Requisitos de certificados de infraestruturas de chaves públicas (PKI) do Azure Stack Hub
O Azure Stack Hub tem uma rede de infraestrutura pública com 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 inquilino. Os certificados PKI com os nomes DNS adequados para estes pontos finais de infraestrutura pública do 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 o Azure Stack Hub.
- Certificados obrigatórios necessários para a implementação do Azure Stack Hub.
- Certificados opcionais necessários ao implementar fornecedores de recursos de valor acrescentado.
Nota
Por predefinição, o Azure Stack Hub também utiliza certificados emitidos por uma autoridade de certificação (AC) integrada no Active Directory interna para autenticação entre os nós. Para validar o certificado, todas as máquinas de infraestrutura do Azure Stack Hub confiam no certificado de raiz da AC interna através da adição desse certificado ao respetivo arquivo de certificados local. Não existe afixação ou filtragem de certificados no Azure Stack Hub. A SAN de cada certificado de servidor é validada no FQDN do destino. Toda a cadeia de fidedignidade também é validada, juntamente com a data de expiração do certificado (autenticação padrão do servidor TLS sem afixação de certificado).
Requisitos de certificados
A lista seguinte descreve os requisitos gerais de emissão, segurança e formatação de certificados:
- Os certificados têm de ser emitidos por uma autoridade de certificação interna ou por uma autoridade de certificação pública. Se for utilizada uma autoridade de certificação pública, esta tem de ser incluída na imagem do sistema operativo base como parte do Programa de Autoridade de Raiz Fidedigna da Microsoft. Para obter a lista completa, consulte Lista de Participantes – Programa de Raiz Fidedigna da Microsoft.
- A infraestrutura do Azure Stack Hub tem de ter acesso de rede à localização da Lista de Revogação de Certificados (CRL) da autoridade de certificação publicada no certificado. Esta CRL deve ser um ponto final de HTTP. Nota: para implementações desligadas, os certificados emitidos por uma autoridade de certificação pública (AC) não são suportados, se o ponto final CRL não estiver acessível. Para obter mais detalhes, veja Funcionalidades com deficiência ou indisponíveis em implementações desligadas.
- Ao rodar certificados em compilações anteriores a 1903, os certificados têm de ser emitidos a partir da mesma autoridade de certificação interna utilizada para assinar certificados fornecidos na implementação ou em qualquer autoridade de certificação pública acima.
- Ao rodar certificados para compilações 1903 e posteriores, os certificados podem ser emitidos por qualquer autoridade de certificação pública ou empresarial.
- A utilização de certificados autoassinados não é suportada.
- Para implementação e rotação, pode utilizar um único certificado que abranja todos os espaços de nomes no Nome do Requerente do certificado e no Nome Alternativo do Requerente (SAN). Em alternativa, pode utilizar certificados individuais para cada um dos espaços de nomes abaixo dos serviços do Azure Stack Hub que pretende utilizar. 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 deve ser SHA1.
- O formato de certificado tem de 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 tem de ter o atributo de chave de máquina local definido.
- A encriptação PFX tem de ser 3DES (esta encriptação é predefinida ao exportar a partir de um cliente Windows 10 ou Windows Server 2016 arquivo de certificados).
- Os ficheiros pfx do certificado têm de ter um valor "Assinatura Digital" e "KeyEncipherment" no campo "Utilização de Chaves".
- Os ficheiros pfx do certificado têm de ter os valores "Autenticação do Servidor (1.3.6.1.5.5.7.3.1)" e "Autenticação de Cliente (1.3.6.1.5.5.7.3.2)" no campo "Utilização Avançada da Chave".
- O campo "Emitido para:" do certificado não pode ser o mesmo que o campo "Emitido por:".
- As palavras-passe de todos os ficheiros pfx de certificado têm de ser as mesmas no momento da implementação.
- A palavra-passe para o certificado pfx tem de ser uma palavra-passe complexa. Tome nota desta palavra-passe, pois irá utilizá-la como parâmetro de implementação. A palavra-passe tem de cumprir os seguintes requisitos de complexidade de palavras-passe:
- Um comprimento mínimo de oito carateres.
- Pelo menos três dos seguintes carateres: letra em maiúscula, letra minúscula, números de 0-9, carateres especiais, caráter alfabético que não seja maiúscula ou minúscula.
- Certifique-se de que os nomes dos requerentes e os nomes alternativos do requerente na extensão de nome alternativo (x509v3_config) correspondem. O campo de nome alternativo do requerente permite-lhe especificar nomes de anfitrião adicionais (sites, endereços IP, nomes comuns) para serem protegidos por um único certificado SSL.
Nota
Os certificados autoassinados não são suportados.
Ao implementar o Azure Stack Hub no modo desligado, recomenda-se a utilização de certificados emitidos por uma autoridade de certificação empresarial. Isto é importante porque os clientes que acedem aos pontos finais do Azure Stack Hub têm de conseguir contactar a lista de revogação de certificados (CRL).
Nota
A presença de Autoridades de Certificação Intermediárias na cadeia de fidedignidade de um certificado é suportada.
Certificados obrigatórios
A tabela nesta secção descreve os certificados PKI de ponto final público do Azure Stack Hub que são necessários para implementações do ID Microsoft Entra e do AD FS do Azure Stack Hub. Os requisitos de certificado são agrupados por área e os espaços de nomes utilizados e os certificados necessários para cada espaço de nomes. A tabela também descreve a pasta na qual o fornecedor de soluções copia os diferentes certificados por ponto final público.
São necessários certificados com os nomes DNS adequados para cada ponto final de infraestrutura pública do Azure Stack Hub. O nome DNS de cada ponto final é expresso no formato: <prefixo>.<região>.<fqdn>.
Para a sua implementação, os <valores regionais> e <fqdn> têm de corresponder aos nomes de domínio externo e de região que escolheu 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 do prefixo> são predesignados pela Microsoft para descrever o ponto final protegido pelo certificado. Além disso, os <valores de prefixo> 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 universal que abrange todos os espaços de nomes nos campos Assunto e Nome Alternativo do Requerente (SAN) copiados para todos os diretórios. Um único certificado que abrange todos os pontos finais e serviços é uma postura insegura e, portanto, apenas de desenvolvimento. Lembre-se de que ambas as opções exigem que utilize certificados universais para pontos finais, como acs e Key Vault onde são necessários.
Nota
Durante a implementação, tem de copiar certificados para a pasta de implementação que corresponde ao fornecedor de identidade no qual está a implementar (Microsoft Entra ID ou AD FS). Se utilizar um único certificado para todos os pontos finais, tem de copiar esse ficheiro de certificado para cada pasta de implementação, conforme descrito nas tabelas seguintes. A estrutura da pasta está pré-criada na máquina virtual de implementação e pode ser encontrada em: C:\CloudDeployment\Setup\Certificates.
| Pasta de implementação | Assunto do certificado obrigatório e nomes alternativos do requerente (SAN) | Âmbito (por região) | Espaço de nomes do 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> |
| Público do Azure Resource Manager | gestão.<região>.<fqdn> | Azure Resource Manager | <região>.<fqdn> |
| Azure Resource Manager Administração | adminmanagement.<região>.<fqdn> | Azure Resource Manager | <região>.<fqdn> |
| ACSBlob | *.blob.<região>.<fqdn> (Certificado SSL universal) |
Armazenamento de Blobs | blob.<região>.<fqdn> |
| ACSTable | *.table.<região>.<fqdn> (Certificado SSL universal) |
Armazenamento de Tabelas | tabela.<região>.<fqdn> |
| ACSQueue | *.queue.<região>.<fqdn> (Certificado SSL com Caráter Universal) |
Armazenamento de Filas | fila.<região>.<fqdn> |
| KeyVault | *.vault.<região>.<fqdn> (Certificado SSL com Caráter Universal) |
Key Vault | cofre.<região>.<fqdn> |
| KeyVaultInternal | *.adminvault.<região>.<fqdn> (Certificado SSL com Caráter Universal) |
Keyvault Interno | adminvault.<região>.<fqdn> |
| Anfitrião da Extensão Administração | *.adminhosting.<região>.<fqdn> (Certificados SSL de Carateres Universais) | Anfitrião da Extensão Administração | adminhosting.<região>.<fqdn> |
| Anfitrião de Extensão Pública | *.hosting.<região>.<fqdn> (Certificados SSL de Carateres Universais) | Anfitrião de Extensão Pública | alojamento.<região>.<fqdn> |
Se implementar o Azure Stack Hub com o modo de implementação Microsoft Entra, só precisa de pedir os certificados listados na tabela anterior. No entanto, se implementar o Azure Stack Hub com o modo de implementação do AD FS, também tem de pedir os certificados descritos na seguinte tabela:
| Pasta de implementação | Nome alternativo do requerente do certificado e do requerente (SAN) necessários | Âmbito (por região) | Espaço de nomes de 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 têm de ter a mesma palavra-passe.
Certificados de PaaS opcionais
Se estiver a planear implementar serviços PaaS do Azure Stack Hub (como SQL, MySQL, Serviço de Aplicações ou Hubs de Eventos) após a implementação e configuração do Azure Stack Hub, tem de pedir certificados adicionais para cobrir os pontos finais dos serviços PaaS.
Importante
Os certificados que utiliza para fornecedores de recursos têm de ter a mesma autoridade de raiz que os utilizados para os pontos finais globais do Azure Stack Hub.
A tabela seguinte descreve os pontos finais e certificados necessários para os fornecedores de recursos. Não precisa de copiar estes certificados para a pasta de implementação do Azure Stack Hub. Em vez disso, fornece estes certificados durante a instalação do fornecedor de recursos.
| Âmbito (por região) | Certificado | Requerente do certificado obrigatório e Nomes Alternativos do Requerente (SANs) | Espaço de nomes de subdomínio |
|---|---|---|---|
| Serviço de Aplicações | Certificado SSL Predefinido de Tráfego Web | *.appservice. <região>.<fqdn> *.scm.appservice. <região>.<fqdn> *.sso.appservice. <região>.<fqdn> (Certificado SSL de Carateres Universais de Múltiplos Domínios1) |
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 com Caráter Universal) |
eventhub. <região>.<fqdn> |
| SQL, MySQL | SQL e MySQL | *.dbadapter. <região>.<fqdn> (Certificado SSL com Caráter Universal) |
dbadapter. <região>.<fqdn> |
1 Requer um certificado com vários nomes alternativos de requerente de carateres universais. Várias SANs de carateres universais num único certificado podem não ser suportadas por todas as autoridades de certificação públicas.
2 Um *.appservice. <região>.<O certificado de caráter universal fqdn> não pode ser utilizado em vez destes três certificados (api.appservice.<região>.<fqdn>, ftp.appservice. <região>.<fqdn> e sso.appservice. <região>.<fqdn>. O Serviço de Aplicações requer explicitamente a utilização de certificados separados para estes pontos finais.
Passos seguintes
Saiba como gerar certificados PKI para a implementação do Azure Stack Hub.