Requisitos de certificado PKI (infraestrutura de chave pública) do Azure Stack Hub

O Azure Stack Hub tem uma rede de infraestrutura pública usando endereços IP públicos acessíveis externamente atribuídos a um pequeno conjunto de serviços do Azure Stack Hub e possivelmente VMs de locatário. Certificados PKI com os nomes DNS apropriados para esses pontos de extremidade de infraestrutura pública do Azure Stack Hub são necessários durante a implantação do Azure Stack Hub. Este artigo fornece informações sobre:

• Requisitos de certificado para o Azure Stack Hub.
• Certificados obrigatórios necessários para a implantação do Azure Stack Hub.
• Certificados opcionais necessários ao implantar provedores de recursos value-add.

Observação

Por padrão, o Azure Stack Hub também usa certificados emitidos de uma AC (autoridade de certificação) integrada do Active Directory interna para autenticação entre os nós. Para validar o certificado, todos os computadores de infraestrutura do Azure Stack Hub confiam no certificado raiz da AC interna por meio da adição desse certificado ao repositório de certificados local. Não há nenhuma fixação ou filtragem de certificados no Azure Stack Hub. A SAN de cada certificado de servidor é validada em relação ao FQDN do destino. Toda a cadeia de confiança também é validada, juntamente com a data de validade do certificado (autenticação de servidor TLS padrão sem fixação de certificado).

Requisitos de certificado

A lista a seguir descreve os requisitos gerais de emissão, segurança e formatação de certificados:

• Os certificados devem ser emitidos de uma autoridade de certificação interna ou de uma autoridade de certificação pública. Se uma autoridade de certificação pública for usada, ela deverá ser incluída na imagem do sistema operacional base como parte do Programa de Autoridade Raiz Confiável da Microsoft. Para obter a lista completa, consulte Lista de Participantes – Programa Raiz Confiável da Microsoft.
• Sua infraestrutura do Azure Stack Hub deve ter acesso à rede para o local CRL (lista de certificados revogados) da autoridade de certificação publicado no certificado. Essa CRL deve ser um ponto de extremidade http. Observação: para implantações desconectadas, não há suporte para certificados emitidos por uma AC (autoridade de certificação pública), se o ponto de extremidade crl não estiver acessível. Para obter mais detalhes, consulte Recursos que estão prejudicados ou indisponíveis em implantações desconectadas.

• Ao girar certificados para builds 1903 e posteriores, os certificados podem ser emitidos por qualquer empresa ou autoridade de certificação pública.

• Não há suporte para o uso de certificados autoassinados.
• Para implantação e rotação, você pode usar um único certificado abrangendo todos os espaços de nome no NOME da Entidade e no SAN (Nome Alternativo da Entidade) do certificado. Como alternativa, você pode usar certificados individuais para cada um dos namespaces abaixo que os serviços do Azure Stack Hub que você planeja utilizar exigem. Ambas as abordagens exigem o uso de curingas para pontos de extremidade em que são necessários, como KeyVault e KeyVaultInternal.
• O algoritmo de assinatura de certificado não deve ser SHA1.
• O formato do certificado deve ser PFX, pois as chaves públicas e privadas são necessárias para a instalação do Azure Stack Hub. A chave privada deve ter o atributo de chave do computador local definido.
• A criptografia PFX deve ser 3DES (essa criptografia é padrão ao exportar de um cliente Windows 10 ou Windows Server 2016 repositório de certificados).
• Os arquivos pfx de certificado devem ter um valor "Assinatura Digital" e "KeyEncipherment" em seu campo "Uso da Chave".
• Os arquivos pfx de certificado 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 "Uso avançado de chaves".
• O campo "Emitido para:" do certificado não deve ser o mesmo que o campo "Emitido por:".
• As senhas para todos os arquivos pfx de certificado devem ser as mesmas no momento da implantação.
• A senha para o certificado pfx precisa ser uma senha complexa. Anote essa senha porque você a usará como um parâmetro de implantação. A senha deve atender aos seguintes requisitos de complexidade de senha:
  • Um comprimento mínimo de oito caracteres.
  • Pelo menos três dos seguintes caracteres: letra maiúscula, letra minúscula, números de 0 a 9, caracteres especiais, caractere alfabético que não é maiúsculo ou minúsculo.
