Configurar o HTTPS num domínio personalizado do Front Door (clássico)
Importante
O Azure Front Door (clássico) será desativado em 31 de março de 2027. Para evitar qualquer interrupção do serviço, é importante migrar seus perfis do Azure Front Door (clássico) para a camada Azure Front Door Standard ou Premium até março de 2027. Para obter mais informações, consulte Aposentadoria (clássica) do Azure Front Door.
Este artigo mostra como habilitar o protocolo HTTPS para um domínio personalizado associado ao seu Front Door (clássico) na seção hosts frontend. Ao usar o protocolo HTTPS em seu domínio personalizado (por exemplo, https://www.contoso.com), você garante que seus dados confidenciais sejam entregues com segurança por meio de criptografia TLS/SSL quando enviados pela Internet. Quando seu navegador da Web está conectado a um site usando HTTPS, ele valida o certificado de segurança do site e verifica se emitido por uma autoridade de certificação legítima. Este processo fornece segurança e protege as suas aplicações Web contra ataques maliciosos.
O Azure Front Door dá suporte a HTTPS em um nome de host padrão do Front Door, por padrão. Por exemplo, se você criar uma porta frontal (como https://contoso.azurefd.net), o HTTPS será automaticamente habilitado para solicitações feitas ao https://contoso.azurefd.net. No entanto, depois de integrar o domínio personalizado 'www.contoso.com', você precisa habilitar adicionalmente o HTTPS para esse host frontend.
Alguns dos principais atributos da funcionalidade HTTPS personalizada são:
Sem custo extra: Não há custos para aquisição ou renovação de certificados e nenhum custo extra para o tráfego HTTPS.
Ativação simples: está disponível no portal do Azure o aprovisionamento de um clique. Também pode utilizar a API REST ou outras ferramentas de programador para ativar a funcionalidade.
Está disponível a gestão de certificados completa: todas as atividades de aprovisionamento e gestão de certificados são feitas por si. Os certificados são automaticamente provisionados e renovados antes da expiração, o que elimina os riscos de interrupção do serviço devido à expiração de um certificado.
Neste tutorial, irá aprender a:
- Ativar o protocolo HTTPS no domínio personalizado.
- Utilizar um certificado gerido por AFD
- Use seu próprio certificado, ou seja, um certificado TLS/SSL personalizado
- Validar o domínio
- Desativar o protocolo HTTPS no seu domínio personalizado
Nota
Recomendamos que utilize o módulo Azure Az do PowerShell para interagir com o Azure. Para começar, consulte Instalar o Azure PowerShell. Para saber como migrar para o módulo do Az PowerShell, veja Migrar o Azure PowerShell do AzureRM para o Az.
Pré-requisitos
Para poder concluir os passos neste tutorial, tem primeiro de criar um Front Door com, pelo menos, um domínio personalizado carregado. Para obter mais informações, veja Tutorial: Adicionar um domínio personalizado ao Front Door.
Certificados TLS/SSL
Para habilitar o protocolo HTTPS para entregar conteúdo com segurança em um domínio personalizado Front Door (clássico), você deve usar um certificado TLS/SSL. Você pode optar por usar um certificado que é gerenciado pelo Azure Front Door ou usar seu próprio certificado.
Opção 1 (predefinição): utilizar um certificado gerido pelo Front Door
Quando você usa um certificado gerenciado pelo Azure Front Door, o recurso HTTPS pode ser ativado com algumas alterações de configuração. O Azure Front Door lida completamente com tarefas de gerenciamento de certificados, como aquisição e renovação. Depois de ativar a funcionalidade, o processo é iniciado imediatamente. Se o domínio personalizado já estiver mapeado para o sistema anfitrião de font-end predefinido do Front Door ({hostname}.azurefd.net), não é necessária mais nenhuma ação. A Front Door processa os passos e conclui o seu pedido automaticamente. No entanto, se o domínio personalizado estiver mapeado noutro local, terá de utilizar o e-mail para validar a propriedade do domínio.
Para ativar o HTTPS num domínio personalizado, siga estes passos:
No portal do Azure, navegue até ao perfil Front Door.
Na lista de sistemas anfitrião de front-end, selecione o domínio personalizado no qual pretende ativar HTTPS para conter o seu domínio personalizado.
Na seção HTTPS de domínio personalizado, selecione Habilitado e selecione Front Door gerenciado como a fonte do certificado.
Selecione Guardar.
Continue a Validar o domínio.
Nota
- Para certificados gerenciados pelo Azure Front Door, o limite de 64 caracteres do DigiCert é imposto. A validação falhará se esse limite for excedido.
- Não há suporte para habilitar HTTPS via certificado gerenciado do Front Door para domínios apex/root (exemplo: contoso.com). Você pode usar seu próprio certificado para esse cenário. Para mais informações, continue com a opção 2.
Opção 2: utilizar o seu próprio certificado
Pode utilizar o seu próprio certificado para ativar a funcionalidade HTTPS. Este processo é efetuado através de uma integração com o Azure Key Vault, o que lhe permite armazenar os certificados de forma segura. O Azure Front Door utiliza este mecanismo seguro para obter o certificado e requer alguns passos adicionais. Ao criar seu certificado TLS/SSL, você deve criar uma cadeia de certificados completa com uma autoridade de certificação (CA) permitida que faz parte da Lista de CA Confiável da Microsoft. Se você usar uma autoridade de certificação não permitida, sua solicitação será rejeitada. Se for apresentado um certificado sem uma cadeia completa, os pedidos que envolvem esse certificado não serão garantidos como esperado.
Prepare o seu cofre de chaves e o certificado
Você deve ter uma conta de cofre de chaves na mesma assinatura do Azure que sua porta de entrada. Se não tiver uma, crie uma conta de cofre de chaves.
Aviso
Atualmente, o Azure Front Door só suporta contas do Key Vault na mesma subscrição que a configuração do Front Door. Escolher um Key Vault numa subscrição diferente do que o Front Door resultará numa falha.
Se o cofre de chaves tiver restrições de acesso à rede ativadas, terá de o configurar para permitir que os serviços Microsoft fidedignos ignorem a firewall.
O cofre de chaves deve ser configurado para usar o modelo de permissão de política de acesso do Cofre da Chave.
Se já tiver um certificado, pode carregá-lo diretamente para o cofre de chaves. Caso contrário, crie um novo certificado diretamente no Azure Key Vault a partir de uma das autoridades de certificação (ACs) parceiras em que o Azure Key Vault está integrado. Carregue seu certificado como um objeto de certificado , em vez de um segredo.
Nota
O Front Door não suporta certificados com algoritmos de criptografia de curva elíptica (EC). O certificado deve ter uma cadeia de certificados completa com certificados folha e intermediários, e a autoridade de certificação raiz deve fazer parte da lista de autoridades de certificação confiáveis da Microsoft.
Registar o Azure Front Door
Registre a entidade de serviço do Azure Front Door como um aplicativo em sua ID do Microsoft Entra usando o Azure PowerShell ou a CLI do Azure.
Nota
- Esta ação requer pelo menos permissões de função de Administrador de Aplicativos no Microsoft Entra ID. O registro só precisa ser realizado uma vez por locatário do Microsoft Entra.
- A ID do aplicativo é atribuída pelo Azure especificamente para o Azure Front Door (clássico).
- O Azure Front Door (clássico) tem uma ID de Aplicativo diferente da camada Standard/Premium do Azure Front Door.
- A função atribuída é apenas para a assinatura selecionada, a menos que você defina um escopo diferente.
Azure PowerShell
Caso seja necessário, instale o Azure PowerShell no PowerShell no seu computador local.
No PowerShell, execute o seguinte comando:
New-AzADServicePrincipal -ApplicationId "ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037"
CLI do Azure
Se necessário, instale a CLI do Azure em sua máquina local.
Na CLI, execute o seguinte comando:
az ad sp create --id ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037
Conceder ao Azure Front Door Service acesso ao Key Vault
Dê permissão ao Azure Front Door para aceder aos certificados na conta do Azure Key Vault.
Na conta do cofre de chaves, selecione Políticas de acesso.
Selecione Criar para criar uma nova política de acesso.
Em Permissões de segredos, selecione Obter para permitir ao Front Door obter o certificado.
Em Permissões de certificados, selecione Obter para permitir ao Front Door obter o certificado.
Em Selecionar principal, procure ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037 e selecione Microsoft.Azure.Frontdoor. Selecione Seguinte.
Em Aplicação, selecione Seguinte.
Em Rever + criar, selecione Criar.
Nota
Se o cofre de chaves estiver protegido com restrições de acesso à rede, certifique-se de permitir que serviços confiáveis da Microsoft acessem seu cofre de chaves.
O Azure Front Door agora pode acessar esse cofre de chaves e os certificados que ele contém.
Selecione o certificado que será implementado pelo Azure Front Door
Volte ao seu Front Door no portal.
Na lista de domínios personalizados, selecione o domínio personalizado no qual pretende ativar o HTTPS.
É apresentada a página Domínio personalizado.
Em Tipo de gestão de certificado, selecione Utilizar o meu próprio certificado.
O Azure Front Door exige que a subscrição da conta do Key Vault seja a mesma subscrição do Front Door. Selecione um cofre de chaves, um segredo e uma versão de segredo.
O Azure Front Door lista as seguintes informações:
- As contas do cofre de chaves do ID da sua subscrição.
- Os segredos no cofre de chaves selecionado.
- As versões dos segredos disponíveis.
Nota
Para que o certificado seja automaticamente alterado para a versão mais recente quando estiver disponível uma versão mais recente do certificado no seu Key Vault, defina a versão secreta como "Mais Recente". Se estiver selecionada uma versão específica, terá de selecionar novamente a nova versão manualmente para a rotação de certificados. Demora 72 a 96 horas para que a nova versão do certificado/segredo seja implementada.
Aviso
Este é um aviso apenas do portal do Azure. Você precisa configurar sua entidade de serviço para ter uma permissão GET no Cofre da Chave. Para que um usuário veja o certificado no menu suspenso do portal, a conta de usuário deve ter as permissões LIST e GET no Cofre da Chave. Se um usuário não tiver essas permissões, ele verá uma mensagem de erro inacessível no portal. Uma mensagem de erro inacessível não tem qualquer impacto na rotação automática do certificado ou em qualquer função HTTPS. Nenhuma ação é necessária para essa mensagem de erro se você não pretende fazer alterações no certificado ou na versão. Se quiser alterar as informações nesta página, consulte Fornecer permissão ao Cofre da Chave para adicionar sua conta à permissão LIST e GET do Cofre da Chave.
Quando utiliza o seu próprio certificado, a validação de domínio não é necessária. Avance para Aguardar pela propagação.
Validar o domínio
Se você já tiver um domínio personalizado em uso que seja mapeado para seu ponto de extremidade personalizado com um registro CNAME ou estiver usando seu próprio certificado, continue para Domínio personalizado é mapeado para sua porta da frente. Caso contrário, se a entrada de registro CNAME para seu domínio não existir mais ou contiver o subdomínio afdverify, continue para Domínio personalizado não está mapeado para sua porta da frente.
O domínio personalizado está mapeado para o Front Door por um registo CNAME
Quando adicionou um domínio personalizado aos sistemas anfitrião de front-end do Front Door, criou um registo CNAME na tabela de DNS da sua entidade de registo de domínios para mapeá-lo para o nome de anfitrião .azurefd.net predefinido do Front Door. Se esse registro CNAME ainda existir e não contiver o subdomínio afdverify, a Autoridade de Certificação DigiCert o usará para validar automaticamente a propriedade do seu domínio personalizado.
Se você estiver usando seu próprio certificado, a validação de domínio não será necessária.
O registo CNAME deve estar no seguinte formato, em que Nome é o nome do seu domínio personalizado e Valor é o nome de anfitrião .azurefd.net predefinido do Front Door:
| Nome | Tipo | valor |
|---|---|---|
| <www.contoso.com> | CNAME | contoso.azurefd.net |
Para obter mais informações sobre os registos CNAME, veja Criar o registo DNS CNAME.
Se o registo CNAME estiver no formato correto, DigiCert verifica o seu nome de domínio personalizado automaticamente e cria um certificado dedicado para o seu nome de domínio. A DigitCert não envia um e-mail de verificação e você não precisa aprovar sua solicitação. O certificado é válido por um ano e renovado automaticamente antes de expirar. Avance para Aguardar pela propagação.
Normalmente, a validação automática demora alguns minutos. Se não vir o seu domínio validado ao fim de uma hora, abra um pedido de suporte.
Nota
Se tiver um registo Autorização de Autoridade de Certificação (CAA) com o seu fornecedor de DNS, tem de incluir DigiCert como AC válida. O registo CAA permite aos proprietários de domínios especificar junto dos respetivos fornecedores de DNS que ACs têm autorização para emitir certificados para os seus domínios. Se uma AC receber um pedido de certificado para um domínio que tenha um registo CAA e essa AC não estiver listada como emissora autorizada, estará proibida de emitir o certificado para esse domínio ou subdomínio. Para obter informações sobre como gerir registos CAA, veja Manage CAA records (Gerir registos CAA). Para obter uma ferramenta de registo CAA, veja CAA Record Helper (Ajuda para Registos CAA).
O domínio personalizado não está mapeado para a sua porta da frente
Se a entrada do registo CNAME para o seu ponto final já não existir ou contiver o subdomínio afdverify, siga o resto das instruções neste passo.
Depois de ativar o HTTPS no domínio personalizado, a CA do DigiCert valida a propriedade do seu domínio ao contactar a entidade de registo do mesmo, de acordo com as respetivas informações de registo em WHOIS. O contacto é feito por endereço de e-mail (por predefinição) ou pelo número de telefone indicado no registo em WHOIS. Você deve concluir a validação do domínio antes que o HTTPS esteja ativo em seu domínio personalizado. Tem seis dias úteis para aprovar o domínio. As solicitações que não forem aprovadas dentro de seis dias úteis serão automaticamente canceladas. A validação de domínio DigiCert funciona no nível do subdomínio. Você precisa provar a propriedade de cada subdomínio separadamente.
A DigiCert também envia um e-mail de verificação para outros endereços de e-mail. Se as informações do registo em WHOIS forem privadas, confirme que pode aprovar diretamente a partir de um dos endereços seguintes:
admin@<your-domain-name.com> administrator@<your-domain-name.com> webmaster@<your-domain-name.com> hostmaster@<your-domain-name.com> postmaster@<your-domain-name.com>
Deverá receber um e-mail passados alguns minutos, semelhante ao seguinte exemplo, que lhe pede para aprovar o pedido. Se você estiver usando um filtro de spam, adicione no-reply@digitalcertvalidation.com à sua lista de permissões. Em determinados cenários, a DigiCert poderá não conseguir obter os contactos do domínio a partir das informações do registante WHOIS para lhe enviar um e-mail. Se não receber um e-mail passadas 24 horas, contacte o suporte da Microsoft.
Ao selecionar o link de aprovação, você será direcionado para um formulário de aprovação online. Siga as instruções do formulário; tem duas opções de verificação:
Pode aprovar todas as encomendas futuras feitas através da mesma conta para o mesmo domínio de raiz; por exemplo, contoso.com. Essa abordagem é recomendada se você planeja adicionar mais domínios personalizados para o mesmo domínio raiz.
Pode aprovar apenas o nome de anfitrião específico utilizado neste pedido. É necessária uma aprovação adicional para pedidos subsequentes.
Após a aprovação, a DigiCert conclui a criação do certificado para o seu nome de domínio personalizado. O certificado é válido durante um ano. Se o registro CNAME do seu domínio personalizado for adicionado ou atualizado para mapear para o nome de host padrão do Azure Front Door após a verificação, ele será renovado automaticamente antes de expirar.
Nota
A renovação automática de certificados gerenciados requer que seu domínio personalizado seja mapeado diretamente para o nome de host .azurefd.net padrão do Front Door por um registro CNAME.
Aguardar pela propagação
Após a validação do nome de domínio, a ativação da funcionalidade HTTPS no domínio personalizado pode demorar entre 6 a 8 horas. Quando o processo estiver concluído, o estado do HTTPS personalizado no portal do Azure é definido como Ativado e os quatro passos da operação na caixa de diálogo de domínio personalizado são marcados como concluídos. O seu domínio personalizado está agora pronto para utilizar o HTTPS.
Progresso da operação
A tabela seguinte mostra o progresso da operação que ocorre quando ativa o HTTPS. Depois de ativar o HTTPS, aparecem quatro passos da operação na caixa de diálogo do domínio personalizado. À medida que cada etapa se torna ativa, mais detalhes da subetapa aparecem sob a etapa à medida que ela progride. Nem todas essas subetapas ocorrem. Depois da conclusão bem-sucedida de um passo, aparece uma marca de verificação verde junto ao mesmo.
| Passo da operação | Detalhes do subpasso da operação |
|---|---|
| 1. Apresentação do pedido | Submeter o pedido |
| O seu pedido HTTPS está a ser submetido. | |
| O seu pedido HTTPS foi submetido com êxito. | |
| 2. Validação do domínio | O domínio é validado automaticamente se for CNAME mapeado para o host frontend .azurefd.net padrão da sua porta da frente. Caso contrário, é enviado um pedido de verificação para o e-mail listado no registo do seu domínio (registante WHOIS). Verifique o domínio assim que possível. |
| A propriedade do domínio foi validada com êxito. | |
| O pedido de validação da propriedade do domínio expirou (é provável que o cliente não tenha respondido em seis dias). HTTPS não será ativado no seu domínio. * | |
| Solicitação de validação de propriedade de domínio rejeitada pelo cliente. HTTPS não será ativado no seu domínio. * | |
| 3. Aprovisionamento de certificados | A autoridade de certificação está a emitir o certificado necessário para ativar o HTTPS no seu domínio. |
| O certificado foi emitido e está a ser implementado no Front Door. Esse processo pode levar de vários minutos a uma hora para ser concluído. | |
| O certificado foi implementado com êxito no Front Door. | |
| 4. Completo | O HTTPS foi ativado com êxito no seu domínio. |
* Esta mensagem não aparece a menos que tenha ocorrido um erro.
Se ocorrer um erro antes de o pedido ser submetido, será apresentada a seguinte mensagem de erro:
We encountered an unexpected error while processing your HTTPS request. Please try again and contact support if the issue persists.
Perguntas mais frequentes
Quem é o fornecedor do certificado e que tipo de certificado é utilizado?
Um certificado dedicado/individual, fornecido pela Digicert, é utilizado para o seu domínio personalizado.
Utiliza TLS/SSL baseado em IP ou em SNI?
O Azure Front Door usa SNI TLS/SSL.
E se não receber o e-mail de verificação do domínio da DigiCert?
Se você tiver uma entrada CNAME para seu domínio personalizado que aponte diretamente para seu nome de host do ponto de extremidade (e não estiver usando o nome de subdomínio afdverify), não receberá um e-mail de verificação de domínio. A validação ocorre automaticamente. Caso contrário, se não tiver uma entrada CNAME e não tiver recebido um e-mail passadas 24 horas, contacte o suporte da Microsoft.
A utilização de um certificado SAN é mais insegura do que um certificado dedicado?
Os certificados SAN seguem as mesmas normas de encriptação e segurança dos certificados dedicados. Todos os certificados TLS/SSL emitidos usam SHA-256 para maior segurança do servidor.
Preciso de um registo Autorização de Autoridade de Certificação junto do meu fornecedor de DNS?
Não, um registro de Autorização da Autoridade de Certificação não é necessário no momento. No entanto, se tiver um, o mesmo tem de incluir a DigiCert como AC válida.
Clean up resources (Limpar recursos)
Nos passos anteriores, ativou o protocolo HTTPS no seu domínio personalizado. Se você não quiser mais usar seu domínio personalizado com HTTPS, poderá desabilitar o HTTPS seguindo estas etapas:
Desativar a funcionalidade HTTPS
No portal do Azure, navegue até sua configuração do Azure Front Door.
Na lista de hosts frontend, selecione o domínio personalizado para o qual você deseja desabilitar o HTTPS.
Selecione Desativado para desativar o HTTPS e, em seguida, selecione Salvar.
Aguardar pela propagação
A desativação da funcionalidade HTTPS no domínio personalizado pode demorar entre 6 a 8 horas a ter efeito. Quando o processo é concluído, o status HTTPS personalizado no portal do Azure é definido como Desabilitado e as três etapas de operação na caixa de diálogo de domínio personalizado são marcadas como concluídas. O domínio personalizado já não pode utilizar o HTTPS.
Progresso da operação
A tabela seguinte mostra o progresso da operação que ocorre quando desativa o HTTPS. Depois de desativar o HTTPS, aparecem três passos da operação na caixa de diálogo Domínio personalizado. À medida que cada etapa se torna ativa, mais detalhes aparecem sob a etapa. Depois da conclusão bem-sucedida de um passo, aparece uma marca de verificação verde junto ao mesmo.
| Progresso da operação | Detalhes da operação |
|---|---|
| 1. Apresentação do pedido | Submeter o pedido |
| 2. Desaprovisionamento de certificados | Eliminar o certificado |
| 3. Completo | Certificado eliminado |
Próximos passos
Para saber como configurar uma política de filtragem geográfica para a sua Porta da Frente, continue para o próximo tutorial.