Add a Custom Domain and Free SSL to Azure App Service (Without the Common Gotchas)
The certificate is free and the steps are short — but half the guides online skip the one prerequisite that makes the whole thing fail silently. Here is the ordered path, plus the apex-domain traps that cost people an afternoon.
New to cloud? CAMPUX is a free, build-first course. Start here →
Before anything else: the free App Service Managed Certificate needs your app on a Basic tier plan or higher — Free F1 and Shared plans do not support it, and the custom-domain feature itself needs Shared or above. If your app is on Free, scale up first; every step below silently depends on it. That single fact, current as of 2026, is what most walkthroughs bury or omit, and it is why people spend an hour clicking a Create managed certificate button that is greyed out for reasons the portal never quite explains.
The rest is mechanical once the tier is right: point DNS at the app, let Azure verify you own the domain, mint the free certificate, bind it, and force HTTPS. Do it in that order. Do it out of order and you will chase errors that are really just "the previous step has not propagated yet."
What you need first — a Basic-or-higher plan, and why Free/Shared won't work
App Service ties two separate features to your plan tier. Mapping a custom domain requires Shared tier or higher. Getting the free managed certificate requires Basic tier or higher. The F1 Free tier gives you neither — it hands you an azurewebsites.net hostname and nothing else. So the practical floor is Basic. On a real production app you are usually on Standard or Premium anyway, so this rarely costs extra; it just has to be true before you start.
Why the split matters: you can be on Shared, successfully map www.contoso.com, and then find the managed certificate button unavailable — because Shared clears the domain bar but not the certificate bar. Scale to Basic and it appears. Check the tier first and you skip that entire confusion. In money terms, Basic runs a few dollars a day; the certificate on top of it is genuinely zero.
Open your App Service plan, confirm it is Basic (B1) or higher, and confirm the app is publicly reachable with no access restrictions blocking anonymous traffic. Both facts are load-bearing for the certificate step later. If either is wrong, fix it now — not after you have spent twenty minutes debugging a failed issuance.
Add the custom domain — A + TXT (or CNAME) records and domain verification
Azure has to confirm two things: that the domain resolves to your app, and that you actually control the domain. That is why you add two DNS records, not one.
- Subdomain (like
www) — add aCNAMEpointingwwwto your app's<app-name>.azurewebsites.nethostname, plus aTXTrecord atasuid.wwwholding the custom-domain verification ID Azure shows you. - Apex / root (like
contoso.com) — a root domain cannot be aCNAME, so you add anArecord to the app's inbound IP address, plus aTXTrecord atasuidwith the same verification ID.
In the portal, go to your app, open Custom domains, choose Add custom domain, and Azure shows you the exact record names and values to create at your DNS provider. Create them, wait for propagation — usually minutes, occasionally longer — then click Validate. The TXT record is the ownership proof; the A or CNAME is the routing. Both must resolve before validation passes. If validation fails, it is almost always propagation or a typo in the record name, not an Azure fault.
Order is the whole game: DNS resolves, then Azure verifies, then the certificate issues, then you bind it, then you force HTTPS. Skip a rung and you debug the wrong problem.
Create the free App Service Managed Certificate
With the domain added and verified, the certificate is a few clicks. In the app, open Certificates, choose Bring your own certificates / Managed certificate, select Create App Service Managed Certificate, pick the custom domain you just bound, and create it. Azure orders the certificate from DigiCert, validates domain control, and stores the result — no CSR, no private key file, no manual renewal on your calendar.
A managed certificate is issued per exact hostname. If you want both contoso.com and www.contoso.com secured, you add each as a custom domain and mint a managed certificate for each. There is no wildcard here — that is a real limitation, covered below.
As of a July 2025 update to how App Service Managed Certificates are issued and renewed, some edge scenarios changed — mostly around validation for certain domain setups. Most apps need no action, but if issuance or renewal behaves oddly on an unusual DNS configuration, check Microsoft's current App Service Managed Certificate guidance rather than an older blog post. The facts in this note are current as of 2026.
Bind the cert (SNI SSL) and force HTTPS-only
Issuing a certificate does not secure traffic — binding it does. In the app, open Custom domains (or the TLS/SSL binding pane), add a TLS/SSL binding for your hostname, select the managed certificate, and choose SNI SSL. SNI is the modern, free binding type and the correct default; IP-based SSL exists for legacy clients and costs extra, and you almost never need it. After binding, load https://your-domain and confirm the padlock shows your certificate, not the old azurewebsites.net one.
Then turn on HTTPS Only in the app's TLS/SSL settings. That flips any http:// request to https:// with a redirect, so no one reaches your app in plaintext. It is a single toggle and there is no reason to leave it off once the binding works. Consider also setting a minimum TLS version of 1.2 while you are on that pane.
Binding a real certificate is also how you stop your app answering on the default *.azurewebsites.net address — a separate leak worth closing. See the default hostname redirect problem for the how and the why.
Root/apex domain gotchas — reachability, IP restrictions, the CAA record for DigiCert
Apex domains are where the smooth path gets bumpy, and three things account for most failures.
- Public reachability. Managed-certificate issuance validates over the public internet. If your app sits behind access restrictions, a private endpoint, or an IP allow-list that blocks anonymous requests, validation cannot reach it and issuance fails. Open the app publicly for issuance, or use a validation path that your restrictions permit.
- IP restrictions. The same trap in a narrower form — an Access restrictions rule that denies all but your office IP will also deny DigiCert's validation. Loosen it during issuance, then re-tighten if you must.
- The CAA record. If your domain already has a
CAArecord naming other certificate authorities, it may forbid DigiCert from issuing. Add aCAArecord of0 issue digicert.comso DigiCert is authorized. NoCAArecords at all means any CA can issue, which is fine; the problem is only a restrictive existing set that excludes DigiCert.
Work these three before you assume anything is broken on Azure's side. In my experience the apex certificate that "won't issue" is nearly always reachability or a stray CAA record, not a platform bug.
Renewal reality + what the free cert does NOT cover (wildcards, some apex cases)
The free certificate is valid for roughly six months and Azure auto-renews it about 45 days before expiry. You do not rotate it manually. The catch is that renewal still needs the world to look the way it did at issuance: the domain binding intact, the DNS records present, and — for apex — the app reachable and the CAA record still permitting DigiCert. Break any of those months later and a silent renewal failure is how you find out, usually via a browser warning your users see first. Keep the plumbing in place and renewal is genuinely hands-off.
What the free cert will not do: no wildcards. If you need *.contoso.com, the managed certificate cannot help, and some apex-plus-subdomain arrangements are cleaner with a certificate that carries multiple names. That is where the paid options come in.
| Option | Cost | Wildcard support | Renewal | Effort |
|---|---|---|---|---|
| App Service Managed Certificate | Free (needs a Basic+ plan) | No | Automatic, ~45 days before a ~6-month expiry | Lowest — a few clicks, no key handling |
| App Service Certificate (paid) | Paid, per year | Yes (wildcard SKU) | Auto-renew in one-year increments; may need domain re-verification | Medium — purchase, store in Key Vault, verify |
| Bring-your-own / Key Vault certificate | Varies (your CA) | Yes, if your cert is wildcard | Manual — you track and re-upload / rotate | Highest — you own issuance and lifecycle |
For the common case — one domain and its www, secured for free, renewing itself — the managed certificate is the right answer, and it is what App Service nudges you toward. Reach for paid or bring-your-own only when a wildcard or a specific compliance requirement forces your hand.
Questions people also ask
Is the Azure App Service managed certificate free?
Yes. The App Service Managed Certificate costs nothing beyond your App Service plan. Azure issues it through DigiCert, binds it to your custom domain, and auto-renews it for you. You do pay for the plan itself, which must be Basic tier or higher — the certificate is free, the compute under it is not.
What tier do I need for a custom domain on App Service?
You need Shared tier or higher to map a custom domain, and Basic tier or higher for the free managed certificate. The Free F1 tier supports neither. In practice you move to Basic or Standard, because that is the floor for the free certificate and for a real production app.
Does the free App Service managed certificate support wildcard domains?
No. The free App Service Managed Certificate does not issue wildcard certificates. It secures the exact hostnames you bind, such as the apex and www. For a wildcard like *.contoso.com you need a paid App Service Certificate or a certificate you bring yourself and store in Key Vault.
Do I need an A record or CNAME for my custom domain?
For a subdomain like www you point a CNAME at your app's azurewebsites.net hostname. For an apex or root domain, which cannot be a CNAME, you use an A record to the app's inbound IP plus a TXT record for verification. Either way Azure checks a TXT record to confirm you own the domain.
How often does the App Service managed certificate renew?
The free managed certificate is valid for about six months and Azure auto-renews it roughly 45 days before it expires. You do not rotate it by hand. Your job is to keep the DNS records and the domain binding in place so the automatic renewal can validate and succeed.
Once the domain and certificate are in place, the next professional move is safe releases: using deployment slots to swap into production with near-zero downtime. And if you are still deciding where to host, start with what App Service actually is.