• Verifique se os nomes de entidade e os nomes alternativos de assunto na extensão de nome alternativo da entidade (x509v3_config) correspondem. O campo nome alternativo da entidade permite que você especifique nomes de host adicionais (sites, endereços IP, nomes comuns) a serem protegidos por um único certificado SSL.

Observação

Não há suporte para certificados autoassinados.
Ao implantar o Azure Stack Hub no modo desconectado, é recomendável usar certificados emitidos por uma autoridade de certificação corporativa. Isso é importante porque os clientes que acessam os pontos de extremidade do Azure Stack Hub devem poder entrar em contato com a CRL (lista de certificados revogados).

Observação

Há suporte para a presença de Autoridades de Certificação Intermediárias na cadeia de confiança de um certificado.

Certificados obrigatórios

A tabela nesta seção descreve os certificados PKI do ponto de extremidade público do Azure Stack Hub necessários para implantações do Azure Stack Hub Microsoft Entra ID e do AD FS. Os requisitos de certificado são agrupados por área e os namespaces usados e os certificados necessários para cada namespace. A tabela também descreve a pasta na qual seu provedor de solução copia os diferentes certificados por ponto de extremidade público.

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

Para sua implantação, os <valores de região> e <fqdn> devem corresponder à região e aos nomes de domínio externos escolhidos para o sistema do Azure Stack Hub. Por 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 de prefixo> são pré-atribuídos pela Microsoft para descrever o ponto de extremidade protegido pelo certificado. Além disso, os <valores de prefixo> dos pontos de extremidade de infraestrutura externa dependem do serviço do Azure Stack Hub que usa o ponto de extremidade específico.

Para os ambientes de produção, recomendamos que certificados individuais sejam gerados para cada ponto de extremidade e copiados para o diretório correspondente. Para ambientes de desenvolvimento, os certificados podem ser fornecidos como um único certificado curinga que abrange todos os namespaces nos campos San (Nome Alternativo da Entidade e Entidade) copiados em todos os diretórios. Um único certificado que abrange todos os pontos de extremidade e serviços é uma postura não segura e, portanto, somente de desenvolvimento. Lembre-se de que ambas as opções exigem que você use certificados curinga para pontos de extremidade como acs e Key Vault em que eles são necessários.

Observação

Durante a implantação, você deve copiar certificados para a pasta de implantação que corresponde ao provedor de identidade em que você está implantando (Microsoft Entra ID ou AD FS). Se você usar um único certificado para todos os pontos de extremidade, deverá copiar esse arquivo de certificado para cada pasta de implantação, conforme descrito nas tabelas a seguir. A estrutura de pastas é pré-criada na máquina virtual de implantação e pode ser encontrada em: C:\CloudDeployment\Setup\Certificates.

Pasta de implantação	SAN (nome alternativo da entidade) e assunto do certificado necessários	Escopo (por região)	Namespace de subdomínio
Public Portal	Portal.<região>.<Fqdn>	Portais	<region>.<fqdn>
Portal de administração	adminportal.<region>.<fqdn>	Portais	<region>.<fqdn>
Azure Resource Manager Public	management.<region>.<fqdn>	Azure Resource Manager	<region>.<fqdn>
Azure Resource Manager Admin	adminmanagement.<region>.<fqdn>	Azure Resource Manager	<region>.<fqdn>
ACSBlob	*.Blob.<região>.<Fqdn> (Certificado SSL curinga)	Armazenamento de Blobs	blob.<region>.<fqdn>
ACSTable	*.Tabela.<região>.<Fqdn> (Certificado SSL curinga)	Armazenamento de Tabelas	table.<region>.<fqdn>
ACSQueue	*.Fila.<região>.<Fqdn> (Certificado SSL curinga)	Armazenamento de Filas	queue.<region>.<fqdn>
KeyVault	*.Cofre.<região>.<Fqdn> (Certificado SSL curinga)	Key Vault	vault.<region>.<fqdn>
KeyVaultInternal	*.adminvault.<região>.<Fqdn> (Certificado SSL curinga)	Internal Keyvault	adminvault.<region>.<fqdn>
Admin Extension Host	*.adminhosting.<região>.<fqdn> (certificados SSL curinga)	Admin Extension Host	adminhosting.<region>.<fqdn>
Public Extension Host	*.De.<região>.<fqdn> (certificados SSL curinga)	Public Extension Host	De.<região>.<Fqdn>

