App Service custom domain and free managed certificate: add it, bind it and fix validation failures

#The goal

You have a web app on app-prod.azurewebsites.net and need it on www.contoso.com with HTTPS, without buying a certificate. App Service can issue a free App Service managed certificate (issued by DigiCert) and renew it automatically. This post walks through the setup from the CLI and lists the failures you will actually hit.

Before you start, check these:

• The plan is Basic or higher. Free and Shared tiers don't support SNI bindings for custom domains.
• You can edit DNS for the domain.
• You know whether anything sits in front of the app (Front Door, Application Gateway, Traffic Manager, a third-party CDN). That changes the validation path; see the troubleshooting table.

#Step 1: Get the verification ID and create DNS records

App Service proves you own the domain with a TXT record named asuid.<hostname> that holds the app's custom domain verification ID.

RG=rg-web-prod
APP=app-prod

az webapp show -g $RG -n $APP --query customDomainVerificationId -o tsv
az webapp show -g $RG -n $APP --query defaultHostName -o tsv

Create the records at your DNS provider:

Get the inbound IP for an apex A record with az webapp show -g $RG -n $APP --query inboundIpAddress -o tsv.

If the zone is in Azure DNS:

az network dns record-set cname set-record -g rg-dns -z contoso.com \
  -n www -c app-prod.azurewebsites.net
az network dns record-set txt add-record -g rg-dns -z contoso.com \
  -n asuid.www -v "<verification-id>"

Check that the records resolve from outside your network before moving on:

nslookup -type=CNAME www.contoso.com 8.8.8.8
nslookup -type=TXT asuid.www.contoso.com 8.8.8.8

#Step 2: Add the hostname to the app

az webapp config hostname add --webapp-name $APP -g $RG --hostname www.contoso.com
az webapp config hostname list --webapp-name $APP -g $RG -o table

At this point the domain works over HTTP, and HTTPS shows a certificate name mismatch because nothing is bound yet.

#Step 3: Create the managed certificate

az webapp config ssl create -g $RG --name $APP --hostname www.contoso.com

Issuance usually completes in a few minutes but can take longer. List the certificates and note the thumbprint:

az webapp config ssl list -g $RG \
  --query "[].{name:name, subject:subjectName, thumbprint:thumbprint, expires:expirationDate}" -o table

Tip

Certificates are separate Microsoft.Web/certificates resources, not settings inside the app. If the list looks empty, make sure you're querying the right resource group and subscription.

#Step 4: Bind it and force HTTPS

az webapp config ssl bind -g $RG --name $APP \
  --certificate-thumbprint <thumbprint> --ssl-type SNI

az webapp update -g $RG -n $APP --https-only true
az webapp config set -g $RG -n $APP --min-tls-version 1.2

Test from a client:

curl -sI https://www.contoso.com | head -n 1
openssl s_client -connect www.contoso.com:443 -servername www.contoso.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -enddate

Use SNI SSL unless a legacy client can't send SNI. IP based SSL assigns a dedicated inbound IP, which changes the address your apex A record must point to.

#Troubleshooting validation and issuance

Check for a CAA record:

dig CAA contoso.com +short

No output means no CAA restriction. Any output that doesn't include digicert.com will block issuance.

Warning

Microsoft changed how managed certificates are validated in 2025: subdomains now also use HTTP token validation, and only Azure endpoints behind Traffic Manager are supported. Apps that rely on nested or external Traffic Manager endpoints can't renew. Check the current "App Service managed certificate" page on Microsoft Learn for the rules that apply today.

#Limits worth knowing before you choose it

• Not exportable. You can't reuse the certificate on Application Gateway, Front Door or a VM.
• No wildcard certificates.
• Renewal is automatic, roughly 45 days before expiry, but a failed renewal is silent unless you watch for it.
• Not available in every environment (for example, check support for App Service Environment and sovereign clouds before planning on it).

If any of these rule it out, store your own certificate in Key Vault and import it with az webapp config ssl import --key-vault <vault> --key-vault-certificate-name <name>.

#Prevent it next time

• Alert on expiry. Run this Azure Resource Graph query weekly or wire it into an alert:

resources
| where type == "microsoft.web/certificates"
| extend expires = todatetime(properties.expirationDate)
| where expires < now() + 30d
| project name, resourceGroup, subscriptionId, subject = tostring(properties.subjectName), expires
| order by expires asc

Any managed certificate within 30 days of expiry means auto-renewal has already failed, because renewal should start about 45 days out.

• Keep the asuid TXT records. Removing them after setup doesn't break the running site, but it blocks re-adding the hostname and moving the app.
• Document CAA records. Security teams often add CAA during a hardening exercise. Make digicert.com part of the standard set if you use managed certificates.
• Don't change DNS without checking. Moving a hostname to Front Door or a CDN changes the validation path. Plan the certificate change in the same ticket.
• Put bindings in IaC. Bicep Microsoft.Web/certificates and Microsoft.Web/sites/hostNameBindings resources let you redeploy the whole setup in minutes if someone deletes it.