Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
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. Para implantações desconectadas, se o ponto de extremidade da CRL não estiver acessível, os certificados emitidos por uma autoridade de certificação (CA) pública não serão suportados. Para obter mais informações, consulte Recursos prejudicados ou indisponíveis em implantaçõ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 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)" 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.
- A senha para o certificado pfx deve ser uma senha complexa. Anote essa senha, porque você a usa 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
É suportada a presença de Autoridades de Certificação Intermediárias na cadeia de relações de confiança de um certificado.
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 ponto de extremidade é expresso no formato <prefix>.<region>.<fqdn>.
Na sua implantação, os valores <region> e <fqdn> devem corresponder à região e aos nomes de domínio externos que foram escolhidos para o 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 <prefix>.redmond.contoso.com. Os <prefix> valores são reservados pela Microsoft para descrever o ponto de extremidade protegido pelo certificado. Além disso, os <prefix> valores dos pontos de extremidade de infraestrutura externa dependem do serviço Azure Stack Hub que usa o ponto de extremidade específico.
Para 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 certificado único que abranja todos os terminais e serviços é uma postura insegura e, portanto, destina-se apenas ao desenvolvimento. Lembre-se, ambas as opções exigem que seja necessário utilizar certificados wildcard para pontos de extremidade, como acs e Key Vault, onde são 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 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.<region>.<fqdn> |
Portais | <region>.<fqdn> |
| Portal de administração | adminportal.<region>.<fqdn> |
Portais | <region>.<fqdn> |
| Azure Resource Manager Público | management.<region>.<fqdn> |
Azure Resource Manager | <region>.<fqdn> |
| Administrador do Azure Resource Manager | adminmanagement.<region>.<fqdn> |
Azure Resource Manager | <region>.<fqdn> |
| ACSBlob | *.blob.<region>.<fqdn>(Certificado SSL curinga) |
Armazenamento de Blobs | blob.<region>.<fqdn> |
| ACSTable | *.table.<region>.<fqdn>(Certificado SSL curinga) |
Armazenamento de mesas | table.<region>.<fqdn> |
| ACSQueue | *.queue.<region>.<fqdn>(Certificado SSL curinga) |
armazenamento de Filas | queue.<region>.<fqdn> |
| KeyVault | *.vault.<region>.<fqdn>(Certificado SSL curinga) |
Cofre de Chaves | vault.<region>.<fqdn> |
| KeyVaultInterno | *.adminvault.<region>.<fqdn>(Certificado SSL curinga) |
Keyvault interno | adminvault.<region>.<fqdn> |
| Host de extensão de administrador |
*.adminhosting.<region>.<fqdn> (Certificados SSL de wildcard) |
Host de extensão para administração | adminhosting.<region>.<fqdn> |
| Host de extensão pública |
*.hosting.<region>.<fqdn> (Certificados SSL de wildcard) |
Host de extensão pública | hosting.<region>.<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. 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 de assunto (SAN) necessários | Âmbito (por região) | Namespace do subdomínio |
|---|---|---|---|
| ADFS | adfs.<region>.<fqdn>(certificado SSL) |
AD FS | <region>.<fqdn> |
| Graph | graph.<region>.<fqdn>(certificado SSL) |
Graph | <region>.<fqdn> |
Importante
Todos os certificados listados nesta seção devem ter a mesma senha.
Certificados PaaS opcionais
Se você planeja 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 for 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 estes 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 Aplicações | Certificado SSL padrão para tráfego na Web | *.appservice.<region>.<fqdn>*.scm.appservice.<region>.<fqdn>*.sso.appservice.<region>.<fqdn>(Certificado SSL Wildcard multidomínio1) |
appservice.<region>.<fqdn>scm.appservice.<region>.<fqdn> |
| Serviço de Aplicações | API | api.appservice.<region>.<fqdn>(Certificado SSL2) |
appservice.<region>.<fqdn>scm.appservice.<region>.<fqdn> |
| Serviço de Aplicações | FTP | ftp.appservice.<region>.<fqdn>(Certificado SSL2) |
appservice.<region>.<fqdn>scm.appservice.<region>.<fqdn> |
| Serviço de Aplicações | SSO | sso.appservice.<region>.<fqdn>(Certificado SSL2) |
appservice.<region>.<fqdn>scm.appservice.<region>.<fqdn> |
| Hubs de Eventos | SSL | *.eventhub.<region>.<fqdn>(Certificado SSL Wildcard) |
eventhub.<region>.<fqdn> |
| SQL, MySQL | SQL e MySQL | *.dbadapter.<region>.<fqdn>(Certificado SSL Wildcard) |
dbadapter.<region>.<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 Um *.appservice.<region>.<fqdn> certificado coringa não pode ser usado no lugar desses três certificados (api.appservice.<region>.<fqdn>, ftp.appservice.<region>.<fqdn>, e sso.appservice.<region>.<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.