Setting Up Azure Storage for CDP and AIA Hosting, Part 2

Part two of our series on highly available, Azure-hosted CDP and AIA for AD CS. Part 1 covered why this matters and what to plan before touching Azure at all. This part covers the actual storage account setup, including a decision that surprises most administrators the first time they encounter it. For the complete architecture in one reference, see Highly Available CDP and AIA for ADCS Using Azure.

TL;DR: Key Takeaways

Zone-Redundant Storage is a sensible baseline, protecting your CDP and AIA content against localized infrastructure failure within a region.
Serve content over plain HTTP, not HTTPS, a genuinely counterintuitive but correct choice given how PKI clients actually behave.
Upload access and read access are two separate permission models, authenticated for the CA-side upload process, anonymous for actual client retrieval.
Validate manually before automating anything, a working manual publication confirms your configuration before you build automation around it in Part 4.

Provisioning the Storage Account

Create a dedicated storage account for CDP/AIA hosting, rather than repurposing one used for unrelated workloads, this keeps access policies, monitoring, and lifecycle management clean and specific to this purpose.
Choose Zone-Redundant Storage as your baseline redundancy setting, this protects against a localized zone failure within the region without requiring a full geo-redundant configuration if your requirements don’t call for it, though geo-redundant options are worth considering if you’re planning the multi-region failover architecture covered in Part 3.
Set minimum TLS version appropriately for the authenticated upload path, even though the actual served content will be plain HTTP, the upload connection from your CA environment should still use a current, secure TLS version.

The HTTP-Not-HTTPS Decision

Do not require secure transfer for this storage account, this is the single most counterintuitive decision in this entire setup, and it’s deliberate: CRL and CA certificate content is already digitally signed, it doesn’t need transport-layer protection for integrity.
Some PKI clients handle HTTPS-based CDP/AIA URLs incorrectly, and can fail permanently as a result, this isn’t a theoretical edge case, it’s a documented, real compatibility issue across the broader PKI client ecosystem, serving over plain HTTP avoids it entirely.
This setting doesn’t prevent you from using HTTPS elsewhere, your authenticated upload connection from the CA environment to the storage account can and should still use HTTPS, this decision is specifically about how content is served to relying parties, not how you manage the storage account administratively.

Configuring Access for Upload and Retrieval Separately

Configure anonymous read access at the container level, this is what allows PKI clients, which never authenticate to your storage account, to actually retrieve CRLs and CA certificates.
Keep the upload path authenticated, using a storage account key or an appropriately scoped access policy, the process that publishes new content should never rely on the same anonymous access clients use to read it.
Treat these as two genuinely separate permission models, not a single setting, conflating them either over-exposes your upload credentials or breaks client retrieval, neither of which you want.

Manual Publication and Validation

Publish a CRL and CA certificate manually to the new storage account before building any automation, this confirms your access configuration actually works end to end before you add a scheduled process on top of it.
Test retrieval from a client that has no special access or configuration, confirming the content is genuinely publicly retrievable exactly the way a real relying party would experience it, not just accessible from an authenticated administrative session.
Confirm the retrieved content matches what your CA actually published, a successful HTTP response with unexpected or stale content is a different problem than an outright failure, and worth explicitly ruling out at this stage.

How Encryption Consulting Can Help

Storage account configuration for this use case involves several settings that run counter to typical web hosting instincts, getting them right the first time avoids a confusing troubleshooting cycle later.

Encryption Consulting’s PKI Services team supports this directly:

Storage account configuration: setting up redundancy, access policies, and content-serving settings correctly for CDP/AIA hosting specifically.
Client compatibility validation: confirming your actual client population retrieves content correctly under the plain-HTTP configuration.
Migration testing, validating manual publication works cleanly before any automation is introduced.

If you want your Azure Storage configuration for CDP/AIA reviewed or built correctly from the start, our PKI Services team can help.

Conclusion

Storage setup for CDP/AIA hosting has a handful of deliberate, counterintuitive settings, plain HTTP for content, separate authenticated and anonymous access paths, that are easy to get backward if you’re applying general web hosting instincts. Validate manually before automating. Part 3 covers fronting this storage with Azure Front Door for genuine high availability and custom domain support.

Setting up Azure Storage for CDP/AIA and want it configured correctly the first time? Talk to our PKI Services team. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

What Azure Storage redundancy level should be used for CDP and AIA hosting? Zone-Redundant Storage is a reasonable baseline, protecting against localized infrastructure failure within a region. Higher redundancy tiers like geo-redundant storage add cross-region data durability, useful groundwork for the multi-region failover architecture covered in Part 3.

Should the storage account require secure transfer for CDP and AIA content? No. CDP and AIA content should be retrievable over plain HTTP, since the content is already digitally signed and some PKI clients handle HTTPS-based CDP/AIA URLs incorrectly. Secure transfer can still be used for the authenticated upload path without affecting how content is served to clients.

How do clients actually read CDP and AIA content from a storage account with no authentication? Through anonymous read access configured at the container level, separate from the authenticated access used for uploading. Clients requesting a CRL or CA certificate never authenticate to the storage account; upload access and read access are two distinct permission models serving different purposes.