Custom Domain + Free HTTPS for an Azure Blob Static Website (the Front Door Way, 2026)

You turned on static website hosting, uploaded your build, and it loads fine on the ugly *.web.core.windows.net URL. Then you point your own domain at it and the padlock breaks. Here is why, and the current fix — including the deprecation most 2024-era guides still get wrong.

New to cloud? CAMPUX is a free, build-first course. Start here →

The gap trips up nearly everyone the first time. An Azure Blob static website serves HTTPS only on its built-in *.web.core.windows.net endpoint; the storage service does not terminate TLS for a domain you own, so a custom domain works over HTTP but not HTTPS on its own. To get HTTPS on your own name, you put a service that terminates TLS in front of the storage origin — and in 2026 that service is Azure Front Door. The rest of this note is how to wire it up, lock it down, and decide whether it's even worth it for your site.

Why Blob static websites can't do custom-domain HTTPS alone

The static website feature is a thin capability bolted onto a storage account. Flip it on and Azure exposes a special $web container over a dedicated web endpoint — something like https://mysite.z13.web.core.windows.net. That endpoint has a valid certificate because Microsoft owns web.core.windows.net and can issue a wildcard for it. Your domain, www.example.com, is a different story: Azure Storage has no mechanism to prove ownership of your name and terminate TLS for it.

You can map a custom domain to the storage account directly — the "custom domain" setting under the storage account takes a CNAME — but read the fine print: that path is HTTP only. The moment a browser asks for https://www.example.com, there is no certificate for that host on the storage side and the handshake fails. There is no toggle inside Storage that fixes this. The feature was never designed to be a public web server; it's object storage that can also emit an index page.

So the architecture is fixed: you need a reverse proxy at the edge that owns the TLS handshake for your domain and forwards the request to the storage web endpoint as its origin. That proxy is where the certificate lives, where HTTP-to-HTTPS redirection happens, and where you get caching for free. Historically you had two choices for that proxy. In 2026, effectively you have one.

Front Door vs the legacy Azure CDN — and why the classic managed-cert path is gone

Here's the timeliness edge, and the reason to distrust older tutorials: most top-ranking "blob static site + HTTPS" guides still walk you through Azure CDN Standard from Microsoft (classic) with a one-click managed certificate. That path is dead. Microsoft stopped issuing managed certificates on classic CDN on August 15, 2025; existing managed certs kept working only until April 14, 2026. It is now past that date — those certificates have expired. The classic CDN product itself is scheduled to retire on September 30, 2027. If a guide tells you to create a "Microsoft Standard" CDN endpoint and enable a managed cert, close the tab.

The supported answer for any new deployment is Azure Front Door Standard (or Premium). Front Door is Microsoft's global edge platform — a reverse proxy at the edge that terminates TLS, redirects HTTP to HTTPS, caches static assets, and issues free Azure-managed certificates that auto-renew. It's the same class of tool as classic CDN but it's the one Microsoft is actually investing in, and it's the migration target Microsoft points classic CDN customers toward.

One nuance worth knowing before you pick a tier: Front Door Standard covers everything a static site needs — custom domains, managed TLS, caching, HTTP-to-HTTPS redirect, and origin-header locking. Front Door Premium adds managed WAF rule sets and Private Link to the origin, which Standard does not support. For a plain static site, Standard is the right default; reach for Premium only when you genuinely need private origin connectivity or managed WAF.

Create a Front Door Standard profile pointing at the $web origin

The setup is four moving parts: a profile, an endpoint, an origin group, and an origin. Walk it in order.

1. Confirm the storage web endpoint. In your storage account, under Static website, copy the Primary endpoint — the *.web.core.windows.net host. That hostname is your origin. Do not use the blob endpoint (*.blob.core.windows.net); the web endpoint is the one that serves your index and error documents.
2. Create a Front Door profile. In the portal, create Front Door and CDN profiles, choose Azure Front Door with the Standard tier, and pick Quick create or Custom create if you want to name each piece. Custom create is clearer the first time.
3. Add an endpoint. The endpoint is your Front Door host — myendpoint-xxxx.z01.azurefd.net. This is what your custom domain will eventually CNAME toward.
4. Add an origin group and origin. Create an origin group, then add an origin whose host is the storage web endpoint you copied. Set Origin host header to the same web endpoint value — this matters, because the storage service routes on the Host header and a mismatched header returns errors. Leave HTTPS on for the origin connection.
5. Add a route. Connect the endpoint to the origin group with a route that accepts HTTP and HTTPS, and set it to redirect HTTP to HTTPS. Enable caching on the route so static assets are served from the edge.

Give it a few minutes to propagate, then hit the *.azurefd.net endpoint in a browser. If your index page loads over HTTPS, the origin wiring is correct and you're ready to attach your own name.

The storage account never learns your domain. Front Door owns the certificate and the handshake; the origin just serves bytes when Front Door asks in the right voice.

Add your custom domain + Azure-managed certificate

This is the part that was broken on raw storage and is trivial on Front Door.

