Requisitos de certificados de infraestruturas de chaves públicas (PKI) do Azure Stack Hub

O Azure Stack Hub tem uma rede de infraestruturas públicas que utiliza endereços IP públicos acessíveis externamente atribuídos a um pequeno conjunto de serviços Azure Stack Hub e possivelmente VMs inquilinos. Os certificados PKI com os nomes DNS apropriados para estes pontos finais de infraestrutura pública Azure Stack Hub são necessários durante a implementação do Azure Stack Hub. Este artigo fornece informações sobre:

  • Requisitos de certificado para Azure Stack Hub.
  • Certificados obrigatórios necessários para a implantação do Azure Stack Hub.
  • Certificados opcionais necessários para a implantação de fornecedores de recursos de valor acrescentado.

Nota

O Azure Stack Hub, por padrão, também utiliza certificados emitidos a partir de uma autoridade de certificados integrados no Ative Directory (CA) para autenticação entre os nós. Para validar o certificado, todas as máquinas de infraestrutura Azure Stack Hub confiam no certificado raiz da AC interna através da adição desse certificado à sua loja de certificados local. Não há fixação ou filtragem de certificados no Azure Stack Hub. A SAN de cada certificado de servidor é validada contra o FQDN do alvo. Toda a cadeia de confiança também é validada, juntamente com a data de validade do certificado (autenticação padrão do servidor TLS sem fixação de certificado).

Requisitos de certificados

A lista que se segue descreve os requisitos gerais de emissão, segurança e formatação do certificado:

  • Os certificados devem ser emitidos a partir de uma autoridade de certificados internos ou de uma autoridade de certificados públicos. Se for utilizada uma autoridade de certificados públicos, deve ser incluída na imagem do sistema operativo base como parte do Programa microsoft Trust Root Authority. Para obter a lista completa, consulte a Lista de Participantes - Microsoft Trusted Root Program.
  • A sua infraestrutura Azure Stack Hub deve ter acesso à rede à localização da Lista de Revogação de Certificados (CRL) da autoridade de certificados publicada no certificado. Esta CRL deve ser um ponto final de HTTP.
  • Quando os certificados rotativos em edifícios anteriores a 1903, os certificados devem ser emitidos a partir da mesma autoridade de certificados internos utilizada para assinar certificados fornecidos na sua implantação ou qualquer autoridade de certificados públicos de cima.
  • Quando os certificados rotativos para as construções de 1903 e posteriormente, os certificados podem ser emitidos por qualquer empresa ou autoridade de certificados públicos.
  • O uso de certificados auto-assinados não é suportado.
  • Para implantação e rotação, pode utilizar um único certificado que cubra todos os espaços de nome no Nome e Nome Alternativo do Certificado (SAN). Em alternativa, pode utilizar certificados individuais para cada um dos espaços de nome abaixo que os serviços Azure Stack Hub que pretende utilizar exigem. Ambas as abordagens requerem a utilização de cartões selvagens para pontos finais onde são necessários, como KeyVault e KeyVaultInternal.
  • O algoritmo de assinatura de certificado não devia ser SHA1.
  • O formato do certificado deve ser PFX, uma vez que as chaves públicas e privadas são necessárias para a instalação do Azure Stack Hub. A chave privada deve ter o conjunto de atributos da chave da máquina local.
  • A encriptação PFX deve ser 3DES (esta encriptação é padrão ao exportar de um cliente Windows 10 ou Windows Server 2016 loja de certificados).
  • Os ficheiros pfx certificados devem ter um valor "Assinatura Digital" e "KeyEncipherment" no seu campo "Utilização chave".
  • Os ficheiros pfx certificados devem ter os valores "Autenticação do Servidor (1.3.6.1.5.5.7.3.1)" e "Autenticação do Cliente (1.3.6.1.5.5.7.3.2)" no campo "Utilização melhorada da chave".
  • O campo "Emitido para:" do certificado não deve ser o mesmo que o campo "Emitido por:".
  • As palavras-passe de todos os ficheiros pfx de certificado devem ser as mesmas no momento da implementação.
  • A palavra-passe para o certificado pfx tem de ser uma senha complexa. Tome nota desta palavra-passe porque a utilizará como parâmetro de implantação. A palavra-passe deve satisfazer os seguintes requisitos de complexidade da palavra-passe:
    • Um comprimento mínimo de oito caracteres.
    • Pelo menos três dos seguintes caracteres: letra maiúscula, letra minúscula, números de 0-9, caracteres especiais, caracteres alfabéticos que não são maiúsculas ou minúsculas.
  • Certifique-se de que os nomes do sujeito e os nomes alternativos sujeitos na extensão do nome alternativo (x509v3_config) correspondem. O campo de nome alternativo sujeito permite especificar nomes de anfitriões adicionais (websites, endereços IP, nomes comuns) para serem protegidos por um único certificado SSL.

