Converter certificados de cluster de declarações baseadas em thumbprint em nomes comuns

  • Artigo

A assinatura de um certificado (normalmente conhecido como thumbprint) é exclusiva. Um certificado de cluster declarado pelo thumbprint refere-se a uma instância específica de um certificado. Esta especificidade torna o rollover de certificados e a gestão em geral, difícil e explícito. Cada alteração requer a orquestração de atualizações do cluster e dos anfitriões de computação subjacentes.

Converter as declarações de certificado de um cluster do Azure Service Fabric de thumbprint em declarações baseadas no nome comum do certificado (CN) simplifica consideravelmente a gestão. Em particular, a reversão de um certificado já não requer uma atualização do cluster. Este artigo descreve como converter um cluster existente em declarações baseadas em CN sem tempo de inatividade.

Nota

Recomendamos que utilize o módulo Azure Az PowerShell para interagir com o Azure. Veja Instalar o Azure PowerShell para começar. Para saber como migrar para o módulo do Az PowerShell, veja Migrar o Azure PowerShell do AzureRM para o Az.

Mover para certificados assinados por autoridade de certificação

A segurança de um cluster cujo certificado é declarado por thumbprint baseia-se no facto de ser impossível, ou computacionalmente inviável, falsificar um certificado com a mesma assinatura que outro. Neste caso, a proveniência do certificado é menos importante, pelo que os certificados autoassinados são adequados.

Por outro lado, a segurança de um cluster cujos certificados são declarados pelos fluxos CN da confiança implícita que o proprietário do cluster tem no respetivo fornecedor de certificados. O fornecedor é o serviço de infraestrutura de chave pública (PKI) que emitiu o certificado. A confiança baseia-se, entre outros fatores, nas práticas de certificação da PKI, se a sua segurança operacional é auditada e aprovada por outras entidades fidedignas, etc.

O proprietário do cluster também tem de ter conhecimentos detalhados sobre as autoridades de certificação (ACs) que estão a emitir os respetivos certificados, uma vez que este é um aspeto fundamental da validação de certificados por assunto. Isto também implica que os certificados autoassinados são totalmente inadequados para esta finalidade. Literalmente, qualquer pessoa pode gerar um certificado com um determinado assunto.

Normalmente, um certificado declarado pelo CN é considerado válido se:

  • A sua cadeia pode ser construída com êxito.
  • O assunto tem o elemento CN esperado.
  • O emissor (imediato ou superior na cadeia) é considerado fidedigno pelo agente que executa a validação.

O Service Fabric suporta a declaração de certificados por CN de duas formas:

  • Com emissores implícitos , o que significa que a cadeia tem de terminar numa âncora de fidedignidade.
  • Com os emissores declarados pelo thumbprint, que é conhecido como afixação do emissor.

Para obter mais informações, veja Declarações de validação de certificados baseadas em nome comum.

Para converter um cluster com um certificado autoassinado declarado pelo thumbprint para CN, o certificado assinado pela AC de destino tem de ser introduzido primeiro no cluster por thumbprint. Só então é possível a conversão do thumbprint para o CN.

Para fins de teste, um certificado autoassinado pode ser declarado pelo CN, mas apenas se o emissor estiver afixado ao seu próprio thumbprint. Do ponto de vista da segurança, esta ação é quase equivalente a declarar o mesmo certificado por thumbprint. Uma conversão deste tipo com êxito não garante uma conversão com êxito do thumbprint para o CN com um certificado assinado pela AC. Recomendamos que teste a conversão com um certificado correto assinado por AC. Existem opções gratuitas para este teste.

Carregar o certificado e instalá-lo no conjunto de dimensionamento

No Azure, o mecanismo recomendado para obter e aprovisionar certificados envolve o Azure Key Vault e as respetivas ferramentas. Um certificado que corresponda à declaração de certificado de cluster tem de ser aprovisionado em todos os nós dos conjuntos de dimensionamento de máquinas virtuais que compõem o cluster. Para obter mais informações, veja Segredos em conjuntos de dimensionamento de máquinas virtuais.

É importante instalar certificados de cluster atuais e de destino nas máquinas virtuais de cada tipo de nó do cluster antes de efetuar alterações nas declarações de certificado do cluster. O percurso desde a emissão de certificados até ao aprovisionamento num nó do Service Fabric é abordado em profundidade no percurso de um certificado.

Colocar o cluster num estado inicial ideal

Converter uma declaração de certificado de um thumbprint baseado em impactos baseados em CN:

  • Como cada nó no cluster localiza e apresenta as respetivas credenciais a outros nós.
  • Como cada nó valida as credenciais do respetivo homólogo ao estabelecer uma ligação segura.

