Configurar o HTTPS em um domínio personalizado 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 que você migre 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 Desativação do Azure Front Door (clássico).
Este artigo mostra como habilitar o protocolo HTTPS para um domínio personalizado que está associado ao seu Front Door (clássico) na seção de hosts de front-end. Usando o protocolo HTTPS no domínio personalizado (por exemplo, https://www.contoso.com), você garante que os seus dados confidenciais sejam entregues com segurança pela criptografia TLS/SSL quando forem enviados na Internet. Quando seu navegador da Web é conectado a um site da Web usando HTTPS, ele valida o certificado de segurança do site da Web e verifica se ele é emitido por uma autoridade de certificação legítima. Esse processo oferece segurança e protege seus aplicativos Web contra ataques mal-intencionados.
O Azure Front Door dá suporte a HTTPS em um nome do host padrão do Front Door, por padrão. Por exemplo, se você criar um Front Door (como https://contoso.azurefd.net), o HTTPS será habilitado automaticamente para solicitações feitas a https://contoso.azurefd.net. No entanto, depois de integrar o domínio personalizado "www.contoso.com", é necessário habilitar adicionalmente o HTTPS para esse host de front-end.
Alguns dos principais atributos do recurso HTTPS são:
Sem custo adicional: não há nenhum custo para a aquisição ou a renovação do certificado e nenhum custo adicional para o tráfego HTTPS.
Habilitação simples: o provisionamento com um clique está disponível no portal do Azure. Você também pode usar a API REST ou outras ferramentas de desenvolvedor para habilitar o recurso.
Gerenciamento de certificado completo disponível: todos os certificados de aquisição e gerenciamento são manipulados para você. Os certificados são provisionados e renovados automaticamente antes da expiração, o que remove os riscos de interrupção do serviço devido à expiração de um certificado.
Neste tutorial, você aprenderá como:
- Habilite o protocolo HTTPS em seu domínio personalizado.
- Usar um certificado gerenciado por AFD
- Usar seu certificado, ou seja, um certificado TLS/SSL personalizado
- Validar o domínio
- Desabilitar o protocolo HTTPS em seu domínio personalizado
Observação
Recomendamos que você use o módulo Az PowerShell do Azure para interagir com o Azure. Confira Instalar o Azure PowerShell para começar. Para saber como migrar para o módulo Az PowerShell, confira Migrar o Azure PowerShell do AzureRM para o Az.
Pré-requisitos
Antes de concluir as etapas deste tutorial, crie primeiro um Front Door e integre pelo menos um domínio personalizado. Para saber mais, confira Tutorial: Adicionar um domínio personalizado ao seu Front Door.
Certificados TLS/SSL
Para habilitar o protocolo HTTPS para fornecer com segurança o conteúdo em um domínio personalizado do 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 (padrão): usar um certificado gerenciado pelo Front Door
Quando você usa um certificado gerenciado pelo Azure Front Door, o recurso HTTPS pode ser ativado com algumas mudanças de configuração. O Azure Front Door lida completamente com tarefas de gerenciamento de certificado, como aquisição e renovação. Depois que você habilitar o recurso, o processo será iniciado imediatamente. Se o domínio personalizado já estiver mapeado para o host de front-end padrão do Front Door ({hostname}.azurefd.net), nenhuma ação adicional será necessária. O Front Door processa as etapas e conclui a solicitação automaticamente. No entanto, se o domínio personalizado for mapeado em outro lugar, você deverá usar o email para validar sua propriedade de domínio.
Para habilitar HTTPS em um domínio personalizado, siga estas etapas:
No portal do Azure, navegue até seu perfil do Front Door.
Na lista de hosts de front-end, selecione o domínio personalizado para o qual deseja habilitar o HTTPS, contendo seu domínio personalizado.
Na seção HTTPS do domínio personalizado, selecione Habilitado e Gerenciado pelo Front Door como a origem do certificado.
Selecione Salvar.
Prossiga para Validar o domínio.
Observação
- Para os certificados gerenciados do 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 a habilitação de HTTPS por meio do certificado gerenciado pelo Front Door em domínios ápice/raiz (exemplo: contoso.com). Você pode usar um certificado próprio para esse cenário. Prossiga com a Opção 2 para obter mais detalhes.
Opção 2: Usar o seu próprio certificado
Você pode usar seu próprio certificado para habilitar o recurs HTTPS. Esse processo é feito por meio de uma integração com o Azure Key Vault, que permite que você armazene os certificados com segurança. O Azure Front Door usa esse mecanismo seguro para obter o certificado e exige algumas etapas extras. Ao criar seu certificado TLS/SSL, você precisa criar uma cadeia de certificados completa com uma AC (autoridade de certificação) permitida que faz parte da Lista de ACs Confiáveis da Microsoft. Se você usar uma CA não permitida, sua solicitação será rejeitada. Se um certificado sem cadeia completa é apresentado, não há garantia de que as solicitações que envolvem esse certificado funcionem conforme o esperado.
Preparar o cofre de chaves e o certificado digital
Você deve ter uma conta no cofre de chaves da mesma assinatura do Azure que o seu front door. Crie uma conta do cofre de chaves, caso não tenha uma.
Aviso
No momento, o Azure Front Door oferece suporte apenas a contas do Key Vault na mesma assinatura que a configuração do Front Door. Se você escolher um Key Vault com uma assinatura diferente do Front Door, ocorrerá uma falha.
Se o cofre de chaves estiver com restrições habilitadas para o acesso à rede, você deverá configurar o cofre de chaves para permitir que serviços confiáveis da Microsoft ignorem o firewall.
Seu cofre de chaves deve estar configurado para usar o modelo de permissão de política de acesso do Key Vault.
Se você já tiver um certificado, carregue-o diretamente no cofre de chaves. Caso contrário, crie diretamente pelo Azure Key Vault um certificado de uma das Autoridades de certificação parceiras com que o Azure Key Vault se integra. Faça upload do certificado como um objeto certificate, em vez de um secret.
Observação
O Front Door não dá suporte a certificados com algoritmos de criptografia de EC (curva elíptica). O certificado precisa ter uma cadeia de certificados completa com certificados de folha e intermediários, e a AC raiz precisa fazer parte da lista de ACs confiáveis da Microsoft.
Registrar o Azure Front Door
Registre a entidade de serviço do Azure Front Door como um aplicativo no Microsoft Entra ID usando o Azure PowerShell ou a CLI do Azure.
Observação
- Essa ação requer pelo menos permissões de função de Administrador de Aplicativos no Microsoft Entra ID. O registro só precisa ser executado 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
Se for necessário, instale o Azure PowerShell no PowerShell em 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 no computador local.
Na CLI, execute o seguinte comando:
az ad sp create --id ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037
Conceder acesso ao seu cofre de chaves para o Azure Front Door
Conceda permissão ao Azure Front Door para acessar os certificados na sua conta do Azure Key Vault.
Em sua conta do cofre de chaves, selecione Políticas de acesso.
Selecione Criar para criar uma política de acesso.
Em Permissões do segredo, selecione Obter para permitir que o Front Door recupere o certificado.
Em Permissões do certificado, selecione Obter para permitir que o Front Door recupere o certificado.
Em Selecionar entidade de segurança, pesquise por ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037 e selecione Microsoft.Azure.Frontdoor. Selecione Avançar.
Em Aplicativo, selecione Avançar.
Em Examinar + criar, clique em Criar.
Observação
Se o cofre de chaves estiver protegido com restrições de acesso à rede, verifique se os serviços confiáveis da Microsoft têm permissão para acessar seu cofre de chaves.
Agora o Azure Front Door pode acessar este cofre de chaves e os certificados armazenados nele.
Selecionar o certificado para o Azure Front Door a implantar
Retorne ao seu Front Door no portal.
Na lista de domínios personalizados, selecione o domínio personalizado para o qual você deseja habilitar o HTTPS.
A página de Domínio personalizado é exibida.
Em Tipo de gerenciamento de certificado, selecione Usar meu próprio certificado.
O Azure Front Door exige que a assinatura da conta do Key Vault seja igual à do Front Door. Selecione um cofre de chaves, um segredo e a versão do segredo.
O Azure Front Door contém as informações a seguir:
- As contas do Key Vault para sua ID de assinatura.
- Os segredos no cofre de chaves selecionado.
- As versões do segredo disponíveis.
Observação
Para que o certificado seja alternado automaticamente para a última versão quando uma versão mais recente do certificado estiver disponível no Key Vault, defina a versão do segredo como 'Mais recente'. Se uma versão específica for selecionada, você precisará selecionar novamente a nova versão manualmente para a rotação do certificado. Leva de 72 a 96 horas para que a nova versão do certificado/do segredo seja implantada.
Aviso
Este é um aviso somente no portal do Azure. Você precisa configurar sua entidade de serviço para ter uma permissão GET no Key Vault. Para que um usuário veja o certificado na lista suspensa do portal, a conta de usuário precisa ter permissões LIST e GET no Key Vault. Se um usuário não tiver essas permissões, ele verá uma mensagem de erro de falta de acesso no portal. Uma mensagem de erro de falta de acesso não tem nenhum impacto na rotação automática do certificado ou em alguma função HTTPS. Nenhuma ação será necessária para essa mensagem de erro se você não pretende fazer alterações no certificado ou na versão. Se você quiser alterar as informações nessa página, confira Conceder permissão para Key Vault a fim de adicionar sua conta à permissão LIST e GET do Key Vault.
Quando você usa um certificado próprio, a validação de domínio não é necessária. Prossiga para Aguardar a propagação.
Validar o domínio
Se você já tiver um domínio personalizado em uso que é mapeado para o ponto de extremidade personalizado com um registro CNAME ou se estiver usando um certificado próprio, prossiga para O domínio personalizado é mapeado para o Front Door. Caso contrário, se a entrada de registro CNAME para o domínio não existir mais ou contiver o subdomínio afdverify, prossiga para O domínio personalizado não é mapeado para o Front Door.
O domínio personalizado está mapeado para o Front Door por registro CNAME
Quando adiciona um domínio personalizado aos hosts de front-end do Front Door, você cria um registro CNAME na tabela DNS do seu registrador de domínios para mapeá-lo para o nome do host .azurefd.net padrão do Front Door. Se esse registro CNAME ainda existir e não contiver o subdomínio afdverify, a autoridade de certificação DigiCert vai utilizá-lo para validar automaticamente a propriedade do seu domínio personalizado.
Se você estiver usando um certificado próprio, a validação de domínio não será necessária.
O registro CNAME deve estar no formato a seguir, em que Nome é o nome de domínio personalizado e Valor é o nome de host .azurefd.net padrão do Front Door:
| Nome | Tipo | Valor |
|---|---|---|
| <www.contoso.com> | CNAME | contoso.azurefd.net |
Para obter mais informações sobre os registros CNAME, consulte criar o registro de DNS CNAME.
Se o registro CNAME estiver no formato correto, o DigiCert verificará automaticamente seu nome de domínio personalizado e criará um certificado dedicado ao seu nome de domínio. O DigitCert não envia um email 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. Prossiga para Aguardar a propagação.
A validação automática geralmente demora alguns minutos. Se você não vir seu domínio validado em uma hora, abra um tíquete de suporte.
Observação
Caso você tenha um registro de CAA (Autorização de Autoridade de Certificação) com o provedor DNS, ele deverá incluir o DigiCert como uma AC válida. Um registro de CAA permite que os proprietários do domínio especifiquem com seus provedores DNS quais ACs estão autorizadas a emitir certificados para seus domínios. Se uma AC receber um pedido de um certificado para um domínio que tem um registro de CAA e a AC não estiver listada como um emissor autorizado, ela será proibida de emitir o certificado para esse domínio ou subdomínio. Para obter informações sobre como gerenciar registros CAA, consulte Gerenciar registros CAA. Para uma ferramenta de registro CAA, consulte Ajuda do registro CAA.
O domínio personalizado não está mapeado para o Front Door
Se a entrada do registro CNAME do ponto de extremidade não existir mais ou contiver o subdomínio afdverify, siga o restante das instruções nesta etapa.
Depois de habilitar o HTTPS em seu domínio personalizado, a autoridade de certificação (CA) do DigiCert valida a propriedade de seu domínio entrando em contato com o inscrito, de acordo com as informações do inscrito WHOIS do domínio. O contato é feito pelo endereço de email (por padrão) ou pelo número de telefone listado no registro WHOIS. Conclua a validação completa de domínio antes de ativar o HTTPS no seu domínio personalizado. Você tem seis dias úteis para aprovar o domínio. As solicitações que não foram aprovadas em até seis dias úteis são canceladas automaticamente. A validação de domínio do DigiCert funciona no nível do subdomínio. Você precisa provar a propriedade de cada subdomínio separadamente.
O DigiCert também envia um email de verificação para outros endereços de email. Se as informações do inscrito WHOIS forem particulares, verifique se é possível aprovar diretamente por meio de um dos seguintes endereços:
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>
Você deverá receber um email em poucos minutos, semelhante ao exemplo a seguir, solicitando que você aprove a solicitação. Caso você esteja usando um filtro de spam, adicione no-reply@digitalcertvalidation.com à lista de permitidos. Em determinados cenários, o DigiCert pode não conseguir buscar os contatos de domínio das informações do registro WHOIS para enviar um email para você. Se você não receber um email em até 24 horas, contate o suporte da Microsoft.
Quando você selecionar o link de aprovação, será direcionado para um formulário de aprovação online. Siga as instruções do formulário; você tem duas opções de verificação:
Você pode aprovar todos os pedidos futuros feitos por meio da mesma conta para o mesmo domínio raiz; por exemplo, contoso.com. Essa abordagem é recomendada se você pretende adicionar mais domínios personalizados ao mesmo domínio raiz.
Você pode aprovar apenas o nome do host específico usado nesta solicitação. Uma aprovação extra é necessária para as solicitações seguintes.
Após a aprovação, o DigiCert conclui a criação do certificado para seu nome de domínio personalizado. O certificado é válido por um ano e é renovado automaticamente antes de expirar.
Aguardar a propagação
Depois da validação do nome de domínio, é necessário de 6 a 8 horas para a ativação do recurso HTTPS de domínio personalizado. Quando o processo for concluído, o status HTTPS Personalizado no portal do Azure será definido como Habilitado e as quatro etapas da operação da caixa de diálogo do domínio personalizado serão marcadas como concluídas. Seu domínio personalizado agora está pronto para usar o HTTPS.
Andamento da operação
A tabela a seguir mostra o andamento da operação que ocorre quando você habilita o HTTPS. Depois de habilitar o HTTPS, quatro etapas de operação são exibidas na caixa de diálogo do domínio personalizado. À medida que cada etapa fica ativa, mais detalhes da subetapa são exibidos na etapa conforme ela avança. Nem todas essas subetapas ocorrem. Depois que uma etapa for concluída com êxito, uma marca de seleção verde é exibida ao lado dela.
| Etapa da operação | Detalhes da subetapa da operação |
|---|---|
| 1. Enviando a solicitação | Enviando a solicitação |
| Sua solicitação HTTPS está sendo enviada. | |
| Sua solicitação HTTPS foi enviada com êxito. | |
| 2. Validação de domínio | O domínio será validado automaticamente se o CNAME estiver mapeado para o host de front-end .azurefd.net padrão do Front Door. Caso contrário, uma solicitação de verificação é enviada ao email listado no registro do seu domínio (WHOIS inscrito). Verifique o domínio assim que possível. |
| Sua propriedade do domínio foi validada com êxito. | |
| A solicitação de validação da propriedade do domínio expirou (provavelmente, o cliente não respondeu dentro de 6 dias). O HTTPS não será habilitado no domínio. * | |
| Solicitação de validação da propriedade do domínio rejeitada pelo cliente. O HTTPS não será habilitado no domínio. * | |
| 3. Provisionamento de certificado | No momento, a autoridade de certificação está emitindo o certificado necessário para habilitar o HTTPS em seu domínio. |
| O certificado foi emitido e está sendo implantado para o Front Door. Esse processo pode levar de vários minutos a uma hora para ser concluído. | |
| O certificado foi implantado com êxito no Front Door. | |
| 4. Concluído | O HTTPS foi habilitado com êxito em seu domínio. |
* Essa mensagem não é exibida a menos que tenha ocorrido um erro.
Se ocorrer um erro antes que a solicitação seja enviada, a seguinte mensagem de erro será exibida:
We encountered an unexpected error while processing your HTTPS request. Please try again and contact support if the issue persists.
Perguntas frequentes
Quem é o provedor de certificado e que tipo de certificado é usado?
Um certificado dedicado/único, fornecido pela DigiCert, é usado para seu domínio personalizado.
Você usa TLS/SSL de SNI ou baseado em IP?
O Azure Front Door usa TLS/SSL de SNI.
E se eu não receber o email de verificação de domínio do DigiCert?
Se você tiver uma entrada CNAME para seu domínio personalizado que aponte diretamente para o nome do host do ponto de extremidade (e não estiver usando o nome de subdomínio afdverify), você não receberá um email de verificação de domínio. A validação ocorre automaticamente. Caso contrário, se você não tem uma entrada CNAME e você ainda não recebeu um email em até 24 horas, entre em contato com o suporte da Microsoft.
Usar um certificado SAN é menos seguro do que um certificado dedicado?
Um certificado SAN segue os mesmos padrões de criptografia e segurança de um certificado dedicado. Todos os certificados TLS/SSL emitidos usam SHA-256 para uma maior segurança do servidor.
É necessário ter um registro de Autorização de Autoridade de Certificação em meu provedor DNS?
Não. No momento, nenhum registro de Autorização de Autoridade de Certificação é necessário. No entanto, caso você tenha um, ele deverá incluir o DigiCert como uma AC válida.
Limpar os recursos
Nas etapas anteriores, você habilitou o protocolo HTTPS em seu domínio personalizado. Se você não deseja mais usar seu domínio personalizado com o HTTPS, desabilite o HTTPS executando estas etapas:
Desabilitar o recurso HTTPS
No portal do Azure, navegue até a configuração do Azure Front Door.
Na lista de hosts de front-end, selecione o domínio personalizado no qual deseja desabilitar o HTTPS.
Selecione Desabilitado para desabilitar o HTTPS e, em seguida, selecione Salvar.
Aguardar a propagação
Depois que o recurso HTTPS do domínio personalizado for desabilitado, poderá levar até 6-8 horas para que ele entre em vigor. Quando o processo for concluído, o status do HTTPS personalizado no portal do Azure será definido como Desabilitado e as três etapas da operação da caixa de diálogo do domínio personalizado serão marcadas como concluídas. Seu domínio personalizado não pode mais usar o HTTPS.
Andamento da operação
A tabela a seguir mostra o andamento da operação que ocorre quando você desabilita o HTTPS. Depois de desabilitar o HTTPS, três etapas de operação são exibidas na caixa de diálogo Domínio personalizado. À medida que cada etapa fica ativa, mais detalhes são exibidos na etapa. Depois que uma etapa for concluída com êxito, uma marca de seleção verde é exibida ao lado dela.
| Andamento da operação | Detalhes da operação |
|---|---|
| 1. Enviando a solicitação | Enviando a solicitação |
| 2. Desprovisionamento de certificado | Excluindo o certificado |
| 3. Concluído | Certificado excluído |
Próximas etapas
Para saber como configurar uma política de filtragem geográfica para o Front Door, prossiga para o próximo tutorial.