Converter certificados de cluster de declarações baseadas em impressão digital em nomes comuns

  • Artigo

A assinatura de um certificado (normalmente conhecida como impressão digital) é exclusiva. Um certificado de cluster declarado pela impressão digital refere-se a uma instância específica de um certificado. Essa especificidade torna a substituição de certificado e o gerenciamento em geral, difícil e explícito. Cada alteração requer a orquestração das atualizações do cluster e dos hosts de computação subjacentes.

Converter as declarações de certificado de um cluster do Azure Service Fabric de baseado em impressão digital em declarações baseadas no nome comum do assunto (CN) do certificado simplifica consideravelmente o gerenciamento. Em particular, a transferência de um certificado não requer mais uma atualização de cluster. Este artigo descreve como converter um cluster existente em declarações baseadas em CN sem tempo de inatividade.

Observação

Recomendamos que você use o módulo Az PowerShell do Azure para interagir com o Azure. Confira Instalar o Azure PowerShell para começar. Para saber como migrar para o módulo Az PowerShell, confira 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 impressão digital repousa no fato de que é impossível, ou computacionalmente inviável, forjar um certificado com a mesma assinatura de outro. Nesse caso, a procedência do certificado é menos importante, portanto, os certificados autoassinados são adequados.

Em contraste, a segurança de um cluster cujos certificados são declarados por CN flui da confiança implícita que o proprietário do cluster tem em seu provedor de certificado. O provedor é o serviço de infraestrutura de chave pública (PKI) que emitiu o certificado. A confiança é baseada, entre outros fatores, nas práticas de certificação da PKI, se sua segurança operacional é auditada e aprovada por outras partes confiáveis e assim por diante.

O proprietário do cluster também deve ter conhecimento detalhado de quais autoridades de certificação (CAs) estão emitindo seus certificados, uma vez que este é um aspecto fundamental da validação de certificados por assunto. Isso também implica que os certificados autoassinados são totalmente inadequados para essa finalidade. Literalmente, qualquer pessoa pode gerar um certificado com um determinado assunto.

Um certificado declarado por CN é normalmente considerado válido se:

  • Sua cadeia pode ser construída com sucesso.
  • O assunto tem o elemento CN esperado.
  • Seu emissor (imediato ou superior na cadeia) é confiável para o agente que realiza a validação.

O Service Fabric oferece suporte à declaração de certificados por CN de duas maneiras:

  • Com emissores implícitos, o que significa que a cadeia deve terminar em uma âncora de confiança.
  • Com emissores declarados por impressão digital, que é conhecida como pinning de emissor.

Para obter mais informações, consulte Declarações de validação de certificado com base em nome comum.

Para converter um cluster usando um certificado autoassinado declarado por impressão digital em CN, o destino, certificado assinado por CA deve ser introduzido primeiro no cluster por impressão digital. Só então é possível a conversão de impressão digital em CN.

Para fins de teste, um certificado autoassinado pode ser declarado pelo CN, mas apenas se o emissor estiver preso à sua própria impressão digital. Do ponto de vista da segurança, essa ação é quase equivalente a declarar o mesmo certificado por impressão digital. Uma conversão bem-sucedida desse tipo não garante uma conversão bem-sucedida de impressão digital em CN com um certificado assinado por CA. Recomendamos que você teste a conversão com um certificado assinado por CA adequado. 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 provisionar certificados envolve o Azure Key Vault e suas ferramentas. Um certificado que corresponda à declaração de certificado de cluster deve ser provisionado para cada nó dos conjuntos de dimensionamento de máquina virtual que compõem seu cluster. Para obter mais informações, consulte Segredos em conjuntos de dimensionamento de máquina virtual.

É importante instalar os certificados de cluster atuais e de destino nas máquinas virtuais de cada tipo de nó do cluster antes de fazer alterações nas declarações de certificado do cluster. A jornada da emissão do certificado ao provisionamento em um nó do Service Fabric é discutida em detalhes em A jornada de um certificado.

Colocar o cluster em um estado inicial ideal

Convertendo uma declaração de certificado de impactos baseados em impressão digital para baseados em CN:

  • Como cada nó no cluster encontra e apresenta suas credenciais para outros nós.
  • Como cada nó valida as credenciais de sua contraparte ao estabelecer uma conexão segura.

Revise as regras de apresentação e validação para ambas as configurações antes de continuar. A consideração mais importante ao executar uma conversão de impressão digital em CN é que os nós atualizados e ainda não atualizados (ou seja, nós pertencentes a domínios de atualização diferentes) devem ser capazes de executar autenticação mútua com êxito a qualquer momento durante a atualização. A maneira recomendada de atingir esse comportamento é declarar o certificado de destino ou objetivo por impressão digital em uma atualização inicial. Em seguida, conclua a transição para CN em um subsequente. Se o cluster já estiver em um estado inicial recomendado, você pode pular esta seção.

Existem vários estados iniciais válidos para uma conversão. A invariável é que o cluster já está usando o certificado de destino (declarado por impressão digital) no início da atualização para CN. Consideramos GoalCert, OldCert1 e OldCert2 neste artigo.

Estados iniciais válidos

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

Observação

Antes da versão 7.2.445 (7.2 CU4), o Service Fabric selecionava o certificado de expiração mais distante (o certificado com a propriedade 'NotAfter' mais distante), portanto, os estados iniciais anteriores a 7.2 CU4 exigem que GoalCert tenha uma data NotAfter posterior a OldCert1

