Revocation Server Was Offline (0x80092013): A Read-First CRL, CDP, Cache, and Offline Root Triage

Helpdesk: "Since about 7:30 this morning the 802.1X Wi-Fi rejects every laptop, the VPN says the certificate couldn't be validated, and the issuing CA service won't start. Its error says the revocation function was unable to check revocation because the revocation server was offline, 0x80092013. The PKI admin is out; the offline root has been powered off in a closet since spring. A forum post says to set CRLF_REVCHECK_IGNORE_OFFLINE on the CA, set NoRevocationCheck on both NPS servers, and turn off revocation checking in the VPN profile. Can we start with that?"

Not yet. "Revocation server offline" almost never means a server is down. It means a client building a certificate chain couldn't get a current CRL for one of the certificates in it: the CRL expired, the CDP URL can't be reached from that client's network or security context, the URL was never published, or the client is still using a stale cached copy. Microsoft's DirectAccess article for 0x80092013 lists those four causes word for word, starting with "The CRL location (CDP) is unreachable." and ending with "The CRL is reachable but the client is picking from an old cache." Its chain-validation note explains the blast radius: "Revocation checking is performed from the root CA certificate down to the evaluated certificate." One expired root CRL breaks every certificate under it, and Wi-Fi, VPN, and the CA itself fail together. Turning off revocation checking hides the failed link and leaves it failed, and a CRL that's still expired tomorrow breaks the next app nobody exempted. Work through it as a chain: which app, which error code, which certificate, which context, since when → certutil -verify -urlfetch on that certificate, from the failing machine → which CRL failed: issuing, root, or delta, and its NextUpdate → can this client, in this context, reach the CDP URL? → does the web or LDAP location serve the current file? → CAPI2 events, which name the exact action that failed → caches → the CA: publication events, schedule, and CDP settings → the offline root's CRL → what each relying party does with an unknown result. certutil, Get-WinEvent, wevtutil, Invoke-WebRequest, Test-NetConnection, Get-CACrlDistributionPoint, and Get-ItemProperty are the sources for that chain. Set the ignore flags everywhere, and you'll be turning them back off one app at a time, with the CRL still expired.

If certificates aren't arriving at all, start with Certificate Autoenrollment Not Working; its Step 9 is where this post picks up. If the failure is a Wi-Fi profile on Intune-managed devices, Intune Wi-Fi Profile Not Applying covers the profile side. This post covers "Windows clients, servers, or the CA itself fail to validate certificates from an AD CS hierarchy with 'the revocation server was offline' (0x80092013) or 'unable to check revocation' (0x80092012), and you need a read-first path before you turn off revocation checking, set ignore-offline flags, or republish over the top."

TL;DR

• Read the chain before you touch the CA. certutil -verify -urlfetch on the failing certificate fetches every AIA and CDP URL in the chain and shows which one failed (Step 2). Microsoft's autoenrollment blog: "Verify that all certification authorities in the chain have valid CRL's published."
• Check NextUpdate on every CRL in the chain. Microsoft's CAPI2 guide: "If the current date is later than the date in the nextUpdate field in the CRL, it means that the CRL has expired." The offline root's CRL is the usual suspect, because nothing publishes it on a schedule (Steps 3, 9).
• Test from the context that fails. Microsoft's 0x80092013 article says to "verify that the CRL is downloadable from the system context". Services run as SYSTEM with WinHTTP proxy settings, not yours (Step 4).
• Publishing isn't delivering. Microsoft: certutil -CRL "writes new CRL data according to the CA configuration; it doesn't prove that a web server, replication process, or external transfer makes the new files available." (Step 5).
• A fixed CRL can still fail from cache. Microsoft's fix for the old-cache cause is certutil -setreg chain\ChainCacheResyncFiletime @now and certutil -urlcache * delete (Steps 7, 11).
• Ignore-offline flags are a stopgap with an owner and an end date, not a fix. The CA flag, the NPS keys, and the curl and Git switches all weaken validation (Step 10, common false starts).

