App Service Custom Domains and TLS Certificates

Azure App Service provides a default domain like myapp.azurewebsites.net. However, production applications almost always need a custom domain (e.g., www.contoso.com) to present a professional brand and enable TLS. A TLS certificate is required to encrypt traffic between the client and the server over HTTPS. Without a proper certificate, browsers display security warnings, and users may lose trust.

Before you can use a custom domain with App Service, you must prove you own the domain. Azure supports two types of domain verification:

To route traffic to your App Service, you need to configure DNS records at your domain registrar. The record type depends on the domain:

Once the custom domain is verified and mapped, you need to bind a TLS certificate to enable HTTPS. Azure App Service supports three types of certificates:

To bind a certificate to a custom domain:

1. Navigate to the App Service in the Azure portal. 2. Under Settings, select TLS/SSL settings. 3. In the Private Key Certificates (.pfx) tab, upload or import the certificate. 4. In the Custom Domains tab, add the custom domain and verify ownership. 5. In the TLS/SSL bindings tab, select the domain, choose the certificate, and set the TLS/SSL type: - SNI SSL: Multiple certificates can be bound to the same IP address. The client indicates the hostname during the TLS handshake, and the server presents the correct certificate. This is the default and recommended option. Supported by all modern browsers. - IP-based SSL: A dedicated IP address is assigned to the app, and the certificate is bound to that IP. This is required for legacy clients that do not support SNI. It incurs additional cost (Standard tier or above) and uses one IP per certificate.

If you use Azure Front Door or Traffic Manager in front of App Service, the custom domain should be configured at the Front Door/Traffic Manager level, not at the App Service. The App Service only needs to accept traffic from the Front Door/Traffic Manager IP ranges. You typically set the App Service access restrictions to allow only the Front Door/Traffic Manager IPs.

You can use Azure CLI or PowerShell to manage custom domains and certificates:

Azure CLI Example:

# Add a custom domain
az webapp config hostname add --resource-group myResourceGroup --webapp-name myApp --hostname www.contoso.com

# Upload a certificate
az webapp config ssl upload --resource-group myResourceGroup --webapp-name myApp \
  --certificate-file /path/to/certificate.pfx --certificate-password myPassword --name myCertificate

# Bind the certificate
az webapp config ssl bind --resource-group myResourceGroup --webapp-name myApp \
  --certificate-thumbprint <thumbprint> --ssl-type SNI --hostname www.contoso.com

PowerShell Example:

# Add a custom domain
New-AzWebAppCertificate -ResourceGroupName myResourceGroup -WebAppName myApp -HostName www.contoso.com

# Upload certificate
$pfxPath = "C:\path\to\certificate.pfx"
$pfxPassword = ConvertTo-SecureString -String "myPassword" -Force -AsPlainText
New-AzWebAppCertificate -ResourceGroupName myResourceGroup -WebAppName myApp -Path $pfxPath -Password $pfxPassword

# Bind certificate
New-AzWebAppSSLBinding -ResourceGroupName myResourceGroup -WebAppName myApp -CertificateThumbprint "<thumbprint>" -SslState SNI -Name www.contoso.com

In a typical enterprise deployment, a company like Contoso hosts its main website (www.contoso.com) and a customer portal (portal.contoso.com) on Azure App Service. They use a single wildcard certificate *.contoso.com purchased from a public CA (e.g., DigiCert) to secure both domains. The certificate is uploaded to the App Service and bound to each domain using SNI SSL. The company also uses Azure Front Door for global load balancing and DDoS protection. In this case, the custom domains are configured at the Front Door level, and the App Service only allows traffic from Front Door's IP ranges via access restrictions. The Front Door terminates TLS and re-encrypts traffic to the App Service using a separate certificate (or the same one).

Another scenario: A SaaS provider offers white-labeled applications where each customer gets a subdomain like customer1.saasapp.com. They use an App Service Managed Certificate for the wildcard domain *.saasapp.com. The managed certificate is free and auto-renewed, reducing operational overhead. However, they must keep the asuid.* TXT record in place for renewal. They also use Azure Traffic Manager to route traffic to different regional App Service instances. The custom domain is configured at Traffic Manager, which then resolves to the App Service's default domain.

A common misconfiguration is using an IP-based SSL binding unnecessarily, which consumes a public IP address and costs extra. For example, a developer might choose IP-based SSL because they think it is required for all certificates, but SNI works with virtually all modern clients. Another issue is forgetting to update the DNS record when the App Service's inbound IP changes (which can happen if the app is scaled down to Free/Shared tier). To avoid this, always use CNAME records for subdomains, which are immune to IP changes. For apex domains, ensure the App Service is on a Standard or higher plan to have a static IP.

Performance considerations: TLS termination at the App Service adds CPU overhead. For high-traffic sites, consider offloading TLS to Azure Front Door or Application Gateway. Certificate renewal can cause brief downtime if not handled correctly. Managed certificates are renewed seamlessly, but BYO certificates require manual intervention. Setting up monitoring alerts for certificate expiry is a best practice.