Fix SEC_E_REVOCATION_OFFLINE_KDC (0X80090358)

What triggers SEC_E_REVOCATION_OFFLINE_KDC

You'll see this error when Windows tries to check if a certificate has been revoked but can't connect to the Certificate Revocation List (CRL) server. It happens most often during Kerberos authentication—like when you're logging into a domain-joined machine, accessing a secure website, or using an application that uses certificate-based authentication. The error text reads something like: The revocation function was unable to check revocation because the revocation server was offline. The error code is 0X80090358.

In my 12 years running help desks, I've seen this error three main ways:

The CRL distribution point (CDP) in the certificate points to an LDAP URL that the machine can't reach.
Group Policy has certificate revocation checking turned on but the network blocks the CDP.
Time sync is off—the certificate's validity period doesn't match the machine's clock.

The fix depends on your environment. Let's start with the one that works 90% of the time.

Fix #1: The CRL distribution point is unreachable (most common)

This is almost always the issue in domain environments. The certificate has an LDAP URL embedded in it—something like ldap:///CN=MyCA,CN=MyServer,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint. Your computer tries to fetch the CRL from that LDAP path. But if the domain controller hosting that path is offline, or if the LDAP port (389) is blocked by a firewall, you get the error.

How to check

Open the certificate that's causing the error. Double-click the .cer file or look in certlm.msc (Local Machine) or certmgr.msc (Current User).
Go to the Details tab. Scroll down to CRL Distribution Points. Click it and read the URLs. You'll see one or more URLs—often LDAP, HTTP, or both.
Try opening the HTTP URL in a browser. If it fails, the CRL server isn't serving. For LDAP URLs, you'd need an LDAP browser to test—but the simpler test is to see if you can ping the domain controller or access it via \dcname\netlogon.

The fix

If the CRL is hosted on a domain controller that's down, you have a few options:

Bring the DC back online. If it's a temporary outage, wait for it to come back. Then refresh the certificate (gpupdate /force, then restart the service using the cert).
Publish the CRL to an HTTP location. On your Certificate Authority server, open the CA console. Right-click the CA name, choose Properties, go to the Extensions tab. Add an HTTP URL (like http://crl.yourdomain.com/crl/CertName.crl) and make sure it's checked for both CRL and Delta CRL. Then republish the CRL manually: run certutil -crl on the CA server.
If you can't fix the server, skip to Fix #2 or #3 below to disable the revocation check on the client. But only do that in environments where you trust the certificates—like internal PKI for domain authentication.

Fix #2: Group Policy forces revocation checking and the network blocks it

Some organizations set Group Policy to enforce certificate revocation checking for all Kerberos traffic. This is a security measure—but if your firewall or proxy blocks outbound HTTP traffic to the CRL URL, you'll hit this error. I've also seen this happen when the CRL URL uses an FQDN that doesn't resolve internally.

How to check

Run rsop.msc (Resultant Set of Policy) on the affected machine.
Go to Computer Configuration > Windows Settings > Security Settings > Public Key Policies.
Double-click Certificate Path Validation Settings. Under the Revocation tab, look for Revocation settings. If it's set to Define these policy settings and the checkboxes for Check all certificates and Also check if certificates are revoked are checked, that's your culprit.
Check the Network Retrieval tab—if it says Automatically update certificates in the certificate store is enabled, the machine will try to download CRLs.

The fix

You have two choices:

Temporarily disable the policy on the affected machine by reconfiguring the GP setting to Not configured or Disabled. Then run gpupdate /force and reboot. This is a quick test, not a long-term solution.
Add an exception in your firewall or proxy to allow the client machine to reach the CRL URL. Look at the certificate's CDP URLs (see Fix #1) and allow outbound TCP 80 (HTTP) or 389 (LDAP) to those servers.

If you're in a domain with a local CA, the cleanest fix is to publish the CRL to an HTTP server inside your network. Then update the CDP in the CA's certificate template to include that HTTP URL. That way, clients only need access to your internal web server—not the internet.

Fix #3: Time sync is off (least common but easy to overlook)

If the client machine's clock is more than a few minutes off from the CA's clock, Windows assumes the certificate might be invalid and tries to check revocation. If the CRL is unreachable, you get the error. This is rare because Windows uses domain time sync, but it happens with laptops that sit in sleep mode for days, or VMs that pause and resume.

How to check

Run w32tm /query /status in Command Prompt as administrator.
Look at the Source line—it should show a domain controller or a reliable time server (like time.windows.com).
Check the Last Successful Sync Time. If it's older than a day, you have a problem.
Compare the machine's time with the DC: run net time \\yourdomaincontroller.

The fix

Force a time sync: w32tm /resync /nowait.
If that fails, stop and restart the time service: net stop w32time & net start w32time.
Then try the resync again.
If it still won't sync, check Group Policy for Windows Time Service settings under Computer Configuration > Administrative Templates > System > Windows Time Service. Make sure Configure Windows NTP Client is set to a valid NTP server.

Once time is correct, the revocation check will succeed (assuming the CRL is reachable). If the CRL is still offline, the error will come back—in which case you're back to Fix #1 or #2.

Quick-reference summary table

Cause	Symptom	Fix	Applies to
CRL distribution point unreachable	Certificate's CDP URL (LDAP or HTTP) doesn't respond	Bring the CA server back online, publish CRL to HTTP, or add the CDP URL to allowed list	Domain-joined machines, internal PKI
Group Policy enforces revocation check	GP settings force revocation for all certificates, network blocks CRL	Disable the GP setting or unblock the CDP URL on the firewall	Domain-joined machines with managed GP
Time sync off	Client clock differs from CA clock by more than a few minutes	Resync time with w32tm /resync, check NTP config	Any machine, especially laptops and VMs

One last thing: if you're desperate and can't fix the server, you can disable certificate revocation checking entirely on the client via registry. But I don't recommend it for production machines. The key is HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings. Create a DWORD named CertificateRevocation and set it to 0. Reboot. This stops all revocation checks—including for HTTPS websites. Use only for testing.