Where in the chain did it break?

Step 1: Capture the symptom (read-only)

Write these on the ticket first:

The codes, each from Microsoft's Winerror.h page:

Then branch on what you see:

Step 2: Read the chain with certutil -verify -urlfetch (read-only)

This is the one test that answers most of the questions at once. Microsoft's autoenrollment blog: "The client does not have a valid certificate revocation list (CRL) from the issuing CA that it can use to check if a certificate has been revoked." Its test is to run certutil -v -verify -urlfetch against the issuing CA's certificate. Microsoft's CDP article uses the same test for any certificate: "From each representative network zone, validate the test certificate and retrieve its revocation data". Run it on the certificate that fails, on the machine that fails:

:: Read-only (writes one local file). Verify the chain and fetch every AIA and CDP URL in it (file names are examples) certutil -v -verify -urlfetch C:\Temp\failing.cer > C:\Temp\verify-failing.txt  :: Read-only (writes one local file). The issuing CA's own certificate, from the CA (config string is an example) certutil -config "CA01.contoso.com\Contoso Issuing CA" -ca.cert C:\Temp\issuing-ca.cer certutil -verify -urlfetch C:\Temp\issuing-ca.cer 

Microsoft's description of -verify: "Verifies a certificate, certificate revocation list (CRL), or certificate chain." Microsoft's caution on running it: "it will use the security and proxy settings of the user that runs it". An admin session that passes doesn't clear the SYSTEM account; Step 4 has the SYSTEM form.

How to read the output (structure from the sample output a user posted on Microsoft Q&A, community; status wording is our reading):

# Read-only. Pull the lines that matter out of the saved output (pattern list is ours) Select-String -Path C:\Temp\verify-failing.txt -Pattern 'CertContext|CDP|CRL \d|ThisUpdate|NextUpdate|Verified|Expired|Failed|0x8009' | Select-Object LineNumber, Line 

Step 3: Which CRL, and is it still time-valid? (read-only)

Every CA in the chain except the root's own certificate needs a current CRL: the root's CRL covers the issuing CA's certificate, and the issuing CA's CRL covers the leaf. Microsoft's CAPI2 guide on what expired looks like: "If the current date is later than the date in the nextUpdate field in the CRL, it means that the CRL has expired." Its fix is one line: "To fix this error, publish a time-valid CRL on the server."

Read the CRLs the clients actually download, not only the CA's copy. Take the HTTP URL from Step 2's output:

# Read-only (writes local files). Download each CRL from its HTTP CDP and read its validity (URLs are examples) $crls = @{ 'issuing' = 'http://pki.contoso.com/pki/ContosoIssuingCA.crl' 'root' = 'http://pki.contoso.com/pki/ContosoRootCA.crl' } foreach ($name in $crls.Keys) { Invoke-WebRequest -Uri $crls[$name] -OutFile "C:\Temp\$name.crl" -UseBasicParsing "== $name" certutil -dump "C:\Temp\$name.crl" | Select-String -Pattern 'ThisUpdate|NextUpdate' } 

certutil -dump "Dumps the configuration information or files." certutil -URL opens the same check interactively: it "Verifies certificate or CRL URLs." On the CA, read what the CA itself generated and what it thinks it published:

# Read-only. On the CA: the CRL files the CA writes locally (default CertEnroll path) and their timestamps Get-ChildItem -Path "$env:SystemRoot\System32\CertSrv\CertEnroll" -Filter *.crl | Select-Object Name, Length, LastWriteTime 

