Highly Available CDP and AIA for ADCS Using Azure

Certificate chain validation spends most of its time on exactly two network operations: retrieving the issuing CA’s certificate and checking its revocation status. If either one is slow or unreachable, validation fails, or worse, times out unpredictably depending on the client. A single on-premises IIS server serving CDP and AIA content is a real single point of failure for an operation every relying party depends on. This is a complete reference architecture for solving that with Azure: DNS and URL planning, storage and web endpoints, the real difference between data replication and actual failover, publishing automation, monitoring, and how to validate failover actually works.

This builds directly on the abstracted-hostname principle covered in The Ultimate Windows ADCS Migration and Modernization Guide and the publication-point discipline covered throughout ADCS Certificate Chain and Topology Monitoring.

TL;DR: Key Takeaways

Storage replication is not the same thing as high availability: redundancy settings on an Azure Storage account protect your data, they don’t reroute client traffic away from a failed origin, that requires a dedicated routing and health-probe layer on top.
CDP and AIA content should be served over plain HTTP, not HTTPS: the content is already digitally signed, and not every PKI client handles an HTTPS-based CDP or AIA URL correctly, some fail permanently.
Azure Blob Storage is case-sensitive, IIS is not: this is a genuine, easy-to-miss migration gotcha that breaks CRL and certificate retrieval if you don’t normalize blob naming and incoming request casing consistently.
Azure Front Door, not a direct storage custom domain, is what actually delivers both HTTPS and failover: it provides managed TLS for your custom domain and health-probe-based routing across multiple storage origins, neither of which a storage account alone gives you.
URL and DNS planning matters more than the Azure architecture itself, since CDP and AIA URLs are permanently embedded in every certificate you’ve already issued, plan for abstraction and future migration flexibility from the start, not as an afterthought.

Reference Architecture

The architecture below is the production-grade pattern: on-premises CAs publish locally, a scheduled process uploads to a primary Azure Storage account, that data replicates to a secondary storage account in a different region, and Azure Front Door sits in front of both as a single, globally available, health-probe-driven entry point.

DNS and URL Planning

Publish under an abstracted hostname, never a literal storage or Front Door endpoint name, a single, stable DNS name like cdp.contoso.com as a CNAME is what lets you change the entire backing infrastructure later without touching a single certificate already in circulation.
Use virtual aliases at every level of the URL, not just the hostname, the virtual directory and file name portions of your CDP/AIA URLs benefit from the same abstraction, since this gives you flexibility to reorganize backing storage without needing to match the exact original structure.
Remember these URLs are permanently embedded in every certificate you’ve already issued, this is precisely why abstraction matters so much here specifically, more than almost anywhere else in your PKI, a URL you have to change later means maintaining the old one indefinitely for existing certificates.

Storage and Web Endpoints

Provision at least two storage accounts in different Azure regions, a primary that receives uploads directly and a secondary that serves as your failover origin, rather than relying on a single storage account’s redundancy setting alone.
Choose Zone-Redundant Storage as a reasonable baseline, more if your requirements call for it, this protects the data itself against localized infrastructure failure, independent of the cross-region failover architecture covered below.
Serve CDP and AIA content over plain HTTP, not HTTPS, this is intentional, the content is already digitally signed and doesn’t need transport-layer protection for integrity, and critically, some PKI clients don’t handle an HTTPS CDP or AIA URL correctly and can fail permanently, use HTTPS for the separate, authenticated upload path from your CA environment instead.
Configure anonymous read access at the container level so clients can actually retrieve content, while keeping the upload path itself authenticated via a storage access key or equivalent, these are two different access patterns serving two different purposes and shouldn’t be conflated.
Account for blob storage’s case sensitivity explicitly, unlike IIS, Azure Blob Storage treats file names as case-sensitive, a blob uploaded with inconsistent casing relative to what a client requests will simply fail to resolve, normalize all blob names to lowercase on upload and configure URL normalization at the Front Door layer to match.

Front Door as the HA/HTTPS Layer

Understand why a storage account’s own custom domain support isn’t sufficient here, custom domain HTTPS on a storage account directly has real limitations, and a storage account has no native concept of routing across multiple backend origins for failover purposes.
Use Azure Front Door as the actual HTTP interface clients talk to, configured with your custom domain and Front Door’s managed TLS certificate, sitting in front of both your primary and secondary storage accounts as an origin group.
Configure Front Door’s health probes against both origins, this is what actually allows automatic routing to a healthy origin, rather than clients ever needing to know which storage account is currently serving traffic.
Apply URL normalization rules at this layer, addressing the case-sensitivity mismatch between how IIS traditionally behaved and how Azure Storage actually behaves, so existing client behavior and expectations aren’t disrupted by the underlying platform change.

Replication vs. Failover: Two Different Problems

Storage replication solves data durability, not traffic routing, a geo-redundant storage account protects your data against regional failure, but it doesn’t, by itself, redirect a client’s request away from an origin that’s become unreachable.
Front Door’s health-probe-driven origin routing is what actually delivers failover, this is the layer that notices an origin is unhealthy and routes subsequent requests to the surviving one, without requiring any DNS change or manual intervention.
Treat these as two separate design requirements, not one, an architecture with excellent storage redundancy but no health-probe routing layer is not highly available in any meaningful sense for this use case, and the reverse, a routing layer in front of a single storage account, doesn’t protect your underlying data.