Reveja as regras de apresentação e validação para ambas as configurações antes de continuar. A consideração mais importante quando efetua uma conversão thumbprint-to-CN é que os nós atualizados e ainda não atualizados (ou seja, os nós pertencentes a diferentes domínios de atualização) têm de conseguir efetuar uma autenticação mútua com êxito em qualquer altura durante a atualização. A forma recomendada de alcançar este comportamento é declarar o certificado de destino ou objetivo por thumbprint numa atualização inicial. Em seguida, conclua a transição para CN numa posterior. Se o cluster já estiver num estado de início recomendado, pode ignorar esta secção.

Existem vários estados iniciais válidos para uma conversão. O invariante é que o cluster já está a utilizar o certificado de destino (declarado por thumbprint) no início da atualização para CN. Consideramos GoalCert, OldCert1e OldCert2 neste artigo.

Estados iniciais válidos

  • Thumbprint: GoalCert, ThumbprintSecondary: None
  • Thumbprint: GoalCert, ThumbprintSecondary: OldCert1, em GoalCert que tem uma data posterior NotBefore à de OldCert1
  • Thumbprint: OldCert1, ThumbprintSecondary: GoalCert, em GoalCert que tem uma data posterior NotBefore à de OldCert1

Nota

Antes da versão 7.2.445 (7.2 CU4), o Service Fabric selecionou o certificado de expiração mais distante (o certificado com a propriedade "NotAfter" mais distante), pelo que os estados iniciais acima anteriores a 7,2 CU4 exigem que o GoalCert tenha uma data posterior NotAfter a OldCert1

Se o cluster não estiver num dos estados válidos descritos anteriormente, veja informações sobre como alcançar esse estado na secção no final deste artigo.

Selecione o esquema de validação de certificados baseado em CN pretendido

Conforme descrito anteriormente, o Service Fabric suporta a declaração de certificados por CN com uma âncora de fidedignidade implícita ou afixar explicitamente os thumbprints do emissor. Para obter mais informações, veja Declarações de validação de certificados baseadas em nome comum.

Certifique-se de que tem uma boa compreensão das diferenças e das implicações da escolha de qualquer um dos mecanismos. Sintaticamente, esta diferença ou escolha é determinada pelo valor do certificateIssuerThumbprintList parâmetro. Vazio significa depender de uma AC de raiz fidedigna (âncora de confiança), enquanto um conjunto de thumbprints restringe os emissores diretos permitidos de certificados de cluster.

Nota

O certificateIssuerThumbprint campo permite-lhe especificar os emissores diretos esperados de certificados declarados pelo CN do requerente. Os valores aceitáveis são um ou mais thumbprints SHA1 separados por vírgulas. Esta ação reforça a validação do certificado.

Se não forem especificados emissores ou a lista estiver vazia, o certificado será aceite para autenticação se a cadeia puder ser criada. Em seguida, o certificado acaba numa raiz fidedigna pelo validador. Se forem especificados um ou mais thumbprints do emissor, o certificado será aceite se o thumbprint do emissor direto, tal como extraído da cadeia, corresponder a qualquer um dos valores especificados neste campo. O certificado será aceite quer a raiz seja ou não fidedigna.

Uma PKI pode utilizar diferentes autoridades de certificação (também conhecidas como emissores) para assinar certificados com um determinado assunto. Por este motivo, é importante especificar todos os thumbprints do emissor esperados para esse assunto. Por outras palavras, não é garantido que a renovação de um certificado seja assinada pelo mesmo emissor que o certificado que está a ser renovado.

Especificar o emissor é considerado uma melhor prática. Omitir o emissor continuará a funcionar para os certificados que estão a encadear numa raiz fidedigna, mas este comportamento tem limitações e pode ser gradualmente eliminado num futuro próximo. Os clusters implementados no Azure, protegidos com certificados X509 emitidos por um PKI privado e declarados por assunto poderão não ser validados pelo Service Fabric (para comunicação cluster a serviço). A validação requer que a política de certificados da PKI seja detetável, disponível e acessível.

Atualizar o modelo de Resource Manager do Azure do cluster e implementar

Faça a gestão dos clusters do Service Fabric com modelos do Azure Resource Manager (ARM). Uma alternativa, que também utiliza artefactos JSON, é o Azure Resource Explorer (pré-visualização). De momento, não está disponível uma experiência equivalente no portal do Azure.

Se o modelo original correspondente a um cluster existente não estiver disponível, pode obter um modelo equivalente no portal do Azure. Aceda ao grupo de recursos que contém o cluster e selecione Exportar modelo no menu Automatização à esquerda. Em seguida, selecione os recursos que pretende. No mínimo, o conjunto de dimensionamento de máquinas virtuais e os recursos de cluster, respetivamente, devem ser exportados. O modelo gerado também pode ser transferido. Este modelo pode exigir alterações antes de ser totalmente implementável. O modelo também pode não corresponder exatamente ao original. É um reflexo do estado atual do recurso do cluster.

As alterações necessárias são as seguintes:

  • Atualizar a definição da extensão de nó do Service Fabric (no recurso da máquina virtual). Se o cluster definir vários tipos de nós, terá de atualizar a definição de cada conjunto de dimensionamento de máquinas virtuais correspondente.
  • A atualizar a definição do recurso de cluster.

