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. Os 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 de valor agregado.
Observação
Por padrão, o Azure Stack Hub também usa certificados emitidos por uma autoridade de certificação (CA) integrada ao Ative 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 raiz da CA interna adicionando esse certificado ao armazenamento de certificados local. Não há 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 expiração do certificado (autenticação padrão do servidor TLS sem fixação de certificado).
Requisitos de certificação
A lista a seguir descreve os requisitos gerais de emissão, segurança e formatação de certificados:
- Os certificados devem ser emitidos por uma autoridade de certificação interna ou por 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 Microsoft Trusted Root Authority Program. Para obter a lista completa, consulte Lista de participantes - Microsoft Trusted Root Program.
- A sua infraestrutura do Azure Stack Hub deve ter acesso à rede ao local da Lista de Revogação de Certificados (CRL) da autoridade de certificação, conforme publicado no certificado. Esta CRL deve ser um ponto de extremidade HTTP. Nota: para implantações desconectadas, os certificados emitidos por uma autoridade de certificação (CA) pública não são suportados, se o ponto de extremidade da CRL não estiver acessível. Para obter mais detalhes, consulte Funcionalidades comprometidas ou indisponíveis em implementações desconectadas.
- Ao substituir certificados em compilações anteriores a 1903, os certificados devem ser emitidos pela mesma autoridade de certificação interna usada para assinar certificados fornecidos na implantação ou por qualquer autoridade de certificação pública mencionada acima.
- Ao atualizar certificados para compilações 1903 e posteriores, os certificados podem ser emitidos por qualquer entidade empresarial ou autoridade de certificação pública.
- Não há suporte para o uso de certificados autoassinados.
- Para a implementação e rotação, pode-se usar um único certificado que cubra todos os espaços de nome no Nome da Entidade e no Nome Alternativo da Entidade (SAN). 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 nos pontos de extremidade onde 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ública e privada são necessárias para a instalação do Azure Stack Hub. A chave privada deve ter o atributo de chave da máquina local definido.
- A criptografia PFX deve ser 3DES (esta criptografia é padrão ao exportar a partir de um cliente Windows 10 ou do armazenamento de certificados do Windows Server 2016).
- Os ficheiros pfx de certificado devem ter um valor "Digital Signature" e "KeyEncipherment" no seu campo "Key Usage".
- 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 da chave".
- 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.
- Senha para o certificado pfx tem que 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 seja maiúsculo ou minúsculo.
- Certifique-se de que os nomes de assunto e os nomes alternativos de assunto na extensão de nome alternativo de assunto (x509v3_config) correspondam. O campo nome alternativo do sujeito permite especificar nomes de host adicionais (nomes de 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 ser capazes de entrar em contato com a lista de revogação de certificados (CRL).
Observação
A presença de Autoridades de Certificação Intermediárias na cadeia de confiança de um certificado é suportada pelo .
Certificados obrigatórios
A tabela nesta seção descreve os certificados PKI de ponto de extremidade público do Azure Stack Hub que são necessários para implantações do Microsoft Entra ID e do AD FS Azure Stack Hub. 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 o provedor de soluções copia os diferentes certificados para cada ponto de extremidade pública.
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 endpoint é expresso no formato: <prefixo>.<região>.<fqdn>.
Para sua implantação, o>de região<e <valores de> fqdn devem corresponder à região e aos nomes de domínio externos que você escolheu para seu sistema 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 formato <prefixo>.redmond.contoso.com. Os prefixos <> valores são pré-definidos pela Microsoft para descrever o ponto de extremidade protegido pelo certificado. Além disso, os <prefixo> valores dos pontos de extremidade de infraestrutura externa dependem do serviço 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 coringa que abrange todos os namespaces nos campos Subject e Nome Alternativo da Entidade (SAN) copiados em todos os diretórios. Um único certificado abrangendo todos os terminais e serviços representa uma postura insegura, adequado apenas para ambientes de desenvolvimento. Lembre-se, ambas as opções exigem a utilização de certificados curinga para pontos de extremidade, como acs e Key Vault, quando necessários.
Observação
Durante a implantação, deve copiar os certificados para a pasta de implantação que corresponde ao fornecedor de identidade contra o qual está a implantar (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 do ,, e pode ser encontrada em: C:\CloudDeployment\Setup\Certificates.
| Pasta de implantação | Assunto do certificado e nomes alternativos de assunto (SAN) necessários | Âmbito (por região) | Namespace 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>.<nome de domínio completo> |
| Azure Resource Manager Público | gestão.<região>.<FQDN> | Azure Resource Manager | <região>.<FQDN> |
| Administrador do Azure Resource Manager | gestão administrativa.<região>.<FQDN> | Azure Resource Manager | <região>.<FQDN> |
| ACSBlob | *.blob.<região>.<FQDN> (Certificado SSL Wildcard) |
Armazenamento de Blob | Blob.<região>.<FQDN> |
| ACSTable | *.tabela.<região>.<FQDN> (Wildcard SSL Certificate) |
Armazenamento de tabelas | tabela.<região>.<FQDN> |
| ACSQueue | *.fila.<região>.<FQDN> (Certificado SSL curinga) |
Armazenamento em fila | fila.<região>.<FQDN> |
| KeyVault | *.cofre.<região>.<FQDN> (Certificado SSL Wildcard) |
Cofre da Chave | cofre.<região>.<FQDN> |
| KeyVaultInterno | *.adminvault.<região>.<FQDN> (Certificado SSL Wildcard) |
Keyvault interno | Adminvault.<região>.<FQDN> |
| Host de extensão de administrador | *.adminhosting.<região><fqdn> (Certificados SSL Wildcard) | Servidor de Extensão do Administrador | adminhosting.<região>.<FQDN> |
| Host de extensão pública | *.hospedagem.<região>.<fqdn> (Certificados SSL curinga) | Host de extensão pública | hospedagem.<região>.<FQDN> |
Se você implantar o Azure Stack Hub usando o modo de implantação do 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 | Assunto do certificado e nomes alternativos do sujeito (SAN) necessários | Âmbito (por região) | Namespace do subdomínio |
|---|---|---|---|
| ADFS | adfs.<região>.<fqdn> (Certificado SSL) |
ADFS | <região>.<fqdn> |
| Gráfico | gráfico.<região>.<fqdn> (Certificado SSL) |
Gráfico | <região>.<fqdn> |
Importante
Todos os certificados listados nesta seção devem ter a mesma senha.
Certificados PaaS opcionais
Se você estiver planejando implantar serviços 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, deverá solicitar certificados adicionais para cobrir os pontos de extremidade dos serviços PaaS.
Importante
Os certificados que você usa para provedores de recursos devem ter a mesma autoridade raiz que aqueles usados para os pontos de extremidade globais do Azure Stack Hub.
A tabela a seguir descreve os pontos de extremidade e certificados requeridos 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.
| Âmbito (por região) | Certidão | Assunto necessário do certificado e Nomes Alternativos do Assunto (SANs) | Namespace do subdomínio |
|---|---|---|---|
| Serviço de Aplicativo | Certificado SSL padrão para tráfego na Web | *.appservice.<região>.<fqdn> *.scm.appservice.<região>.<fqdn> *.sso.appservice.<região>.<fqdn> (Certificado SSL Wildcard multidomínio1) |
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.<region>.<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 Wildcard |
EventHub.<região>.<fqdn> |
| SQL, MySQL | SQL e MySQL | *.dbadapter.<região>.<fqdn> (Certificado SSL curinga) |
dbadapter.<região>.<fqdn> |
1 Requer um certificado com vários nomes alternativos de assunto do tipo curinga. Várias SANs curinga em um único certificado podem não ser suportadas por todas as autoridades de certificação públicas.
2 A *.appservice.<regiã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 Appservice exige explicitamente o uso de certificados separados para esses pontos de extremidade.
Próximos passos
Saiba como gerar certificados PKI para a implantação do Azure Stack Hub.