1. Add the custom domain in the Front Door profile under Domains. Enter www.example.com and choose Azure managed for the certificate. That's the free, auto-renewing option — no cert to buy, upload, or babysit.
2. Prove ownership. Front Door gives you a DNS TXT record (a _dnsauth value) to add at your DNS provider. Add it; Front Door polls and flips the domain to Validated, usually within minutes.
3. Point traffic at Front Door. Add a CNAME from www.example.com to your *.azurefd.net endpoint. For an apex/root domain (example.com) where a plain CNAME isn't allowed, use Azure DNS with an alias record, or your provider's CNAME-flattening equivalent.
4. Associate the domain to the route. Back on the route, add the new domain so Front Door serves it. Within minutes the managed certificate is issued and the padlock is real.

From here Front Door renews the certificate on its own before expiry. The thing that used to be a recurring chore — cert rotation — is now something you never think about again.

Lock it down — enforce HTTPS, restrict the origin to Front Door

Two jobs remain, and skipping the second one is a common mistake that leaves your storage origin wide open to the public.

Enforce HTTPS. You already set the route to redirect HTTP to HTTPS; confirm it. A visitor typing http:// should land on https:// with a 301/308, never see mixed content, and never reach a plaintext page. If you're strict, add a response header rule for Strict-Transport-Security so browsers refuse HTTP on repeat visits.

Restrict the origin. Right now, someone who discovers your *.web.core.windows.net endpoint can hit it directly and bypass Front Door entirely — no caching, no WAF, no HTTPS-on-your-domain guarantees. Close that door with two layers:

• The X-Azure-FDID header check. Front Door stamps every request to your origin with an X-Azure-FDID header carrying your profile's unique Front Door ID. Configure your origin path to honor only requests bearing your specific ID. Requests that arrive without it — anyone hitting storage directly — get rejected.
• The storage firewall. On the storage account, deny public network access and allow the AzureFrontDoor.Backend service tag, so only Front Door's backend IP ranges can even reach the origin. On Front Door Premium, tighten it all the way with Private Link to the origin, so traffic never touches the public internet; Standard doesn't support Private Link, which is where the header check earns its keep.

With both in place, the only public way to reach your content is through Front Door, on your domain, over HTTPS — which is the entire point.

Cost + tradeoff check — is Front Door worth it, or should you just use Static Web Apps?

Be honest about the money. Front Door Standard has a base fee of about $35 per profile per month, plus usage — outbound data transfer from around $0.083/GB for the first 10 TB out of North America and Europe edges, and a small per-10,000-requests charge. For a busy site that egress-heavy pricing is a bargain compared to classic CDN; for a five-page brochure site doing a few gigabytes a month, that $35 base fee is most of your bill and buys you edge features you may not use.

The honest alternative for small sites is Azure Static Web Apps. Its Free tier includes a custom domain and a free managed TLS certificate out of the box, with global distribution — no separate proxy, no $35 base fee. If your "static website" is genuinely static content and you don't need Front Door's routing, WAF, or fine-grained caching control, Static Web Apps is usually the cheaper and simpler answer. Reach for Blob-static-site-plus-Front-Door when you already have content in a storage account, need Front Door's edge and security controls, or are standing up something at real scale.

Questions people also ask

Why doesn't Azure Blob static website support HTTPS on a custom domain?

The static website feature serves HTTPS only on its built-in *.web.core.windows.net endpoint. When you map a custom domain directly to the storage account, Azure can serve it over HTTP but not HTTPS, because the storage service does not terminate TLS for domains you own. To get HTTPS on your own domain you put a service that terminates TLS — Azure Front Door — in front of the storage origin.

Should I use Azure Front Door or Azure CDN for a static website?

Use Azure Front Door Standard for any new static site. Azure CDN Standard from Microsoft (classic) is retiring on September 30, 2027, and it stopped issuing managed certificates on August 15, 2025 — existing ones only stayed valid until April 14, 2026. That managed-cert path is gone, so guides that still point you at classic CDN are stale. Front Door Standard supports Azure-managed certificates for new deployments.

Does Azure Front Door provide a free SSL certificate?

Yes. Front Door offers Azure-managed TLS certificates at no extra charge, and it auto-renews them. You validate domain ownership with a DNS TXT record (or CNAME), and Front Door issues and rotates the certificate for you. You still pay the Front Door base fee and usage, but the certificate itself costs nothing.

How do I restrict my storage account to only accept traffic from Front Door?

Front Door stamps every request to your origin with an X-Azure-FDID header carrying your profile's unique ID. Configure your origin so only requests with your Front Door ID are honored, and pair that with the storage account firewall — allow the AzureFrontDoor.Backend service tag and deny public access. On Front Door Premium you can go further and use Private Link to reach the origin privately.

Is Front Door worth it for a small static site?

Sometimes not. Front Door Standard carries a base fee of about $35 per profile per month plus usage, which is real money for a tiny brochure site. If you only need a custom domain with free HTTPS and don't need Front Door's edge or routing, Azure Static Web Apps has a free tier that includes a managed certificate and a custom domain — often the cheaper, simpler answer for a small site.