:: Read-only. On the CA: base and delta CRL publish status, then the CRL schedule values (Name* is certutil's prefix match) certutil -CAInfo crlstatus certutil -CAInfo deltacrlstatus certutil -getreg ca\CRLPeriod* certutil -getreg ca\CRLOverlap* certutil -getreg ca\CRLDelta* 

certutil -CAInfo lists crlstatus as "CRL Publish Status" and deltacrlstatus as "Delta CRL Publish Status". The CRL period is how long each CRL is valid; the overlap is the head start clients get. Microsoft's two-tier PKI lab guide: "The overlap period for CRLs is the amount of time at the end of a published CRLs lifetime that a client can use to obtain a new CRL before the old CRL is considered unusable". And: "The default setting for this value is 10% of the CRL lifetime." Microsoft's CDP article keeps the two ideas apart: "A publishing interval and a CRL validity period are different settings."

LDAP CDPs live in AD. Read when each CDP object last changed (our form; whenChanged moves when a CRL is written there, our reading):

# Read-only. CRL distribution point objects in the configuration partition and when each last changed $config = (Get-ADRootDSE).configurationNamingContext Get-ADObject -SearchBase "CN=CDP,CN=Public Key Services,CN=Services,$config" `  -Filter "objectClass -eq 'cRLDistributionPoint'" -Properties whenChanged | Select-Object DistinguishedName, whenChanged | Sort-Object whenChanged 

certutil -dsCRL "Displays DS CRLs." Add -config to point it at one CA (our reading of its options).

Step 4: Can this client, in this context, reach the CDP? (read-only)

Microsoft's 0x80092013 article lists five reasons a CRL location is unreachable, including "System context proxy is applied but unreachable and requires user authentication." and "CRL Location requires authentication before access is granted." Microsoft's CDP article puts the test plainly: "Test the exact CDP URL from that client network."

Name and port first, from the failing machine:

# Read-only. The CDP host from Step 2: DNS answer, then TCP 80 (host name is an example) $cdpHost = 'pki.contoso.com' Resolve-DnsName -Name $cdpHost Test-NetConnection -ComputerName $cdpHost -Port 80 -WarningAction SilentlyContinue | Select-Object ComputerName, RemoteAddress, TcpTestSucceeded 

Then the context. Services don't use your browser's proxy. Read the machine's WinHTTP proxy and the two hives Microsoft's article checks for the system context:

:: Read-only. WinHTTP proxy (what many services use), then the proxy values Microsoft's 0x80092013 article reads netsh winhttp show proxy reg query "HKU\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable reg query "HKU\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer reg query "HKU\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v AutoConfigURL 

Then repeat Step 2 as SYSTEM. Sysinternals PsExec's -s switch will "Run the remote process in the System account." Run locally, it does the same on this machine (our reading):

:: Read-only (writes one local file). Step 2's test as SYSTEM on the failing machine psexec -s cmd /c "certutil -verify -urlfetch C:\Temp\failing.cer > C:\Temp\verify-system.txt" 

Then the URL list. Microsoft's PKI design page: "Remember that Windows clients always retrieve the list of URLs in sequential order until a valid CRL is retrieved." An LDAP URL first in the list costs a non-domain or off-network client a timeout before it reaches HTTP. The same page: "Use HTTP CDP locations to provide accessible CRL locations for clients running non-Windows operating systems." For Entra joined devices, Microsoft's Windows Hello for Business guide says the same: "Publish your certificate revocation list to a location that is available to Microsoft Entra joined devices, such as a web-based URL". Microsoft's CAPI2 guide rules one scheme out: "CryptoAPI does not support the FTP protocol for network retrieval."

Step 5: Does the web or LDAP location serve the current file? (read-only)

The CA writing a CRL and a client getting it are separate jobs. Microsoft: "The CA's local generation result doesn't validate the delivery chain." Its monitoring advice: "At each HTTP endpoint, verify that the expected CRL file is current, complete, and readable by the intended clients." Compare the CA's file with what the web server hands out:

# Read-only. Same bytes on the CA and at the HTTP CDP? (file names are examples; C:\Temp\issuing.crl is Step 3's download) Get-FileHash -Path "$env:SystemRoot\System32\CertSrv\CertEnroll\ContosoIssuingCA.crl", 'C:\Temp\issuing.crl' -Algorithm SHA256 | Select-Object Hash, Path 

Different hashes with a current CA file means the copy job, the share, or the replication between web servers didn't run (our reading). Microsoft's lab guide grants Cert Publishers modify rights on the web server's pki folder so the CA can write there; its 0x80092013 article adds "check File System Permissions on the CRL and Delta CRL files."

Delta CRLs and IIS. A delta CRL's file name carries a +. Microsoft's lab guide: "Allowing double escaping is needed if you are publishing Delta CRLs to IIS because the Delta CRL file contains a + symbol." IIS's request filtering reference: "If set to true, request filtering will allow URLs with doubly-escaped characters." and "The default value is false." Read the setting on the CDP's site or folder:

# Read-only. On the IIS server: double escaping on the CDP folder (site and folder names are examples) Import-Module WebAdministration Get-WebConfigurationProperty -PSPath 'IIS:\Sites\Default Web Site\pki' -Filter system.webServer/security/requestFiltering -Name allowDoubleEscaping 

Microsoft's CDP article also asks for "the .crl MIME mapping required by your web-server policy" and for checking "the actual HTTP response after deployment". Step 3's Invoke-WebRequest download is that check for the base CRL; repeat it with the delta file name (the + one) from Step 2's Base CRL CDP line.

Step 6: Turn on CAPI2 logging and read the action that failed (read-only, one log switch)

When -urlfetch passes and the app still fails, the CAPI2 log shows what the app's own validation did. Microsoft's CAPI2 guide on why the app's message isn't enough: the API "was designed to return an error code and string", so many network problems reach the app as revocation offline. Enable the log, make it bigger, reproduce once, export, and turn it off. Microsoft: "The default size for the event log is 1 MB." It recommends "at least 4 MB to capture relevant events".

:: Low-risk. Enable CAPI2 logging at 4 MB, reproduce the failure, export, then disable (Microsoft's wevtutil forms) wevtutil sl Microsoft-Windows-CAPI2/Operational /ms:4194304 wevtutil sl Microsoft-Windows-CAPI2/Operational /e:true :: reproduce the failure now, then: wevtutil epl Microsoft-Windows-CAPI2/Operational C:\Temp\capi2.evtx wevtutil sl Microsoft-Windows-CAPI2/Operational /e:false 

# Read-only. CAPI2 errors, then the ones whose XML names a known revocation action (action list from Microsoft's guide; the filter is ours) $capi = Get-WinEvent -LogName 'Microsoft-Windows-CAPI2/Operational' -MaxEvents 2000 -ErrorAction SilentlyContinue $capi | Where-Object Level -eq 2 | Select-Object TimeCreated, Id, TaskDisplayName | Format-Table -AutoSize $capi | Where-Object { $_.ToXml() -match 'CheckTimeValidity|CanRetrieveFromNetwork|CanCheckServerForUpdatedCrl|BadProxy|GetCrlOrOcspUrls|IsCrlSignatureValid|2EE7|2EFD' } | Select-Object TimeCreated, Id, TaskDisplayName 

Microsoft's guide names the events to open: results are in CertVerifyRevocation, and "To find the cause, you need to look at the" CertRejectedRevocationInfo and CryptRetrieveObjectByUrlWire events nested under it. In CertGetCertificateChain, the status flags CERT_TRUST_REVOCATION_STATUS_UNKNOWN plus CERT_TRUST_IS_OFFLINE_REVOCATION mean the revocation information couldn't be retrieved or was invalid. The actions, each from Microsoft's guide:

Microsoft's summary for the network rows: "fix the underlying component (such as network, proxy settings, Web server, or LDAP) that is causing failure."

Step 7: Is the client using a cached old CRL? (read-only)

Clients keep CRLs. Microsoft's 0x80092013 article: "The CRL is retrieved by clients who can then cache the CRL (based on the configured lifetime of the CRL)". So a CRL you republished an hour ago doesn't help a client that cached the old one, and its fourth cause is exactly that: "The CRL is reachable but the client is picking from an old cache." Read the cache before you clear it:

:: Read-only. Cached CRL URLs for the current user's context (certutil's CRL filter), saved for the ticket certutil -urlcache CRL > C:\Temp\urlcache-crl.txt 

Microsoft's syntax note for -URLCache: delete "deletes relevant URLs from the current user's local cache." Run the read in the same context as the failure: as the user for a user app, and as SYSTEM (Step 4's PsExec form) for a service (our reading).

CAPI2's back-off is a second kind of cache. After repeated offline results it stops asking; the CanRetrieveFromNetwork event gives the EarliestOnlineTime it will try again (Step 6).

Step 8: The CA side: publication, schedule, and CDP settings (read-only)

Did the CA publish? Microsoft's AD CS event list gives the CRL publication events in the Application log:

# Read-only. On the CA: chain, publication, and startup events, last 30 days (IDs from Microsoft's AD CS event list) Get-WinEvent -FilterHashtable @{ LogName = 'Application'; ProviderName = 'Microsoft-Windows-CertificationAuthority' Id = 48, 49, 65, 66, 67, 74, 75, 100; StartTime = (Get-Date).AddDays(-30) } -ErrorAction SilentlyContinue | Select-Object TimeCreated, Id, Message | Format-List # Read-only. Is Certificate Services running? Get-Service -Name CertSvc | Select-Object Name, Status, StartType 

A Microsoft Q&A post shows what a failed LDAP publish looks like in practice: "could not publish a Base CRL for key 0 to the following location: ldap:///" with a logon failure code (community; the location is redacted in the post).

Where does the CA publish, and what do certificates carry? Microsoft: the CA's CDP configuration "represents both publication and retrieval settings". Read both:

# Read-only. On the CA: every CDP and AIA entry with its flags (Microsoft's lab guide uses the same Format-List form) Get-CACrlDistributionPoint | Format-List Get-CAAuthorityInformationAccess | Format-List 

Microsoft's cmdlet page lists the flags on each CDP entry: PublishToServer, PublishDeltaToServer, AddToCertificateCdp, AddToFreshestCrl, AddToCrlCdp, AddToCrlIdp, and Uri. PublishToServer is where the CA writes; AddToCertificateCdp is what clients get told. A URL with AddToCertificateCdp and nothing that copies the file there is a CDP that goes stale on its own (our reading).

The trap with CDP changes: "Changing a CDP URL affects only certificates issued after the change." Microsoft's design page says the same: "Modifying the URL for a CRL distribution point only affects newly issued certificates." Certificates issued before a change still point at the old URL. Microsoft's troubleshooting table for that case: "Keep the old CDP online and restore current CRL content there. A CDP configuration change doesn't repair old certificates."

The CA's own startup. Microsoft's Event 100 page: AD CS "startup can fail if there are problems with availability, validity, and chain validation for the CA certificate." Its resolution includes: "If a CRL for a CA in the chain has expired, generate new base and delta CRLs on this CA and copy them to the required locations." Microsoft's lab guide is blunt about the subordinate: if it can't find its parent's CRLs, the service "will fail to start on the subordinate CA". For the issuing CA, the parent is usually the offline root, so Step 9 is the fix. Read the CA's current ignore flags before anyone changes them:

:: Read-only. On the CA: CRLFlags as set now (a stopgap someone set last year shows up here) certutil -getreg ca\CRLFlags 

Step 9: The offline root's CRL (read-only)

The offline root is the one CA nobody turns on, so its CRL is the one that expires. Microsoft's CDP article: "For an offline root CA, avoid delta CRLs unless a documented requirement justifies them. Use a scheduled, witnessed process to publish a new ba...