Certutil CRL error - Failing to access revocation server

Help
1

I am a consumer rather than the owner of the domain - but my problem is with accessing Let's Encrypt servers. Still providing the relevant info.

My domain is: www.lavishsoft.com

I ran this command: certutil -f -urlfetch -verify ".crt"

It produced this output:

Issuer:
CN=R10
O=Let's Encrypt
C=US
Name Hash(sha1): 690fe41567ed6f7fb534446406066f0967077172
Name Hash(md5): a5bee5098a6e5f007b23cf58fe582c56
Subject:
CN=www.lavishsoft.com
Name Hash(sha1): e73a3c30d3840d19e1963ef0e0fa19bfb4fb6664
Name Hash(md5): 0c3a2526da58efa29dc5ccdbb883f180
Cert Serial Number: 06e51951f3be31d44f6787e55ef0f30fa8c4

dwFlags = CA_VERIFY_FLAGS_ALLOW_UNTRUSTED_ROOT (0x1)
dwFlags = CA_VERIFY_FLAGS_IGNORE_OFFLINE (0x2)
dwFlags = CA_VERIFY_FLAGS_FULL_CHAIN_REVOCATION (0x8)
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN (0x20000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=1000040
Issuer: CN=R10, O=Let's Encrypt, C=US
NotBefore: 5/24/2025 6:26 AM
NotAfter: 8/22/2025 6:26 AM
Subject: CN=www.lavishsoft.com
Serial: 06e51951f3be31d44f6787e55ef0f30fa8c4
SubjectAltName: DNS Name=www.lavishsoft.com
Cert: 18391dcad3bfcfe1fbb3c15f8304509c7c3b1f61
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
---------------- Certificate AIA ----------------
Verified "Certificate (0)" Time: 0 00abefd055f9a9c784ffdeabd1dcdd8fed741436
[0.0] http://r10.i.lencr.org/

---------------- Certificate CDP ----------------
Failed "CDP" Time: 0 (null)
Error retrieving URL: The connection with the server was terminated abnormally 0x80072efe (WinHttp: 12030 ERROR_WINHTTP_CONNECTION_ERROR)
http://r10.c.lencr.org/69.crl

---------------- Certificate OCSP ----------------
No URLs "None" Time: 0 (null)

Issuance[0] = 2.23.140.1.2.1
Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication

CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=ISRG Root X1, O=Internet Security Research Group, C=US
NotBefore: 3/12/2024 8:00 PM
NotAfter: 3/12/2027 7:59 PM
Subject: CN=R10, O=Let's Encrypt, C=US
Serial: 4ba85293f79a2fa273064ba8048d75d0
Cert: 00abefd055f9a9c784ffdeabd1dcdd8fed741436
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
Verified "Certificate (0)" Time: 0 cabd2a79a1076a31f21d253635cb039d4329a5e8
[0.0] http://x1.i.lencr.org/

---------------- Certificate CDP ----------------
No IDP Intersection "Base CRL (69)" Time: 0 5ed0044ac937193b78f9878ad7bac5c9ff7534ff
[0.0] http://x1.c.lencr.org/

---------------- Base CRL CDP ----------------
No URLs "None" Time: 0 (null)
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0 (null)

CRL 69:
Issuer: CN=ISRG Root X1, O=Internet Security Research Group, C=US
ThisUpdate: 12/10/2024 8:00 PM
NextUpdate: 11/10/2025 7:59 PM
CRL: 5ed0044ac937193b78f9878ad7bac5c9ff7534ff

Issuance[0] = 2.23.140.1.2.1
Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication

CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=ISRG Root X1, O=Internet Security Research Group, C=US
NotBefore: 6/4/2015 7:04 AM
NotAfter: 6/4/2035 7:04 AM
Subject: CN=ISRG Root X1, O=Internet Security Research Group, C=US
Serial: 8210cfb0d240e3594463e0bb63828b00
Cert: cabd2a79a1076a31f21d253635cb039d4329a5e8
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
No URLs "None" Time: 0 (null)
---------------- Certificate CDP ----------------
No URLs "None" Time: 0 (null)
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0 (null)

Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication

Exclude leaf cert:
Chain: 9c82015f753c209f2d37728b39aec0664842b9c9
Full chain:
Chain: 589fd928ed150440ca6a8a4a14cdcfe3b745f744

Verified Issuance Policies:
2.23.140.1.2.1
Verified Application Policies:
1.3.6.1.5.5.7.3.2 Client Authentication
1.3.6.1.5.5.7.3.1 Server Authentication
Cert is an End Entity certificate

ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)
CertUtil: The revocation function was unable to check revocation because the revocation server was offline.

