Short answer
On Azure you typically terminate TLS on an Application Gateway (regional L7 load balancer) or Front Door (global edge/CDN). Both can use managed certificates that Azure issues and renews automatically, or your own certificates from Key Vault. A listener binds a certificate to a hostname and port. If you want encryption all the way to the backend, you enable end-to-end TLS (re-encryption).
Application Gateway: listeners and certificates
Application Gateway terminates TLS in an HTTPS listener that binds a certificate to a hostname and port 443. Traffic is then forwarded to a backend pool via an HTTP setting. The certificate can either be uploaded directly or — recommended — referenced from Azure Key Vault so renewal can be automated:
# Listener certificate from Key Vault (CLI sketch) az network application-gateway ssl-cert create \ --gateway-name appgw \ --resource-group rg \ --name web-cert \ --key-vault-secret-id "https://myvault.vault.azure.net/secrets/web-cert"
If you reference Key Vault, Application Gateway automatically pulls the latest version of the certificate, so a rotation in Key Vault propagates without manual intervention (with a few minutes' delay).
End-to-end TLS on Application Gateway
By default the connection from gateway to backend is unencrypted (offloading). If you enable end-to-end TLS, the gateway does bridging: it terminates the client's TLS and opens a new HTTPS connection to the backend. The backend must then have its own certificate, and the gateway's HTTP setting is configured to trust it (a known root or an explicit backend certificate). The internal backend certificate is the one most often forgotten.
Front Door: managed certificates and custom domains
Front Door is Microsoft's global edge platform. You add a custom domain, validate ownership via a DNS TXT record, and choose either an Azure managed certificate (free, renewed automatically) or your own from Key Vault:
# Add custom domain with a managed certificate (CLI sketch) az afd custom-domain create \ --resource-group rg \ --profile-name fd-profile \ --custom-domain-name www-example \ --host-name www.example.com \ --certificate-type ManagedCertificate \ --minimum-tls-version TLS12
Managed certificates are renewed by Azure as long as the DNS validation remains valid. If you use a CNAME towards Front Door, validation requires a _dnsauth TXT record to exist — remove it and automatic renewal can fail silently.
Offloading vs end-to-end on Azure
| Scenario | Front certificate | Backend certificate |
|---|---|---|
| Termination only (offloading) | On gateway/Front Door | None (HTTP to backend) |
| End-to-end TLS (bridging) | On gateway/Front Door | On backend (must be monitored) |
What Azure does not tell you
Managed certificates renew themselves — until the DNS validation breaks, a custom domain loses its TXT record, or a backend certificate under end-to-end TLS expires without anyone watching. The Azure portal shows status per resource, but rarely a single picture across gateways, Front Door profiles and backends. CertControl scans all of your Azure-fronted domains from the outside, sees the actual expiry date and chain, and warns you in good time — including for the internal backend certificates. See the ACME pillar and how other platforms handle it on F5 BIG-IP.
Frequently asked questions
What is the difference between Application Gateway and Front Door?
Application Gateway is a regional L7 load balancer in a single Azure region. Front Door is a global edge/CDN service that terminates TLS close to the user worldwide. Both terminate TLS, but at different levels in the architecture.
What is a listener on Application Gateway?
A listener binds a certificate to a specific hostname and port (typically 443). It decides which certificate is served for which domain before traffic is forwarded to a backend pool.
Do Azure managed certificates renew automatically?
Yes, as long as the domain validation remains valid. For custom domains on Front Door that means the required _dnsauth TXT record (or the CNAME validation) must keep existing — otherwise renewal can fail.
How do I get encryption all the way to the backend on Azure?
Enable end-to-end TLS on Application Gateway. The gateway then does bridging: it terminates the client's TLS and opens a new HTTPS connection to the backend, which must have a valid certificate itself.
Why is Key Vault recommended for certificates?
Because Application Gateway and Front Door can reference the certificate in Key Vault and automatically pull the latest version. That makes rotation centralised and automatable instead of manual uploads per resource.