Certificate chains and revocation

Capture the certificate the application used

Begin with an exported public certificate and its thumbprint, issuer, serial number, validity interval, names and intended usage. Exporting a .cer for inspection does not require exporting its private key. Confirm the certificate came from the failing connection or application’s configured store; a nearby certificate with the same subject might have different keys, issuers or validity.

certutil -dump certificate.cer

Also record the validating host, service identity, network, time and exact error. Compare a working and failing client using the same certificate before changing the CA. Chain discovery depends on the validator’s stores and available information. An application using its own trust bundle might not use the Windows chain engine at all. Microsoft’s chain-engine overview explains why validation involves a constructed chain rather than only the leaf certificate.

Read the complete chain result

Active network diagnostic: this can download issuer certificates and revocation information and populate local caches:

certutil -verify -urlfetch certificate.cer
certutil -URL certificate.cer

Save the complete output and find the failed chain element and URL. The final error line usually isn’t enough. A leaf can be valid while an intermediate is expired, untrusted or lacks reachable revocation data. Microsoft’s certificate-chain troubleshooting procedure shows how to read the result. It’s an AD FS example; a successful test there doesn’t cover every application’s policy.

Do not place an intermediate in Trusted Root simply to make chain construction succeed. Discovering an issuer through AIA supplies a candidate certificate; it does not establish trust in that issuer.

Distinguish AIA, CDP and OCSP

The issued certificate contains the locations clients will use. CA configuration changes apply to future issuance; they cannot rewrite extensions in certificates already distributed.

Keep publication endpoints reachable for the lifetime of the certificates that name them. A CA hostname change can therefore leave a dependency on the old HTTP/LDAP path. Microsoft’s CA migration guidance specifically calls for reviewing old certificate-extension locations during migration.

Separate publication destinations from client URLs

Adding an HTTP URL to a certificate does not publish a CRL there. The CA’s write destination might be a local directory or a UNC share whose content is separately served over HTTP. Check the publisher’s write identity, transfer job and permissions independently from the client’s retrieval identity.

On the CA, these commands read the selected local CA’s configuration:

certutil -getreg CA\CRLPublicationURLs
certutil -getreg CA\CACertPublicationURLs

Each entry carries separate flags for publication, inclusion in issued certificates and delta-CRL discovery. Work through those flags for each location rather than borrowing the list from another CA. Microsoft’s CDP/AIA configuration example shows the different HTTP inclusion and file-share publication settings. Adapt those to the existing topology rather than deleting every location to match the example.

Compare the expanded name in a newly issued certificate with the file actually published. CA renewal can change suffixes represented by placeholders such as <CertificateName> and <CRLNameSuffix>. Copying yesterday’s filename won’t help if the new certificate points somewhere else. Keep the older files needed by certificates under earlier CA keys.

Inspect the CRL itself

Retrieve the CRL named by the failing certificate, then inspect the file:

certutil -dump issuing-ca.crl

Record the issuer, signature, CRL number, ThisUpdate, NextUpdate, and whether a delta CRL/base CRL relationship is involved. ThisUpdate describes publication time and NextUpdate the next scheduled update. Compare these times with the validator’s clock and the file actually returned from the publication endpoint. The CRL data structure defines those fields.

A web server can return HTTP 200 while serving the wrong or expired CRL. Equally, the current file on the CA can be healthy while a copy on the external publication server is stale. Compare the downloaded bytes and CRL metadata at each stage of the publication path. If delta CRLs are used, test that the matching base and delta are both obtainable and valid.

A delta CRL is not simply “changes since the last delta.” Its critical Delta CRL Indicator contains a BaseCRLNumber; it represents cumulative updates relative to that base. A compatible complete CRL must match issuer and scope, have a CRL number at least that base number and lower than the delta’s number, and use the appropriate signing key. This is why any reachable .crl file is not necessarily the required base. RFC 5280 delta-CRL rules.

Plan publication with enough time for transfer, replication, retrieval and a failed operation to be corrected. Next CRL Publish, when present, provides another scheduling signal; do not confuse it with NextUpdate. Microsoft’s revocation operations guidance covers base/delta publication and endpoint verification separately.

An offline root still publishes the CRL used to check certificates it issued, such as an issuing CA’s certificate. This remains necessary even when the root’s self-signed trust-anchor certificate is excluded from the application’s revocation checks. Separate that parent-CRL dependency from the issuing CA’s own CRL for end-entity certificates. See PKI availability design.

Revocation offline does not mean revoked

0x80092013, CRYPT_E_REVOCATION_OFFLINE, means the validator could not complete the revocation check. Common causes include an unreachable or unpublished CDP, an expired CRL and a cached stale result. The failure can also depend on whether the validating service can use the proxy or authenticate to the endpoint. Microsoft’s revocation-offline investigation illustrates these distinctions.

Repeat the test from the relevant network and identity context. An administrator’s browser may have proxy credentials, a warm cache or a trust store that the service lacks. Investigate that difference rather than disabling revocation in the application. Save the cache state before clearing it; it may contain the clue explaining the failure.

Capture the application’s chain activity

On the validating machine, check Microsoft-Windows-CAPI2/Operational. Note whether the channel is enabled, enable it if needed, then reproduce one failure and save the events:

wevtutil gl Microsoft-Windows-CAPI2/Operational
wevtutil sl Microsoft-Windows-CAPI2/Operational /e:true

The second command changes event logging. Restore the recorded enabled state after the collection. Correlate the event timestamp, process details, certificate thumbprint, chain status and retrieval URL with the application failure. Microsoft’s diagnostic logging primer documents the channel and switch. A quiet CAPI2 channel is inconclusive if the application uses another TLS/crypto implementation.

Verify the relying application’s policy

A chain-building test and a TLS-server-name check are related but distinct operations. Windows exposes separate chain-policy checks for TLS, basic constraints, Authenticode and NT authentication. CertVerifyCertificateChainPolicy documents those policies.

After fixing the failed element, repeat the original operation with the application’s configured identity and name. For LDAPS, test the intended FQDN, TLS session and LDAP bind. For domain certificate authentication, continue to strong certificate mapping: a trusted, unrevoked certificate can still map to no account, or to the wrong account.

If OCSP is the failed status path, use responder diagnosis to compare issuer-key coverage, response signing and data freshness. A passing CRL fallback test does not establish that the responder is healthy.