0

We have a typical offline root and issuing intermediate CA Enterprise environment.

My problem is very similar to the one found here: Certificate revocation check fails for non-domain guest in spite of accessible CRL However, I have already tried the solution posted there and it has not fixed my problem. I have tested to make sure both the full and delta CRLs are accessible from non-domain computers. We recently reconfigured our CRL distribution point to remove LDAP and only use an http distribution point. During the change, we noticed this problem. It only affects non-domain computers.

As an example, we use RDP certs in our environment. There is a GPO that is configured to distribute certs to computers. Throughout the domain, these are successfully distributed and verified within the domain. If a non-domain computer tries to RDP to a domain computer, it will consistently fail to verify the certificate revocation.

If a non-domain computer is able to retrieve the CRLs and delta CRLs successfully via http, I don't know what else is required. Any assistance is appreciated.

Steve G.
  • 1
  • `If a non-domain computer tries to RDP to a domain computer, it will consistently fail to verify the certificate revocation.` Let's see the packet capture on tcp/80 from that client to the CDP during the failure. Also what is in the CAPI2 event log. – Greg Askew May 26 '23 at 20:07
  • @GregAskew Thank you for your interest in my question. The CAPI2 log on the client is empty but you weren't specific about on which system I should be looking for that log. As far as the Wireshark capture goes. It looks pretty cut and dry to me. Maybe there's something I'm missing. The capture can be found [here](https://pastebin.com/r9QpU0vK). – Steve G. May 31 '23 at 15:39
  • The CAPI2 log is disabled by default. You may need to enable it. It should be reviewed on the system that is exhibiting the symptom. – Greg Askew May 31 '23 at 21:15
  • The CRL is digitally signed (allows clients to check integrity) so the client would need (at least) the certificate corresponding to the private key that created the digital signature in order to verify the signature. Likely domain-joined computers get this certificate(s) automatically, but non-domain joined ones don't. From the AD CS [docs](https://tinyurl.com/msadcrlsign): `Like Certificates, each CRL is digitally signed by the CA which has published the CRL. Also, each CRL has a validity period beyond which it is no longer valid.` – Binky Jun 03 '23 at 17:41

0 Answers0