Part three of our series on highly available, Azure-hosted CDP and AIA for AD CS. Part 2 covered storage account setup. This part covers what actually turns a single storage account into a genuinely highly available architecture: Azure Front Door. For the complete picture with a full architecture diagram, see Highly Available CDP and AIA for ADCS Using Azure.
TL;DR: Key Takeaways
- A storage account alone can’t deliver both custom domain HTTPS and multi-origin failover, Front Door is what actually provides both together.
- Origin groups and health probes are the mechanism that makes failover automatic, clients never need to know which storage account is currently serving them.
- Azure Blob Storage’s case sensitivity is a genuine, easy-to-miss migration issue, requiring explicit normalization at both the storage and Front Door layers.
- Front Door’s managed TLS handles your custom domain certificate, while the actual content behind it is still served over plain HTTP, consistent with Part 2’s configuration.
Why Front Door, Specifically
- Storage account custom domains have real HTTPS limitations on their own, sufficient for some use cases, but not for a production CDP/AIA architecture that needs a stable, trusted custom domain with proper certificate management.
- A storage account has no native concept of routing across multiple backend accounts, if you want the dual-region redundancy covered in Part 2 to translate into actual failover, you need a layer capable of directing traffic to whichever origin is healthy.
- Front Door delivers both in one service: managed TLS for your custom domain, and health-probe-driven routing across an origin group containing your primary and secondary storage accounts.
Configuring the Origin Group
- Add both your primary and secondary storage accounts as origins within a single origin group, this is what allows Front Door to treat them as interchangeable backends for the same content.
- Configure health probes against both origins, this is the mechanism that actually detects when an origin becomes unhealthy and routes subsequent requests to the surviving one, without any DNS change or manual intervention required.
- Set probe frequency and failure thresholds deliberately, rather than accepting defaults without consideration, this directly affects how quickly your architecture actually responds to a real origin failure.
Custom Domain and TLS
- Associate your abstracted CDP/AIA hostname with the Front Door endpoint, this is the domain relying parties will actually resolve and connect to, not the underlying storage or Front Door service names.
- Use Front Door’s managed certificate for this custom domain, removing manual certificate lifecycle management from your team’s ongoing operational burden.
- Remember this TLS configuration governs the connection to Front Door itself, not the content being served, per Part 2, the actual CDP/AIA content should still be plain HTTP once past this layer, these are two distinct points in the request path.
Solving the Case Sensitivity Problem
- Understand the mismatch before it causes a confusing failure: Azure Blob Storage treats file names as case-sensitive, IIS, which most existing PKI infrastructure was built around, does not, a blob named with different casing than a client requests simply fails to resolve.
- Upload every blob using consistent, lowercase naming, establishing this as a hard rule for your publication process rather than something enforced inconsistently across manual and automated uploads.
- Configure a Front Door rule to normalize incoming request URLs to lowercase, before they reach the storage origin, this preserves the case-insensitive behavior clients and existing certificate CDP/AIA extensions may already assume, without requiring you to reissue anything.
How Encryption Consulting Can Help
Front Door configuration for this specific use case, correct origin group health probing, custom domain TLS, and case normalization together, is exactly the kind of setup that’s easy to get partially right and not discover the gap until a specific client or failure scenario exposes it.
Encryption Consulting’s PKI Services team supports this directly:
- Front Door architecture configuration: origin groups, health probes, and custom domain setup built correctly for CDP/AIA hosting specifically.
- Case-sensitivity remediation: auditing existing blob naming and Front Door rules for this specific, easy-to-miss issue.
- Failover behavior validation, confirming health probes actually trigger routing changes as expected before you rely on them in production.
If you want your Front Door configuration for CDP/AIA reviewed or built correctly, our PKI Services team can help.
Conclusion
Front Door is the layer that actually turns redundant storage into a highly available architecture, through origin group health probing, and it’s also where you solve the custom domain HTTPS requirement and the case-sensitivity mismatch between Azure Storage and traditional IIS behavior. Part 4 covers automating publication from your CA environment and the DNS cutover that puts all of this into production.
Related reading: Highly Available CDP and AIA for ADCS Using Azure · Setting Up Azure Storage for CDP and AIA Hosting, Part 2 · ADCS Certificate Chain and Topology Monitoring
Configuring Azure Front Door for CDP/AIA and want it validated before go-live? Talk to our PKI Services team. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.
FAQ
Why is Azure Front Door necessary in front of a storage account for CDP/AIA hosting? A storage account alone has real limitations for custom domain HTTPS support and has no native mechanism for routing across multiple backend storage accounts. Front Door provides managed TLS for a custom domain and health-probe-based routing across multiple origins, which together deliver both HTTPS support and genuine failover.
What is an origin group in Azure Front Door used for in this architecture? It groups your primary and secondary storage accounts together as interchangeable backends, with Front Door’s health probes determining which one is currently healthy and routing client requests accordingly, without the client ever needing to know which origin actually served the request.
Why does casing matter when uploading CRLs and certificates to Azure Blob Storage? Because Azure Blob Storage is case-sensitive, unlike IIS. A blob uploaded with different casing than what a client requests simply won’t resolve. Normalize all blob names to lowercase on upload and configure a Front Door rule to normalize incoming request casing to match.