Se você implantar o Azure Stack Hub usando o modo de implantação Microsoft Entra, só precisará solicitar os certificados listados na tabela anterior. Mas, se você implantar o Azure Stack Hub usando o modo de implantação do AD FS, também deverá solicitar os certificados descritos na tabela a seguir:

Pasta de implantação	SAN (nome alternativo da entidade) e assunto do certificado necessários	Escopo (por região)	Namespace de subdomínio
ADFS	Adfs. <região>.<Fqdn> (Certificado SSL)	ADFS	<região>.<Fqdn>
Grafo	Gráfico. <região>.<Fqdn> (Certificado SSL)	Grafo	<região>.<Fqdn>

Importante

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

Certificados de PaaS opcionais

Se você estiver planejando implantar serviços de PaaS do Azure Stack Hub (como SQL, MySQL, Serviço de Aplicativo ou Hubs de Eventos) depois que o Azure Stack Hub tiver sido implantado e configurado, você deverá solicitar certificados adicionais para cobrir os pontos de extremidade dos serviços de PaaS.

Importante

Os certificados que você usa para provedores de recursos devem ter a mesma autoridade raiz que os usados para os pontos de extremidade globais do Azure Stack Hub.

A tabela a seguir descreve os pontos de extremidade e os certificados necessários para provedores de recursos. Você não precisa copiar esses certificados para a pasta de implantação do Azure Stack Hub. Em vez disso, você fornece esses certificados durante a instalação do provedor de recursos.

Escopo (por região)	Certificado	Entidade de certificado necessária e SANs (Nomes Alternativos da Entidade)	Namespace de subdomínio
Serviço de Aplicativo	Certificado SSL Padrão de Tráfego da Web	*.appservice. <região>.<Fqdn> *.scm.appservice. <região>.<Fqdn> *.sso.appservice. <região>.<Fqdn> (Certificado SSL curinga de vários domínios1)	appservice. <região>.<Fqdn> scm.appservice. <região>.<Fqdn>
Serviço de Aplicativo	API	api.appservice. <região>.<Fqdn> (Certificado SSL2)	appservice. <região>.<Fqdn> scm.appservice. <região>.<Fqdn>
Serviço de Aplicativo	FTP	ftp.appservice. <região>.<Fqdn> (Certificado SSL2)	appservice. <região>.<Fqdn> scm.appservice. <região>.<Fqdn>
Serviço de Aplicativo	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 curinga)	eventhub. <região>.<Fqdn>
SQL, MySQL	SQL e MySQL	*.dbadapter. <região>.<Fqdn> (Certificado SSL curinga)	dbadapter. <região>.<Fqdn>

¹ Requer um certificado com vários nomes alternativos de entidade curinga. Várias SANs curinga em um único certificado podem não ter suporte de todas as autoridades de certificação públicas.

² Um *.appservice. <região>.<O certificado curinga fqdn> não pode ser usado no lugar desses três certificados (api.appservice.<região>.<fqdn>, ftp.appservice. <região>.<fqdn> e sso.appservice. <região>.<fqdn>. O serviço de aplicativo requer explicitamente o uso de certificados separados para esses pontos de extremidade.

Próximas etapas

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