HomeAbout Me

Front your Power Apps(pages) with Azure Front Door and WAF

By Sri Gunnala
Published in Microsoft Azure
September 21, 2025
2 min read
Front your Power Apps(pages) with Azure Front Door and WAF

Power Pages behind Azure Front Door with a Custom Domain (and the 421/SNI gotcha)

Putting Azure Front Door (AFD) in front of Power Pages is a common pattern for performance, security (WAF), and centralized routing.
But when you introduce a custom domain, one setting becomes critical:

Origin host header — without it, you’ll run into a 421 Misdirected Request (SSLMismatchedSNI).

This post explains the custom domain setup, why the 421 happens, and the safe steps to avoid it.


What we’re building

  • Public hostname: https://portal.example.com
  • Front Door endpoint: xxxxxxxx.azurefd.net
  • Power Pages backend host: site-abc.powerappsportals.com

AFD terminates TLS at the edge for portal.example.com, then forwards requests to the Power Pages origin.


High-level steps (TL;DR)

  1. Create the AFD origin → point to the Power Pages host (site-abc.powerappsportals.com).
  2. Add custom domain in AFDportal.example.com with an AFD-managed certificate.
  3. Temporarily point DNS CNAME portal.example.comsite-abc.powerappsportals.com (Power Pages validation requires this).
  4. Add the custom domain in Power Pages Admin → wait until it shows mapped/SSL provisioned.
  5. Flip DNS CNAME back to AFD: portal.example.comxxxxxxxx.azurefd.net.
  6. Set AFD Origin host header to portal.example.com.

The critical ordering: bind the domain in Power Pages before setting Origin host header to the custom domain. Otherwise you’ll get 421 SSLMismatchedSNI.


1) Configure the AFD origin group

AFD → Origin groups → Add origin

  • Origin type: Custom
  • Host name: site-abc.powerappsportals.com
  • Origin host header: (leave as default for now — we’ll change later)
  • HTTPS port: 443
  • Certificate subject name validation: Enabled
  • Session affinity: Off

Why this matters: the origin host name controls where AFD connects and which certificate the origin presents during TLS. It should remain the Power Pages host.


2) Add the custom domain in AFD

AFD → Domains → Add

  • Custom domain: portal.example.com
  • Certificate: AFD managed (auto)
  • Associate with endpoint & route: your xxxxxxxx.azurefd.net and the default route (/*)

DNS (first pass): Point portal.example.com to AFD with a CNAME:

portal.example.com  CNAME  xxxxxxxx.azurefd.net

This proves ownership and issues an edge certificate, but Power Pages still doesn’t know about this host yet.


3) The 421 error explained

If you browse https://portal.example.com without setting the Origin host header, you’ll likely see:

421 - Misdirected Request
Error Info: SSLMismatchedSNI

Why?

  • TLS at the origin relies on SNI (Server Name Indication).
  • AFD connects to the backend host (site-abc.powerappsportals.com) but forwards with the wrong host header.
  • Power Pages doesn’t recognize portal.example.com yet → the certificate won’t match → SSL handshake fails421.

4) Bind the custom domain in Power Pages

Power Pages requires that during validation, the custom domain’s CNAME points directly to the portal host.

Temporarily change DNS:

portal.example.com  CNAME  site-abc.powerappsportals.com

Then in Power Pages Admin:

  • Admin center → Your site → Set up → Custom domains → Add domain
  • Enter portal.example.com
  • Wait until status shows Mapped and SSL Provisioned

Tip: Reduce the CNAME record’s TTL before you start, so flipping back to AFD is quick.


5) Flip DNS back to AFD

Once Power Pages shows the domain is mapped and its certificate is provisioned:

portal.example.com  CNAME  xxxxxxxx.azurefd.net

You now have:

  • AFD presenting a valid edge cert for portal.example.com.
  • Power Pages accepting Host: portal.example.com at the origin (because it’s been bound there too).

6) Set Origin host header in AFD

Now it’s safe to set:

AFD → Origin groups → (your origin) → Origin host header = portal.example.com

This tells AFD to forward:

Host: portal.example.com

Result: Power Pages generates absolute URLs and accepts TLS correctly for the custom domain.


7) Key lessons learned

  • Bind the custom domain in both places: AFD (edge) and Power Pages (origin).
  • Origin host header is required — without it, you’ll hit a 421 error when using a custom domain.
  • The 421 happens because the backend certificate doesn’t match the SNI unless the domain is bound in Power Pages.
  • Safe process: Temporarily CNAME → Power Pages, validate in portal admin, then CNAME back to AFD.

Final architecture

Client
  │  https://portal.example.com
  ▼
Azure Front Door (WAF, TLS at edge)
  │  Host: portal.example.com
  ▼
Power Pages (domain bound, TLS at origin)

Conclusion

When you put Azure Front Door in front of Power Pages with a custom domain:

  • Add the domain in both AFD and Power Pages.
  • Always configure the Origin host header in AFD to the custom domain.
  • If you skip it, expect a 421 SSLMismatchedSNI error.

Following these steps ensures smooth routing, correct certificates, and no surprises with custom domain access.

Photo/Thumbnail by Matthew Henry on Unsplash

Tags

#Azure#AzureFrontDoor
Previous Article
Azure EventHub and Service Bus Integration | Azure Function Trigger with Service Bus output Binding
Sri Gunnala

Sri Gunnala

Learner | Reader | Blogger | Azure Enthusiast

Topics

Front End
Microsoft Azure
Microsoft .NET

Newsletter

Sri Gunnala - Make sure to subscribe to newsletter and be the first to know the news.

Related Posts

Azure EventHub and Service Bus Integration | Azure Function Trigger with Service Bus output Binding
September 03, 2025
1 min

Legal Stuff

Privacy NoticeCookie PolicyTerms Of Use

Social Media