Certificate revocation check fails for non-domain guest in spite of accessible CRL
After troubleshooting this with Microsoft support, we noticed that the delta CRL was not accessible to the client because IIS's default configuration does not support filenames with the +
character and delta CRL's end with +
. After enabling double escaping in IIS, the non-domain-joined client was able to confirm that the certificate had not been revoked.
Related videos on Youtube
0xFE
Updated on September 18, 2022Comments
-
0xFE almost 2 years
When we try to use certificates on computers that are not part of the domain, Windows complains that
The revocation function was unable to check revocation because the revocation server was offline.
However, if I manually open the certificate and check the
CRL Distribution Point
property, I see anldap:///
URL and anhttp://
URL that points to externally-accessible IIS site that hosts the CRLs. Of course, the non-domain-joined client cannot access theldap:///
URL, but it can download the CRL from thehttp://
link (at least in a browser).I enabled CAPI logging and I see the event that corresponds to this failed revocation check. The
RevocationInfo
section is:RevocationInfo
[ freshnessTime] PT11H27M4S
- RevocationResult The revocation function was unable to check revocation because the revocation server was offline.
[ value] 80092013 - CertificateRevocationList
[ location] UrlCache
[ url] http://the correct URL
[fileRef] 6E463C2583E17C63EF9EAC4EFBF2AEAFA04794EB.crl
[issuerName] the name of the CA
- RevocationResult The revocation function was unable to check revocation because the revocation server was offline.
Furthermore, I can see the HTTP request to the correct URL and the server's response (HTTP 304 Not Modified) with Microsoft Network Monitor.
I ran
certutil -verify -urlfetch
, and it seems to show the same thing: the computer recognizes both URLs, tries both, and even though thehttp://
link succeeds, returns the same error.Is there a way to have non-domain-joined clients skip the
ldap:///
link and only check thehttp://
one?Edit:
Theldap:///
URL isldap:///CN=<name of CA>,CN=<name of server that is running the CA>,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain name>?certificateRevocationList?base?objectClass=cRLDistributionPoint
The non-domain-joined clients may be on the domain network or on an external network. The
http://
CDP is accessible from the public internet.-
Ryan Ries almost 10 yearsVery good question that I myself have run into and do not know the answer to. I think it might be a bug. Has not been urgent enough for me to open a support case with MS about it though.
-
Ryan Ries almost 10 yearsYour only workaround may be re-issuing the certs with only the HTTP CDP on them.
-
cornelinux almost 10 yearsI am a bit confused. I think that an PKI enabled application should check all mentioned CDPs and use the one, it can find. So I would guess that his is a mistake of the client. Which application is using the certificates? Other possibility might be: What does the ldap-URL look like and where are the non-domain-joined client located. Maybe you could setup a fake ldap-system, that provides the CRL.
-
0xFE almost 10 years@cornelinux The actual client is a WCF program, but
certutil
, the built-in program is exhibiting the same behavior. The WCF client does not explicitly check for CDPs or anything, but the check happens automatically. -
cornelinux almost 10 yearsLooking at this (social.technet.microsoft.com/Forums/windowsserver/en-US/…) and the third answer by Brian (who probably is Brian Komar), he states, that you should only use HTTP in the CDP (no File, no LDAP).