Configuring and Troubleshooting CRL Distribution Points (CDP) and Authority Information Access (AIA)

CDP and AIA Points can sometimes be confusing but are the most important pillars of a functional PKI environment. Configuration of proper CDP and AIA points can result in a better and healthy PKI environment, and debugging those issues can be equally tricky. This article intends to be a way to stop any CDP/AIA issues that one may face during the PKI configuration and debugging stages.

Quick Answer: What Are CDP and AIA?

CDP (CRL Distribution Point) and AIA (Authority Information Access) are certificate extensions that tell clients where to find a CA’s revocation lists and issuer certificates. Configuring them correctly means setting the right decimal publication flags on the CA, matching replacement tokens like %1 and %3 to the actual file names, and verifying every URL resolves before certificates go into production.

Last updated: August 2026 · Last verified: August 2026 · Recommended refresh cadence: quarterly, since CDP/AIA behavior is tied to CA/Browser Forum validity-period changes and vendor (Windows CA) updates.

Executive Summary: Key Takeaways

• Two extensions, two jobs: AIA tells clients where to fetch the issuing or root CA certificate; CDP tells them where to fetch the CRL for revocation checking.
• Decimal flags control behavior: AIA uses 1, 2, and 32; CDP uses 1, 2, 4, 8, and 64, and they combine (65, 79, 6) to represent multiple settings at once.
• Replacement tokens build the file name: %1 through %11 map to the CA’s DNS name, short name, CA name, and CRL suffix, so renaming a published file breaks the lookup.
• Debugging starts in PKIView.msc: it shows which specific location (AD/LDAP, HTTP, or file share) is failing before you touch any configuration.
• Fixes are usually one command or one copy: certutil -dspublish for AD gaps, or copying the certificate to the web server for HTTP gaps.

Who Should Care About CDP/AIA Configuration

CDP and AIA configuration is easy to ignore until revocation checking breaks. Here is what each role should own.

PKI Administrators

Own the decimal flag configuration on the CA, keep the replacement-token file names in sync with what’s actually published, and run PKIView.msc after every CA change.

Security Architects

Decide which CDP/AIA locations are internal (LDAP) versus internet-facing (HTTP), and make sure load-balanced or clustered endpoints are excluded from direct CA publishing.

Platform Teams

Keep the web servers hosting HTTP AIA/CDP files in sync with the CA’s CertEnroll folder, and monitor certificate and CRL file availability like any other production endpoint.

Compliance Teams

Confirm CRL publication intervals and CDP availability meet the organization’s Certificate Policy and any regulatory revocation-checking requirements.

CISOs

Track CDP/AIA outages as a revocation-checking risk: an unreachable CRL can silently let an application accept a certificate that should have been rejected.

Why This Matters: Data and Deadlines

According to DigiCert’s Trust Pulse survey (published July 2, 2025), nearly half of enterprises experienced a certificate-related outage in the past year, and more than half (56.6%) named tracking certificate and expiration data as a top concern. A broken CDP or AIA location is exactly the kind of silent failure that produces this outcome, since revocation checking fails quietly until an application starts rejecting valid certificates or accepting ones it shouldn’t.

The CA/Browser Forum’s Ballot SC-081v3 (approved April 11, 2025) locks in shrinking TLS certificate validity: 200 days starting March 15, 2026, 100 days starting March 15, 2027, and 47 days starting March 15, 2029. Shorter lifetimes mean CRLs and AIA endpoints get hit far more often, so a misconfigured decimal flag or a renamed file causes visible failures much sooner than it would have under the old 398-day maximum.

On the cryptography side, NIST finalized its first three post-quantum standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), on August 13, 2024. Any CDP/AIA design built today should assume certificate and CRL sizes will grow once post-quantum algorithms are in play, which is one more reason to get the publication flags and replacement tokens right now instead of patching around them later.

Prerequisites

Before configuring or troubleshooting CDP/AIA, confirm the following are in place:

• Administrative access to the CA server and its command line (certutil).
• Access to Active Directory tools (ADSIEdit.msc) if any CDP/AIA locations use LDAP.
• A documented list of every CDP/AIA URL currently in use, and whether each is HTTP, LDAP, or a file share.
• A test client outside the CA’s own network, so you can verify URLs resolve the way real clients will experience them.

Configuration of CDP/AIA Points

Proper configuration of CDP and AIA points can be tricky. It involves proper permission of where CRL needs to be published and where they would be accessed.

Improper configuration of CDP can result in two scenarios

• CRL fails to be published, or
• CRLs cannot be accessed

Configuration of AIA

AIA is the easiest to configure. If OCSP is used, the AIA decimal point may include 34; otherwise, it’s always 2.