Nota

Os certificados auto-assinados não são suportados.
Ao implementar o Azure Stack Hub em modo desligado, recomenda-se a utilização de certificados emitidos por uma autoridade de certificados da empresa. Isto é importante porque os clientes que acedem aos pontos finais do Azure Stack Hub devem poder contactar a lista de revogação do certificado (CRL).

Nota

É apoiada a presença de Autoridades Intermediárias em cadeias de fidedignidades de um certificado.

Certificados obrigatórios

A tabela desta secção descreve os certificados PKI do ponto final do Azure Stack Hub que são necessários tanto para as implementações do Azure AD AD como para as implementações do AD FS Azure Stack Hub. Os requisitos de certificado são agrupados por área, e os espaços de nome utilizados e os certificados que são necessários para cada espaço de nome. A tabela também descreve a pasta na qual o seu fornecedor de solução copia os diferentes certificados por ponto final público.

São necessários certificados com os nomes DNS apropriados para cada ponto final de infraestrutura pública Azure Stack Hub. O nome DNS de cada ponto final é expresso no formato: prefixo > . < região > . < fqdn >.

Para a sua implementação, os valores da região > e > devem corresponder aos nomes de domínio da região e externos que escolheu para o seu sistema Azure Stack Hub. Como exemplo, se a região for Redmond e o nome de domínio externo for contoso.com,os nomes DNS terão o prefixo de formato .redmond.contoso.com. Os valores do prefixo > são pré-assinados pela Microsoft para descrever o ponto final garantido pelo certificado. Além disso, os valores prefixos > dos pontos finais da infraestrutura externa dependem do serviço Azure Stack Hub que utiliza o ponto final específico.

Para os ambientes de produção, recomendamos que sejam gerados certificados individuais para cada ponto final e copiados para o diretório correspondente. Para ambientes de desenvolvimento, os certificados podem ser fornecidos como um único certificado wildcard que abrange todos os espaços de nome nos campos subjecto e nome alternativo sujeito (SAN) copiados em todos os diretórios. Um único certificado que abrange todos os pontos finais e serviços é uma postura insegura e, portanto, apenas para o desenvolvimento. Lembre-se, ambas as opções requerem que você use certificados wildcard para pontos finais como acs e Key Vault onde são necessários.

Nota

Durante a implementação, deve copiar certificados para a pasta de implantação que corresponda ao fornecedor de identidade contra o qual está a implantar (Azure AD ou AD FS). Se utilizar um único certificado para todos os pontos finais, deve copiar esse ficheiro de certificado em cada pasta de implantação, conforme descrito nas tabelas seguintes. A estrutura da pasta é pré-construída na máquina virtual de implantação e pode ser encontrada em: C:\CloudDeployment\Setup\Certificates.

