Partilhar via

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

  • Artigo

A assinatura de um certificado (vulgarmente conhecida como impressão digital) é única. Um certificado de cluster declarado por impressão digital refere-se a uma instância específica de um certificado. Essa especificidade torna a rolagem de certificados, e o gerenciamento em geral, difíceis e explícitos. Cada alteração requer a orquestração de atualizações do cluster e dos hosts de computação subjacentes.

A conversão das declarações de certificado de um cluster do Azure Service Fabric de baseadas em impressão digital em declarações baseadas no CN (nome comum da entidade) do certificado simplifica consideravelmente o gerenciamento. Em particular, a rolagem 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.

Nota

Recomendamos que utilize o módulo Azure Az do PowerShell para interagir com o Azure. Para começar, consulte Instalar o Azure PowerShell. 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 pela autoridade de certificação

A segurança de um cluster cujo certificado é declarado por impressão digital baseia-se no fato de que é 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 pelo CN flui da confiança implícita que o proprietário do cluster tem em seu provedor de certificados. O provedor é 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 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, pois esse é um aspeto fundamental da validação de certificados por assunto. Isto implica também que os certificados autoassinados são totalmente inadequados para este efeito. Literalmente, qualquer pessoa pode gerar um certificado com um determinado assunto.

Um certificado declarado pela NC é normalmente considerado válido se:

  • Sua cadeia pode ser construída com sucesso.
  • O sujeito tem o elemento NC esperado.
  • Seu emissor (imediato ou superior na cadeia) é confiável pelo 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, o que é conhecido como fixação do emissor.

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

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

Para efeitos de ensaio, um certificado autoassinado pode ser declarado pela CN, mas apenas se o emitente estiver fixado à 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 da impressão digital para a CN com um certificado assinado pela CA. Recomendamos que você teste a conversão com um certificado adequado assinado pela CA. Existem opções gratuitas para este teste.

Carregue o certificado e instale-o no conjunto de escalas

No Azure, o mecanismo recomendado para obter e provisionar certificados envolve o Azure Key Vault e suas ferramentas. Um certificado correspondente à declaração de certificado de cluster deve ser provisionado para cada nó dos conjuntos de escala de máquina virtual que compõem o cluster. Para obter mais informações, consulte 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 fazer alterações nas declarações de certificado do cluster. A jornada desde a emissão do certificado até o provisionamento em um nó do Service Fabric é discutida em profundidade 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 impactos baseados em CN:

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

Analise as regras de apresentação e validação para ambas as configurações antes de continuar. A consideração mais importante quando você executa uma conversão de impressão digital para 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 a autenticação mútua bem-sucedida a qualquer momento durante a atualização. A maneira recomendada para obter esse comportamento é declarar o certificado de destino ou meta por impressão digital em uma atualização inicial. Em seguida, conclua a transição para CN em uma subsequente. Se o cluster já estiver em um estado inicial recomendado, você poderá ignorar esta seção.

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

Estados iniciais válidos

  • Thumbprint: GoalCert, ThumbprintSecondary: None
  • Thumbprint: GoalCert, ThumbprintSecondary: OldCert1, quando GoalCert tiver uma data posterior NotBefore à de OldCert1
  • Thumbprint: OldCert1, ThumbprintSecondary: GoalCert, quando GoalCert tiver uma data posterior NotBefore à de OldCert1

Nota

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 acima anteriores à 7.2 CU4 exigem que o GoalCert tenha uma data posterior NotAfter a OldCert1

Se o 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 NC 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 baseadas em nome comum.

Certifique-se de ter 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 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.

Nota

O certificateIssuerThumbprint campo permite especificar os emissores diretos esperados de certificados declarados por 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 pelo validador. Se forem especificadas uma ou mais impressões digitais do emitente, o certificado será aceite se a impressão digital do seu emissor direto, tal como extraída da cadeia, corresponder a qualquer um dos valores especificados neste campo. O certificado será aceito independentemente de a raiz ser 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 esperadas do emissor 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.

A especificação do emitente é considerada uma boa prática. Omitir o emissor continuará a funcionar para certificados encadeados até 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 por assunto podem não conseguir ser validados pelo Service Fabric (para comunicação entre clusters). A validação requer que a política de certificado da PKI seja detetá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 Gerenciador de Recursos do Azure. 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 poderá 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 escala da máquina virtual e os recursos de cluster, respectivamente, devem ser exportados. O modelo gerado também pode ser baixado. Este modelo pode exigir alterações antes de ser totalmente implantável. O modelo também pode não corresponder exatamente ao original. É um reflexo do estado atual do recurso de cluster.

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

  • Atualização da definição da extensão do nó do Service Fabric (sob o 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 escala de máquina virtual correspondente.
  • Atualizando a definição de recurso de cluster.

Exemplos detalhados estão incluídos aqui.

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

Da:

"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 de cluster

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

Da:

    {
        "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

Reimplante o modelo atualizado depois de fazer 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 certificado baseadas em CN

Estado inicial Atualização 1 Atualização 2
Thumbprint: OldCert1, ThumbprintSecondary: None e GoalCert tenha uma data posterior NotBefore a OldCert1 Thumbprint: OldCert1, ThumbprintSecondary: GoalCert -
Thumbprint: OldCert1, ThumbprintSecondary: None e OldCert1 tenha uma data posterior NotBefore a GoalCert Thumbprint: GoalCert, ThumbprintSecondary: OldCert1 Thumbprint: GoalCert, ThumbprintSecondary: None
Thumbprint: OldCert1, ThumbprintSecondary: GoalCert, quando OldCert1 tiver uma data posterior NotBefore a GoalCert Atualize para Thumbprint: GoalCert, ThumbprintSecondary: None -
Thumbprint: GoalCert, ThumbprintSecondary: OldCert1, quando OldCert1 tiver uma data posterior NotBefore a GoalCert Atualize para Thumbprint: GoalCert, ThumbprintSecondary: None -
Thumbprint: OldCert1, ThumbprintSecondary: OldCert2 Remover um dos OldCert1 ou OldCert2 para chegar ao estado Thumbprint: OldCertx, ThumbprintSecondary: None Continuar a partir do novo estado inicial

Nota

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 executar qualquer uma dessas atualizações, consulte Gerenciar certificados em um cluster do Azure Service Fabric.

Próximos passos