Estão incluídos exemplos detalhados aqui.

Atualizar os recursos do conjunto de dimensionamento de máquinas virtuais

De:

"virtualMachineProfile": {
        "extensionProfile": {
            "extensions": [
                {
                    "name": "[concat('ServiceFabricNodeVmExt','_vmNodeType0Name')]",
                    "properties": {
                        "type": "ServiceFabricNode",
                        "autoUpgradeMinorVersion": true,
                        "protectedSettings": {
                            ...
                        },
                        "publisher": "Microsoft.Azure.ServiceFabric",
                        "settings": {
                            ...
                            "certificate": {
                                "thumbprint": "[parameters('certificateThumbprint')]",
                                "x509StoreName": "[parameters('certificateStoreValue')]"
                            }
                        },
                        ...
                    }
                },

Para:

"virtualMachineProfile": {
        "extensionProfile": {
            "extensions": [
                {
                    "name": "[concat('ServiceFabricNodeVmExt','_vmNodeType0Name')]",
                    "properties": {
                        "type": "ServiceFabricNode",
                        "autoUpgradeMinorVersion": true,
                        "protectedSettings": {
                            ...
                        },
                        "publisher": "Microsoft.Azure.ServiceFabric",
                        "settings": {
                            ...
                            "certificate": {
                                "commonNames": [
                                    "[parameters('certificateCommonName')]"
                                ],
                                "x509StoreName": "[parameters('certificateStoreValue')]"
                            }
                        },
                        ...
                    }
                },

Atualizar o recurso do cluster

No recurso Microsoft.ServiceFabric/clusters , adicione uma propriedade certificateCommonNames com uma definição commonNames e remova completamente a propriedade do certificado (todas as definições).

De:

    {
        "apiVersion": "2018-02-01",
        "type": "Microsoft.ServiceFabric/clusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        "dependsOn": [
            ...
        ],
        "properties": {
            "addonFeatures": [
                ...
            ],
            "certificate": {
              "thumbprint": "[parameters('certificateThumbprint')]",
              "x509StoreName": "[parameters('certificateStoreValue')]"
            },
        ...

Para:

    {
        "apiVersion": "2018-02-01",
        "type": "Microsoft.ServiceFabric/clusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        "dependsOn": [
            ...
        ],
        "properties": {
            "addonFeatures": [
                ...
            ],
            "certificateCommonNames": {
                "commonNames": [
                    {
                        "certificateCommonName": "[parameters('certificateCommonName')]",
                        "certificateIssuerThumbprint": "[parameters('certificateIssuerThumbprintList')]"
                    }
                ],
                "x509StoreName": "[parameters('certificateStoreValue')]"
            },
        ...

Para obter mais informações, veja Implementar um cluster do Service Fabric que utiliza o nome comum do certificado em vez de thumbprint.

Implementar o modelo atualizado

Reimplemente o modelo atualizado depois de efetuar as alterações.

$groupname = "sfclustertutorialgroup"

New-AzResourceGroupDeployment -ResourceGroupName $groupname -Verbose `
    -TemplateParameterFile "C:\temp\cluster\parameters.json" -TemplateFile "C:\temp\cluster\template.json"

Obter um estado inicial válido para converter um cluster em declarações de certificados baseados em CN

Estado inicial Atualização 1 Atualização 2
Thumbprint: OldCert1, ThumbprintSecondary: None e GoalCert tem uma data posterior NotBefore a OldCert1 Thumbprint: OldCert1, ThumbprintSecondary: GoalCert -
Thumbprint: OldCert1, ThumbprintSecondary: None e OldCert1 tem uma data posterior NotBefore a GoalCert Thumbprint: GoalCert, ThumbprintSecondary: OldCert1 Thumbprint: GoalCert, ThumbprintSecondary: None
Thumbprint: OldCert1, ThumbprintSecondary: GoalCert, em que OldCert1 tem uma data posterior NotBefore a GoalCert Atualizar para Thumbprint: GoalCert, ThumbprintSecondary: None -
Thumbprint: GoalCert, ThumbprintSecondary: OldCert1, em que OldCert1 tem uma data posterior NotBefore a GoalCert Atualizar para Thumbprint: GoalCert, ThumbprintSecondary: None -
Thumbprint: OldCert1, ThumbprintSecondary: OldCert2 Remover um ou OldCert1OldCert2 para chegar ao estado Thumbprint: OldCertx, ThumbprintSecondary: None Continuar a partir do novo estado inicial

Nota

Para um cluster numa versão anterior à versão 7.2.445 (7.2 CU4), substitua por NotBeforeNotAfter nos estados acima.

Para obter instruções sobre como realizar qualquer uma destas atualizações, veja Gerir certificados num cluster do Azure Service Fabric.

Passos seguintes