Início / coding / Perguntas / 79560141
Accepted
jamesfm
Asked: 2025-04-07 22:25:43 +0800 CST

Problema com o mesmo domínio personalizado com certificado gerenciado pelo Azure em um serviço de aplicativo e um ponto de extremidade do Front Door?

  • 772

Tenho um serviço de aplicativo com um domínio personalizado e um certificado gerenciado do Azure, que funciona bem há anos. Recentemente, adicionei um perfil do Front Door e, claro, adicionei o mesmo domínio personalizado a ele, com um certificado criado pelo Azure Front Door.

Nesse processo, os registros DNS do domínio foram atualizados para que o registro A agora seja um ALIAS para o recurso AFD, e o CNAME para www aponte para o ponto de extremidade do AFD.

Entretanto, recentemente o Azure relatou este erro no serviço de aplicativo:

Auto-Renewal Failed... for Apex domain we must have the A record mapped to the 
webapp IP. For subdomain, we must have CNAME mapped to the webapp name.

Isso parece implicar que, uma vez implantado o Front Door, o aplicativo web em si não poderá mais ter um domínio personalizado. Mas há um conselho da Microsoft online de que você deve "preservar o nome do host HTTP original entre um proxy reverso e seu aplicativo web de back-end".

A MS também afirma que

Para conexões HTTPS, o Azure Front Door espera que sua origem apresente um certificado de uma autoridade de certificação (CA) válida com um nome de assunto correspondente ao nome do host de origem.

Então estou confuso sobre como fazer isso. (Talvez eu tenha entendido errado.)

Posso ter um domínio personalizado com um certificado gerenciado do Azure no AFD e no serviço de aplicativo? Caso contrário, como posso seguir as práticas recomendadas para garantir que o nome do host HTTP original solicitado pelo usuário também corresponda ao nome do host do serviço de aplicativo?

1 respostas

  1. Best Answer

    O Front Door deve passar o cabeçalho do host original ( example.com) ao encaminhar a solicitação para o backend. A parte complicada é o TLS entre o Front Door e o App Service.

    • Você não precisa abrir mão do TLS entre o Front Door e o Serviço de Aplicativo, mas precisa garantir que o certificado fornecido pelo Serviço de Aplicativo corresponda ao cabeçalho do host enviado pelo Front Door. Como os certificados gerenciados pelo Azure no Serviço de Aplicativo exigem que o DNS aponte diretamente para o aplicativo, e o seu agora aponta para o Front Door, esses certificados não serão mais renovados automaticamente.

    Você tem duas maneiras de fazer isso.

    Use o domínio padrão do App Service:

    • Você pode definir o host de backend no Front Door para o nome de host padrão do aplicativo, como yourapp.azurewebsites.net. Dessa forma, o certificado TLS fornecido pelo App Service (que é sempre válido para azurewebsites.net) corresponderá à solicitação, e o Front Door ficará satisfeito.

    Nesse caso, você ainda preserva o cabeçalho do host original ( example.com) para que seu aplicativo se comporte como se a solicitação tivesse vindo daquele domínio.

    Exemplo de configuração:

    "backend": {
  "address": "yourapp.azurewebsites.net",
  "hostHeader": "example.com",
  "protocol": "Https"
}

    Isso evita a necessidade de gerenciar certificados manualmente.

    Use um certificado personalizado no App Service:

    • Se você realmente precisa que o Front Door se conecte ao App Service usando example.como nome do host (tanto no cabeçalho do host quanto no TLS SNI), o App Service deve apresentar um certificado TLS válido para example.com.

    Como os certificados gerenciados pelo Azure não funcionarão mais nesse caso, você precisará trazer seu próprio certificado (do Let's Encrypt, DigiCert, etc.), carregá-lo no App Service e vinculá-lo ao domínio personalizado.

    Isso lhe dá TLS completo durante todo o processo, mas agora você é responsável por renovar e gerenciar esse certificado.

    • 0

relate perguntas