CertUtil: -verify command completed successfully.

My web server is (include version): Well, I don't run the server. I am on a Windows 11 home PC.

... and I do not think the rest of the question really apply.
I am wondering if there might be any more context on specifically what issues would cause such a failure. My internet connection is generally fine, I am freshly rebooted (PC and Modem/Router). Within my web browser, the certificate is validated / the website shows as valid. It is when an application tries to make an https call to that domain that I am experiencing the error.

2

Let's Encrypt does not include OCSP info any longer since a few months now, that's most likely the issue.

I don't see any specific error regarding a CRL, but revocation checking is currently CRL only.

Edit: wait, I see something regarding http://r10.c.lencr.org/69.crl.. Well, that URI works nicely from my phone. So if that doesn't work for you, there's probably something wrong with your network or something similar.

1 Like
3

I get the same error from Certutil while able to get that CRL using curl and Certutil's -url option. So, they are not likely having a network or connection problem. I get some success with the CRL but same completion error from Certutil. See my next post.

I don't have time to dig into it further but seems like Certutil has some problems. Or, at least its response isn't clear exactly what is wrong.

Here is a snip of what I see. Note the dwErrorStatus is zero and the CRL info looks okay (but I am far from a certutil expert)

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
  Issuer: CN=R10, O=Let's Encrypt, C=US
  NotBefore: 5/24/2025 6:26 AM
  NotAfter: 8/22/2025 6:26 AM
  Subject: CN=www.lavishsoft.com
  Serial: 06e51951f3be31d44f6787e55ef0f30fa8c4
  SubjectAltName: DNS Name=www.lavishsoft.com
  Cert: 18391dcad3bfcfe1fbb3c15f8304509c7c3b1f61
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  ----------------  Certificate AIA  ----------------
  Verified "Certificate (0)" Time: 0 00abefd055f9a9c784ffdeabd1dcdd8fed741436
    [0.0] http://r10.i.lencr.org/

  ----------------  Certificate CDP  ----------------
  Verified "Base CRL (1855cdc387477f0d)" Time: 0 ebaa5ce70b42dfc803e606f6289f8b793bdb9169
    [0.0] http://r10.c.lencr.org/69.crl

At the bottom of the display it shows

ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)
CertUtil: The revocation function was unable to check revocation because the revocation server was offline.

CertUtil: -verify command completed successfully.
3 Likes
4

Oh, sorry, I guess my error was not the same as theirs. I get the same failure message at the end but my CRL lookup is fine and dwErrorStatus is zero.

@tscbp Are you able to retrieve the CRL separately? Like with a powershell command:

invoke-webrequest http://r10.c.lencr.org/69.crl

or

curl -i http://r10.c.lencr.org/69.crl

And, does that problem repeat? Is it possible you have a firewall blocking outbound requests using HTTP (rather than HTTPS)?

3 Likes
5

Hi, thanks for the responses. The curl fails with

curl: (56) Recv failure: Connection was reset

Yes, this problem is highly repeatable. It's interesting to me that Chrome has no problem with this cert.

Adding an explicit firewall exception for the program got it working. That is interesting, as I have been using it for a couple years without needing such an exception. Wondering if there is something different enough about the switch to CRL that caused an issue / change in how the firewall was treating these requests. Either way, thanks for taking a look.

1 Like
6

Chrome will try HTTP and HTTPS simultaneously (unless configured otherwise). If HTTPS worked Chrome won't care if HTTP does not. That is probably why it worked.

Yeah, OCSP should have had the same problem as it is HTTP too. I don't have a good guess on that :slight_smile:

3 Likes
7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.