Se o seu cluster não estiver em um dos estados válidos descritos anteriormente, consulte as informações sobre como atingir esse estado na seção no final deste artigo.

Selecione o esquema de validação de certificado baseado em CN desejado

Conforme descrito anteriormente, o Service Fabric oferece suporte à declaração de certificados por CN com uma âncora de confiança implícita ou com a fixação explícita das impressões digitais do emissor. Para obter mais informações, consulte Declarações de validação de certificado com base em nome comum.

Certifique-se de ter um bom entendimento das diferenças e implicações da escolha de qualquer um dos mecanismos. Sintaticamente, essa diferença ou escolha é determinada pelo valor do parâmetro certificateIssuerThumbprintList. Vazio significa confiar em uma CA raiz confiável (âncora de confiança), enquanto um conjunto de impressões digitais restringe os emissores diretos permitidos de certificados de cluster.

Observação

O campo certificateIssuerThumbprint permite que você especifique os emissores diretos esperados de certificados declarados pelo assunto CN. Os valores aceitáveis são uma ou mais impressões digitais SHA1 separadas por vírgula. Esta ação fortalece a validação do certificado.

Se nenhum emissor for especificado ou a lista estiver vazia, o certificado será aceito para autenticação se sua cadeia puder ser construída. O certificado então termina em uma raiz confiável para o validador. Se uma ou mais impressões digitais do emissor forem especificadas, o certificado será aceito se a impressão digital de seu emissor direto, conforme extraída da cadeia, corresponder a qualquer um dos valores especificados neste campo. O certificado será aceito quer a raiz seja confiável ou não.

Uma PKI pode usar diferentes autoridades de certificação (também conhecidas como emissores) para assinar certificados com um determinado assunto. Por esse motivo, é importante especificar todas as impressões digitais do emissor esperadas para esse assunto. Em outras palavras, a renovação de um certificado não tem garantia de ser assinada pelo mesmo emissor do certificado que está sendo renovado.

Especificar o emissor é considerada uma prática recomendada. A omissão do emissor continuará a funcionar para certificados vinculados a uma raiz confiável, mas esse comportamento tem limitações e pode ser eliminado em um futuro próximo. Os clusters implantados no Azure, protegidos com certificados X509 emitidos por uma PKI privada e declarados pelo assunto podem não ser validados pelo Service Fabric (para comunicação de cluster a serviço). A validação requer que a política de certificado da PKI seja detectável, disponível e acessível.

Atualizar o modelo do Azure Resource Manager do cluster e implantar

Gerencie seus clusters do Service Fabric com modelos do Azure Resource Manager (ARM). Uma alternativa, que também usa artefatos JSON, é o Azure Resource Explorer (visualização). Uma experiência equivalente não está disponível no portal do Azure no momento.

Se o modelo original correspondente a um cluster existente não estiver disponível, um modelo equivalente pode ser obtido no portal do Azure. Vá para o grupo de recursos que contém o cluster e selecione Exportar modelo no menu Automação à esquerda. Em seguida, selecione os recursos desejados. No mínimo, o conjunto de dimensionamento da máquina virtual e os recursos do cluster, respectivamente, devem ser exportados. O modelo gerado também pode ser baixado. 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 de cluster.

As mudanças necessárias são as seguintes:

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

Exemplos detalhados estão incluídos aqui.

Atualize os recursos do conjunto de dimensionamento da máquina virtual

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')]"
                            }
                        },
                        ...
                    }
                },

Atualize o recurso do cluster

No recurso Microsoft.ServiceFabric/ clusters, adicione uma propriedade certificateCommonNames com uma configuração commonNamese remova a propriedade do certificadopor completo (todas as suas configuraçõ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, consulte Implantar um cluster do Service Fabric que usa o nome comum do certificado em vez da impressão digital.

Implantar o modelo atualizado

Reimplemente o modelo atualizado depois de fazer as mudanças.

$groupname = "sfclustertutorialgroup"

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

Alcance um estado inicial válido para converter um cluster em declarações de certificado baseadas em CN

Estado inicial Atualização 1 Atualização 2
Thumbprint: OldCert1, ThumbprintSecondary: None e GoalCert tem uma data posterior NotBefore que OldCert1 Thumbprint: OldCert1, ThumbprintSecondary: GoalCert -
Thumbprint: OldCert1, ThumbprintSecondary: None e OldCert1 tem uma data posterior NotBefore que GoalCert Thumbprint: GoalCert, ThumbprintSecondary: OldCert1 Thumbprint: GoalCert, ThumbprintSecondary: None
Thumbprint: OldCert1, ThumbprintSecondary: GoalCert, onde OldCert1 tem uma data posterior NotBefore que GoalCert Fazer upgrade para Thumbprint: GoalCert, ThumbprintSecondary: None -
Thumbprint: GoalCert, ThumbprintSecondary: OldCert1, onde OldCert1 tem uma data posterior NotBefore que GoalCert Fazer upgrade para Thumbprint: GoalCert, ThumbprintSecondary: None -
Thumbprint: OldCert1, ThumbprintSecondary: OldCert2 Remover um de OldCert1 ou OldCert2 para chegar ao estado Thumbprint: OldCertx, ThumbprintSecondary: None Continue do novo estado inicial

Observação

Para um cluster em uma versão anterior à versão 7.2.445 (7.2 CU4), substitua NotBefore por NotAfter nos estados acima.

Para obter instruções sobre como realizar qualquer uma dessas atualizações, consulte Gerenciar certificados em um cluster do Azure Service Fabric.

Próximas etapas