Publishing Automation

Let your CA servers continue publishing to a local share or DFS location as normal, this doesn’t need to change, the Azure layer sits downstream of your existing, familiar CA publication process.
Build a scheduled task or script that uploads from that local share to your primary storage account, authenticated through a storage access key or equivalent access policy, running on a schedule tight enough to keep published content current relative to your actual CRL publication interval.
Let storage-level replication propagate content to your secondary account, this happens independently of your upload script, and is exactly the data-durability piece covered above, distinct from the traffic-routing piece Front Door provides.

Monitoring

Monitor Front Door’s origin health probe status directly, this tells you in real time whether either backend origin is currently considered healthy, and is your earliest signal of a developing problem before it becomes a client-facing failure.
Monitor storage account availability metrics independently, giving you visibility into the underlying infrastructure health that Front Door’s probes are actually reflecting.
Run an independent, client-side synthetic check against your actual public CDP/AIA URL on a schedule, using a real retrieval test rather than trusting infrastructure-level health metrics alone, infrastructure can report healthy while served content is stale or a recent CRL upload silently failed, only an actual content check catches that gap.
Alert on content staleness specifically, not just availability, a CRL that’s reachable but hasn’t updated in longer than your publication interval indicates a broken upload pipeline even though every component reports as up.

Failover Validation

Test actual failover deliberately, in a controlled window, rather than assuming it works because it’s configured, simulate a primary origin outage and confirm Front Door genuinely routes traffic to the secondary origin automatically.
Confirm the content served during failover is current, not just reachable, a successful failover to stale content is a different, more subtle failure than an outright outage, and worth explicitly checking for.
Document the actual recovery time this failover path delivers, and compare it against what your organization’s real requirements demand, rather than assuming Front Door’s failover is instantaneous without having measured it.
Treat this as a recurring validation exercise, consistent with the disaster recovery testing discipline covered throughout our broader AD CS series, not a one-time check performed only when the architecture was first built.

How Encryption Consulting Can Help

Designing and validating a genuinely highly available CDP and AIA architecture in Azure touches DNS planning, storage configuration, Front Door routing, and ongoing monitoring together, and a gap in any one layer can quietly undermine the availability the whole design was meant to deliver.

Encryption Consulting’s PKI Services team supports this directly:

Reference architecture design: building your specific DNS, storage, and Front Door configuration aligned to your existing CA hierarchy and publication process.
Migration planning: moving from an on-premises-only CDP/AIA setup to this architecture without breaking chain validation for certificates already in circulation.
Monitoring and alerting implementation: building both infrastructure-level health monitoring and independent content-freshness validation.
Failover testing and validation, running real, controlled failover exercises and documenting your actual recovery time.
Ongoing architecture review, integrated into your broader continuous PKI risk assessment practice, as your Azure environment and PKI hierarchy evolve together.

If you’re planning a highly available CDP and AIA architecture in Azure, or want your existing setup reviewed and validated, our PKI Services team can help.

Conclusion

A genuinely highly available CDP and AIA architecture in Azure needs more than a storage account and a hopeful DNS record, it needs abstracted, future-proof URLs, dual-region storage with real replication, a health-probe-driven routing layer like Front Door on top, and monitoring that checks actual content freshness, not just infrastructure uptime. Build replication and failover as the two distinct problems they actually are, and validate failover deliberately rather than trusting it works because it’s configured correctly on paper.

Planning or validating a highly available CDP/AIA architecture in Azure? Talk to our PKI Services team about designing or reviewing it. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

Should CDP and AIA content in Azure be served over HTTPS? No, and this is counterintuitive. CRLs and CA certificates are already digitally signed, and not every PKI client correctly handles an HTTPS-based CDP or AIA URL, some fail permanently if the URL uses HTTPS. Serve the actual content over plain HTTP through Azure Front Door’s custom domain, while still using HTTPS for the separate, authenticated upload process from your CA environment to storage.

Does Azure Storage redundancy alone provide high availability for CDP and AIA? No. Storage redundancy options like ZRS or GRS protect data durability, they don’t automatically route client traffic away from a failed or unreachable storage account. Genuine availability requires a layer like Azure Front Door in front of multiple storage origins, using health probes to route traffic to whichever origin is actually healthy.

Why does blob storage case sensitivity matter for CDP and AIA hosting? Azure Blob Storage treats file names as case-sensitive, unlike IIS, which does not. A blob named with different casing than what a client requests will fail to resolve. The fix is to upload all blobs using consistent lowercase naming and configure URL normalization rules at the Front Door layer so incoming requests are matched correctly regardless of casing.

Why use Azure Front Door instead of pointing a custom domain directly at a storage account? A storage account alone has real limitations for this use case, including custom domain HTTPS support and no built-in mechanism for routing across multiple storage accounts. Azure Front Door provides managed TLS for a custom domain, a global entry point, and health-probe-based routing across multiple backend storage origins, which is what actually delivers both HTTPS support and failover.

How should failover be validated for an Azure-hosted CDP and AIA architecture? Periodically simulate a primary storage origin outage in a controlled way and confirm Front Door actually routes traffic to the secondary origin automatically, with correct and current content. Treat this as a recurring validation exercise, not a one-time check performed only when the architecture was first built.