Display Name	Decimal Value
Publish at this location	1
Include in the AIA extension of issued certificates	2
Include in the Online Certificate Status Protocol (OCSP) extension	32

Decimal Value 1 is included when publishing in the %windir%\System32\certsrv\CertEnroll location. It can also be included to publish directly onto the AIA location if proper permissions are provided.

[Note: If the location is behind a load balancer, the CA cannot access both servers and may cause failure. Please do not publish on those locations; instead manual copy is recommended]

Decimal Value 2 is included when the URL is to be added to the issued certificates. These URLs act as the AIA points from where the certificates can be extracted.

Configuration of CDP

Configuration of CDP can depend on how the CA is configured, how the CRLs are published and accessed, and if Delta CRLs are published.

Display Name	Description	Decimal Value
Publish CRLs at this location	Used by the CA to determine whether to publish base CRLs to this location	1
Include in the CRL Distribution Point (CDP) of issued certificates	Used by clients during revocation checking to find base CRL Location	2
Include in [base] CRLs	Used by clients during revocation checking to find delta CRL location from base CRLs	4
Include in all CRLs	An offline CA can use it to specify the LDAP URL for manual publishing CRLs. You must also set the explicit configuration container in the URL or the DSConfigDN value in the registry. certutil -setreg CA\DSConfigDN CN=	8
		16
		32
Publish Delta CRLs to this location	Used by the CA to determine whether to publish Delta CRLs to this location	64

Decimal values are used accordingly based on how the CDP needs to be configured.

Decimal Value 1 is mostly used to publish CRLs to %windir%\System32\certsrv\CertEnroll location or to those locations where CA has proper permissions to access. If Delta CRLs are also published, 65 (1+64) is used.

[Note: If the location is behind a load balancer, the CA cannot access both servers and may cause failure. Please do not publish on those locations; instead manual copy is recommended]

Decimal Value 2 includes the URL or location and lets it act as a CDP location from where base or delta CRLs are accessed.

Example

Decimal Value 79 = CRLs are published at that location (1) + Location is added to CDP (2) + Delta CRL location (4) + Include in all CRLs (8) + Publish Delta CRL at this location (64)

Decimal Value 65 = Publish CRL at this location (1) + Publish Delta CRL at this location (64)

Decimal Value 6 = Location is added to CDP (2) + Delta CRL location (4)

CRL Replacement Tokens

In the above examples, you may have noticed %1, %3, %4, %8, and %9. This represents how the CA is configured and what the file’s name should be. If the files are renamed, the AIA and CDP points may fail as the naming convention doesn’t match.

