STATUS_REVOCATION_OFFLINE_KDC (0xC000040C) Fix Guide

What triggers this error

STATUS_REVOCATION_OFFLINE_KDC shows up when a domain controller tries to check if a certificate used for Kerberos authentication (smart card logon, PKINIT, VPN cert) has been revoked, but the CRL distribution point (CDP) isn't reachable. The KDC gives up and denies the login. You'll see this in event logs with the error code 0xC000040C. The most common scenario: a user tries to log in with a smart card from a remote site where the CA's CRL is published on an internal web server they can't reach.

Cause #1: KDC can't reach the CRL distribution point

This is the culprit 9 times out of 10. The domain controller can't download the current CRL because the URL in the certificate's CDP extension points to an internal server that's unreachable from the KDC's network context. This happens with:

• Certificates issued by an internal CA where the CDP points to an intranet URL (e.g., http://ca.company.local/crl/MyCA.crl) but the KDC sits in a different subnet with no routing.
• Cross-forest authentication where the CRL is published in forest A but the KDC in forest B can't access it.
• VPN or DirectAccess scenarios where the KDC can't see the CA server during initial auth.

The fix: Verify the CRL distribution points on the certificate. Use certutil on the KDC:

certutil -urlfetch -verify certfile.cer

Look for the "CRL Distribution Point" section. If it shows HTTP URLs, test connectivity from the KDC:

certutil -URL http://ca.company.local/crl/MyCA.crl

If that fails, you have two options:

1. Reissue the certificate with a CDP that points to a public or universally reachable location (like an HTTP-based CRL on a load-balanced web server).
2. Or, for testing only, disable revocation checking on the KDC (see Cause #3). Don't do that in production.

Cause #2: Expired or missing CRL on the CA

Even if the KDC can reach the CDP, the CRL file itself might be expired or missing. CRLs have a lifetime—typically set between 1 day and 1 week. If the CA stops publishing new CRLs (disk full, service hung, expired CA certificate), the KDC sees a stale CRL and throws 0xC000040C.

Check this: On the issuing CA, run:

certutil -crl

This forces a new CRL publish. Then verify the CRL file is present at the CDP location. For a web-based CDP, check the IIS logs to confirm the KDC requested it. If the CRL is on an LDAP path (e.g., ldap:///CN=CA,CN=CDP,...), make sure the KDC can bind to Active Directory and read the CRL object.

Cause #3: KDC registry tweak as a band-aid

In some locked-down environments—air-gapped networks, or where you absolutely can't change the certificate—you can tell the KDC to skip revocation checking for Kerberos authentication. This is a security downgrade, so only do it if you understand the risk (revoked certs will still work).

Set this DWORD on all domain controllers handling authentication:

HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Value: KdcAllowCachedCRL
Type: REG_DWORD
Data: 0

Setting it to 0 tells the KDC to not bother checking CRLs at all for PKINIT requests. The default (1) requires a valid, non-expired CRL. Reboot the KDC service or restart the server.

There's also KdcUseClientCred (set to 0) if the KDC is trying to use the client's network context to fetch the CRL and failing. I've rarely needed that one.

Quick-reference table

Start with Cause #1. That's where 90% of these tickets end.