Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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 traz 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 adição de valor.
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 adicionando esse certificado ao repositório de certificados local. Não há nenhuma fixação ou filtragem de certificados no Azure Stack Hub. O SAN de cada certificado do servidor é validado contra o 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 base do sistema operacional 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. Para implantações desconectadas, se o ponto de extremidade CRL não estiver acessível, certificados emitidos por uma autoridade de certificação pública (CA) não são suportados. Para obter mais informações, consulte Recursos que estão prejudicados ou indisponíveis em implantações desconectadas.
- Ao rotacionar certificados em builds pré-1903, os certificados devem ser emitidos pela mesma autoridade de certificação interna usada para assinar os certificados fornecidos na implantação ou por qualquer autoridade de certificação pública reconhecida.
- Ao realizar a rotação de certificados para builds 1903 e posteriores, os certificados podem ser emitidos por qualquer autoridade de certificação empresarial ou pública.
- Não há suporte para certificados autoassinados.
- Para implantação e rotação, você pode usar um único certificado que abrange todos os espaços de nome no Nome da Entidade e no Nome Alternativo da Entidade (SAN) 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 os 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ú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 repositório de certificados do Windows Server 2016).
- Os arquivos pfx do certificado devem ter um valor "Assinatura Digital" e "KeyEncipherment" em seu campo "Uso de chave".
- Os arquivos pfx de certificado devem ter os valores "Autenticação de Servidor (1.3.6.1.5.5.7.3.1)" no campo "Uso avançado de 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, pois 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, caracteres alfabéticos que não são maiúsculas ou minúsculas.
- 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 de nome alternativo do sujeito permite que você defina 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 que você use 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 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 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 <prefix>.<region>.<fqdn>.
Para sua implantação, os valores <region> e <fqdn> devem corresponder à região e aos nomes de domínio externos escolhidos para o 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 do 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 curinga que abrange todos os namespaces nos campos Subject e Subject Alternative Name (SAN) copiados em todos os diretórios. Um único certificado que cobre todos os endpoints e serviços é uma postura insegura e, portanto, deve ser usado apenas para desenvolvimento. Lembre-se de que ambas as opções exigem que você use certificados curinga para pontos de extremidade, como acs e Key Vault, sempre que necessário.
Observação
Durante a implantação, você deve copiar certificados para a pasta de implantação que corresponde ao provedor de identidade no qual você está implantando (ID do Microsoft Entra 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 requerido e nomes alternativos do assunto (SAN) | Escopo (por região) | Namespace de 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 tabela | 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> |
| KeyVaultInternal | *.adminvault.<region>.<fqdn>(Certificado SSL curinga) |
Keyvault interno | adminvault.<region>.<fqdn> |
| Host de Extensão de Administrador |
*.adminhosting.<region>.<fqdn> (Certificados SSL curinga) |
Host de extensão administrativa | adminhosting.<region>.<fqdn> |
| Host de Extensão Pública |
*.hosting.<region>.<fqdn> (Certificados SSL curinga) |
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 requerido e nomes alternativos do assunto (SAN) | Escopo (por região) | Namespace de 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 de PaaS do Azure Stack Hub (como SQL, MySQL, Serviço de Aplicativo ou Hubs de Eventos) depois que o Azure Stack Hub é implantado e configurado, você deve 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 abaixo descreve os endpoints e certificados necessários para os 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 | Assunto do certificado necessário e nomes alternativos de assunto (SANs) | Namespace de subdomínio |
|---|---|---|---|
| Serviço de Aplicativo | Certificado SSL padrão para tráfego web | *.appservice.<region>.<fqdn>*.scm.appservice.<region>.<fqdn>*.sso.appservice.<region>.<fqdn>(Certificado SSL curinga para vários domínios1) |
appservice.<region>.<fqdn>scm.appservice.<region>.<fqdn> |
| Serviço de Aplicativo | API | api.appservice.<region>.<fqdn>(Certificado SSL2) |
appservice.<region>.<fqdn>scm.appservice.<region>.<fqdn> |
| Serviço de Aplicativo | FTP | ftp.appservice.<region>.<fqdn>(Certificado SSL2) |
appservice.<region>.<fqdn>scm.appservice.<region>.<fqdn> |
| Serviço de Aplicativo | SSO | sso.appservice.<region>.<fqdn>(Certificado SSL2) |
appservice.<region>.<fqdn>scm.appservice.<region>.<fqdn> |
| Hubs de Eventos | SSL | *.eventhub.<region>.<fqdn>(Certificado SSL Curinga) |
eventhub.<region>.<fqdn> |
| SQL, MySQL | SQL e MySQL | *.dbadapter.<region>.<fqdn>(Certificado SSL Curinga) |
dbadapter.<region>.<fqdn> |
1 Requer um certificado com vários nomes alternativos de assunto curinga. Várias SANs curinga em um único certificado podem não ter suporte de todas as autoridades de certificação públicas.
2 Um *.appservice.<region>.<fqdn> certificado curinga 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 requer explicitamente o uso de certificados distintos para esses pontos de extremidade.
Próximas etapas
Saiba como gerar certificados PKI para implantação do Azure Stack Hub.