Token Name	Description	Map Value
ServerDNSName	The DNS name of the CA Server	%1
ServerShortName	The NetBIOS name of the server	%2
CAName	The name of the CA	%3
Cert_Suffix	The renewal extension of the CA	%4 (as per Windows 2000 mapping)
CertificateName		%4 (as per Windows 2003 mapping
ConfigurationContainer	The location of the Configuration container in AD	%6
CATruncatedName	The “sanitized” name of the CA	%7
CRLNameSuffix	The renewal extension of the CRL	%8
DeltaCRLAllowed	If Delta CRL is allowed, + is added at the end of the file to indicate a delta crl	%9
CDPObjectClass		%10
CAObjectClass		%11

Based on the mapping value, the AIA and CDP points are given a naming convention to find the correct file from those locations.

Debugging CDP/AIA Location Issues

If the CDP/AIA locations are properly configured, these steps will temporarily help resolve the issues. For example, we will use AIA issues, which will also work for CDP issues.

After we open and check PKIView.msc, we can see where the issue is. We can copy the URL to a notepad for further investigation.

The AD doesn’t have our certificate if the issue is on the LDAP location. This is quite an easy fix.

Certificates retrieved via LDAP are retrieved from Domain Controller. If we open Domain Controller and ADSIEdit.msc, then we can navigate to Services > Public Key Services > AIA and check the present certificates. Since our Issuing CA Certificate is absent, the PKI environment cannot retrieve the certificate from that location.

To resolve this, we navigate to our issuing CA and run the command
certutil -dspublish -f <path to certificate> SubCA

Once the command runs successfully, we can refresh our PKIView.msc to check if the issue is resolved, and we should see a clean slate

However, if the AIA location #2, or the HTTP location is causing errors, this error is because the certificate isn’t present at that server endpoint.

To resolve this, we copy the certificate from %windir%\System32\certsrv\CertEnroll location to our web server, which hosts our certificate.

This would resolve our issue, which we can check on PKIView.msc again.

Validation Checks After Configuration

• Run PKIView.msc after any CDP/AIA change and confirm every row shows OK, not “Unable to download” or an error state.
• From an external client, fetch each HTTP AIA/CDP URL directly and confirm it returns the expected .crt or .crl file.
• Confirm the CRL’s NextUpdate field is in the future by opening the CRL file or checking it with certutil.
• For LDAP-published certificates, open ADSIEdit.msc and confirm the certificate is present under the expected Public Key Services container.

Common Errors and Error Codes

• “Unable to download” in PKIView.msc: the location is unreachable, misnamed, or the replacement token doesn’t match the published file.
• CRL_E_REVOCATION_OFFLINE (0x80092013): a client can’t reach an HTTP CDP location, usually a firewall, DNS, or load-balancer issue.
• Missing certificate in AD (LDAP AIA failure): the CA certificate was never published to Active Directory; resolved with certutil -dspublish -f <path> SubCA (or RootCA for a root CA).
• CertUtil: -dsPublish command FAILED (access denied): the account running the command lacks write permission to the Public Key Services container in AD.
• File name mismatch after a manual copy: a certificate or CRL was renamed during copy and no longer matches the %1-%11 replacement-token pattern the CDP/AIA URL expects.

Rollback Steps

1. If a new decimal flag value breaks publishing, revert the CDP/AIA extension back to its previous value with certutil -setreg CA\CACertPublicationURLs or CA\CRLPublicationURLs using the saved prior string, then restart Certificate Services.
2. If a manual file copy introduced a naming mismatch, delete the incorrectly named file and re-copy it using the exact %1-%11 pattern documented for that CA.
3. If certutil -dspublish introduced an unwanted duplicate entry in AD, remove it via ADSIEdit.msc from the same Public Key Services container.
4. If a load-balanced location was mistakenly set for direct CA publishing, remove decimal value 1 from that location and switch back to manual copy.

CDP/AIA Configuration Reference Table

Use this table as a quick-reference summary of each CDP/AIA configuration task.

Prerequisite	Command / Configuration	Validation Check	Common Error	Rollback	Owner
AIA decimal flags set on the CA	certutil -setreg CA\CACertPublicationURLs with values 1, 2, and 32 as needed	PKIView.msc shows the AIA row as OK	0x80070005 access denied if not run elevated	Restore the previous CACertPublicationURLs string and restart Certificate Services	PKI Administrator
CDP decimal flags set on the CA	certutil -setreg CA\CRLPublicationURLs with combined values like 65, 79, or 6	New CRL publishes with certutil -crl and PKIView.msc shows the CDP row as OK	0x80092013 CRL_E_REVOCATION_OFFLINE if the location is unreachable	Restore the previous CRLPublicationURLs string	PKI Administrator
Replacement tokens matched to file names	Confirm %1 (ServerDNSName), %3 (CAName), %8 (CRLNameSuffix), %9 (DeltaCRLAllowed) map to the actual published file name	File names at the HTTP/LDAP location match the expected token pattern exactly	File name mismatch after a manual copy or rename	Re-copy the file using the documented token pattern	PKI Administrator
LDAP AIA/CDP publishing to Active Directory	certutil -dspublish -f <path to certificate> SubCA (or RootCA)	ADSIEdit.msc shows the certificate under Services > Public Key Services > AIA	Missing certificate in AD, or access denied on -dspublish	Remove the duplicate or incorrect AD entry via ADSIEdit.msc	PKI Administrator / Platform Team
HTTP AIA/CDP hosted on a web server	Copy the certificate/CRL from %windir%\System32\certsrv\CertEnroll to the web server	curl -I against the HTTP URL returns the expected file	Certificate not present at server endpoint (404)	Re-copy the file from CertEnroll and confirm web server permissions	Platform Team
Load-balanced or clustered CDP/AIA endpoints excluded from direct CA publishing	Use manual copy instead of decimal value 1 for load-balanced locations	Both nodes behind the load balancer serve the identical file	CA publishing failure because it can’t reach both nodes	Remove decimal value 1 for that location and resume manual copy	Security Architect / Platform Team

Certificate Lifecycle Management and PKI Modernization

CDP and AIA configuration is a foundational piece of certificate lifecycle management: get the decimal flags and replacement tokens wrong and every downstream renewal, revocation check, and machine identity inventory built on top of that CA inherits the problem. CertSecure Manager automates certificate lifecycle management, including certificate automation for issuance, renewal, and CDP/AIA-aware revocation checking, so teams don’t have to hand-verify decimal flags on every CA. Organizations moving away from self-managed CDP/AIA infrastructure altogether should evaluate PKI-as-a-Service for PKI modernization with hosted, pre-validated distribution points.

Because shrinking certificate lifetimes make CDP/AIA errors surface faster, this is also a good moment to build a broader crypto agility plan: the PQC Center of Excellence offers hands-on post-quantum testing, and a PQC readiness assessment can flag where certificate and CRL sizes will grow once post-quantum algorithms are involved. Pair both with CBOM Secure to keep a current certificate discovery and machine identity inventory instead of rediscovering every CDP/AIA location manually during the next incident.

For more on the surrounding lifecycle, see What Are the Stages in a Certificate Lifecycle? and How to Avoid Certificate Outages.

Measuring Success and Ongoing Audits

Track these signals for at least 30 days after any CDP/AIA change: zero “Unable to download” rows in PKIView.msc, zero CRL_E_REVOCATION_OFFLINE errors in client or firewall logs, and CRL NextUpdate dates that stay current without manual intervention.

This is policy- and vendor-adjacent guidance, so re-verify the decimal flag values and replacement-token mapping quarterly, especially around any CA/Browser Forum validity-period change, and re-check the full debugging walkthrough whenever a new CA is stood up.

Conclusion

Issues with CDP and AIA locations can be tricky. Misconfiguration can often cause issues, which can be harder to track. With this guide, we hope to make the configuration of CDP/AIA points much easier with debugging steps to support any technical issues. If your organization wants CDP/AIA health monitored automatically instead of checked manually in PKIView.msc, see how CertSecure Manager handles certificate lifecycle management, including revocation checking, across every CA in your environment.

Frequently Asked Questions

What is the main takeaway from Configuring and Troubleshooting CRL Distribution Points (CDP) and Authority Information Access (AIA)?

The main takeaway is that CDP and AIA are controlled by decimal publication flags and replacement tokens that must match the actual published file names exactly. When a flag is wrong or a file gets renamed, clients silently fail to retrieve the CA’s certificate or CRL, which shows up in PKIView.msc as an “Unable to download” error long before anyone else notices.

Why does this matter for enterprise PKI teams?

Enterprise PKI teams often run these locations for years without touching them, so a single overlooked change, a renamed file, a decommissioned load balancer, a moved web server, can quietly break revocation checking or certificate chain building across every application that trusts that CA.

What risks increase if this topic is handled manually?

Manual, undocumented CDP/AIA configuration increases the risk of decimal flag values drifting from what’s actually needed, replacement-token mismatches after a manual file copy, and load-balanced locations mistakenly set for direct CA publishing, which the CA cannot reach and which then breaks publishing entirely.

Which teams should own this change?

PKI administrators own the decimal flag configuration and replacement-token mapping, security architects decide which locations are internal versus internet-facing, platform teams keep the web servers hosting HTTP endpoints in sync with the CA’s CertEnroll folder, and compliance teams confirm CRL availability meets the organization’s certificate policy.

How does this connect to certificate lifecycle management?

CDP and AIA are the retrieval mechanism underneath every stage of certificate lifecycle management: issuance depends on AIA to build a trust chain, and revocation checking depends on CDP to find a current CRL, so a broken distribution point undermines the lifecycle even if issuance itself is working fine.

How should organizations measure success?

Success means zero “Unable to download” rows in PKIView.msc, zero CRL_E_REVOCATION_OFFLINE errors in client or firewall logs, CRL NextUpdate dates that stay current, and every published file name matching its documented replacement-token pattern.

What should be audited or monitored regularly?

Organizations should monitor PKIView.msc after any CA or file server change, audit CDP/AIA decimal flag values against documentation quarterly, confirm CRL publication intervals haven’t drifted, and verify load-balanced or clustered locations are still excluded from direct CA publishing.

How does this topic affect cloud, hybrid, or multi-CA PKI?

Cloud and hybrid PKI adds extra HTTP endpoints and load balancers that need the same manual-copy treatment as on-premises clustered servers, and multi-CA hierarchies require every issuing and root CA to have its own correctly configured CDP/AIA locations, since a single misconfigured CA in the chain breaks trust for everything it issued.

What prerequisites are required before implementation?

Before configuring or troubleshooting CDP/AIA, teams need administrative access to the CA and its command line, access to ADSIEdit.msc if any locations use LDAP, a documented list of every current CDP/AIA URL and its type, and a test client outside the CA’s own network to verify real-world resolution.

What common errors should administrators watch for?

Watch for “Unable to download” in PKIView.msc, CRL_E_REVOCATION_OFFLINE (0x80092013) on HTTP locations, a missing certificate in Active Directory for LDAP AIA (resolved with certutil -dspublish), access-denied errors from running certutil without elevated privileges, and file name mismatches after a manual copy that no longer match the %1-%11 token pattern.