Pasta de implantação Sujeito de certificado exigido e nomes alternativos sujeitos (SAN) Âmbito (por região) Espaço de nome subdomínio
Portal Público portal. < região > . < fqdn> Portais <região > . < fqdn>
Portal de Administração adminportal. < região > . < fqdn> Portais <região > . < fqdn>
Gestor de Recursos Azure Public gestão. < região > . < fqdn> Azure Resource Manager <região > . < fqdn>
Administrador de Recursos Azure administrador. < região > . < fqdn> Azure Resource Manager <região > . < fqdn>
ACSBlob *.blob. < região > . < fqdn>
(Certificado SSL wildcard)
Armazenamento de Blobs blob. < região > . < fqdn>
ACSTable *.mesa. < região > . < fqdn>
(Certificado SSL wildcard)
Armazenamento de Tabelas mesa. < região > . < fqdn>
ACSQueue *.fila. < região > . < fqdn>
(Certificado SSL wildcard)
Armazenamento de Filas fila. < região > . < fqdn>
KeyVault *.cofre. < região > . < fqdn>
(Certificado SSL wildcard)
Key Vault cofre. < região > . < fqdn>
KeyVaultInternal *.adminvault. < região > . < fqdn>
(Certificado SSL wildcard)
Keyvault Interno adminvault. < região > . < fqdn>
Anfitrião da extensão de Admin *.adminhos. < região > . < fqdn > (Certificados SSL wildcard) Anfitrião da extensão de Admin adminhos. < região > . < fqdn>
Anfitrião de extensão pública *.hosting. < região > . < fqdn > (Certificados SSL wildcard) Anfitrião de extensão pública hospedagem. < região > . < fqdn>

Se implementar o Azure Stack Hub utilizando o modo de implantação Azure AD, só precisa de solicitar os certificados listados na tabela anterior. Mas, se implementar o Azure Stack Hub utilizando o modo de implantação AD FS, também deve solicitar os certificados descritos no quadro seguinte:

Pasta de implantação Sujeito de certificado exigido e nomes alternativos sujeitos (SAN) Âmbito (por região) Espaço de nome subdomínio
ADFS adfs. região > . < fqdn >
(Certificado SSL)
ADFS região > . < fqdn>
Graph gráfico. região > . < fqdn >
(Certificado SSL)
Graph região > . < fqdn>

Importante

Todos os certificados listados nesta secção devem ter a mesma senha.

Certificados de PaaS opcionais

Se planeia implementar os serviços Azure Stack Hub PaaS (como SQL, MySQL, App Service ou Event Hubs) depois de o Azure Stack Hub ter sido implantado e configurado, tem de solicitar certificados adicionais para cobrir os pontos finais dos serviços PaaS.

Importante

Os certificados que utiliza para fornecedores de recursos devem ter a mesma autoridade de raiz que os utilizados para os pontos finais globais do Azure Stack Hub.

O quadro seguinte descreve os pontos finais e certificados necessários para os fornecedores de recursos. Não é necessário copiar estes certificados para a pasta de implantação do Azure Stack Hub. Em vez disso, fornece estes certificados durante a instalação do fornecedor de recursos.

Âmbito (por região) Certificado Sujeito de certificado exigido e nomes alternativos sujeitos (SANs) Espaço de nome subdomínio
Serviço de Aplicações Tráfego Web Padrão SSL Cert *.appservice. região > . < fqdn >
*.scm.appservice. região > . < fqdn >
*.sso.appservice. região > . < fqdn >
(Certificado SSL wildcard multi domínio1)
appservice. região > . < fqdn >
scm.appservice. região > . < fqdn >
Serviço de Aplicações API api.appservice. região > . < fqdn >
(Certificado SSL2)
appservice. região > . < fqdn >
scm.appservice. região > . < fqdn >
Serviço de Aplicações FTP ftp.appservice. região > . < fqdn >
(Certificado SSL2)
appservice. região > . < fqdn >
scm.appservice. região > . < fqdn >
Serviço de Aplicações SSO sso.appservice. região > . < fqdn >
(Certificado SSL2)
appservice. região > . < fqdn >
scm.appservice. região > . < fqdn >
Hubs de Eventos SSL *.eventhub. região > . < fqdn >
(Certificado SSL wildcard)
eventhub. região > . < fqdn >
SQL, MySQL SQL e MySQL *.dbadapter. região > . < fqdn >
(Certificado SSL wildcard)
dbadapter. região > . < fqdn >

1 Requer um certificado com vários nomes alternativos de tema wildcard. Várias SANs wildcard num único certificado podem não ser apoiadas por todas as autoridades de certificados públicos.

2 A *.appservice. região . < o certificado > fqdn wildcard não pode ser usado no lugar destes três certificados (api.appservice.<ftp.appservice. >, e sso.appservice. <. O Appservice requer explicitamente a utilização de certificados separados para estes pontos finais.

Passos seguintes

Saiba como gerar certificados PKI para a implantação do Azure Stack Hub.