Certificate errors after migrating to new Windows Certificate Authority (CA)

Question

I just migrated our domain certificate authority from Windows 2012 to Windows 2022. This was done by standing up an entirely new CA. Everything was fine until I recently did some cleanup in Active Directory to remove remnants of the old CA (as well as some other old CAs that were never cleaned up apparently). Note, the old CA servers have been offline for months without issue.

Now, suddenly, when accessing systems still using certs from the old CA (which should still be valid until their expiration) we are getting invalid cert errors citing messages such as:

• The host certificate chain is not complete, or
• The issuer of this certificate could not be found.

Further, when I view the certificate chain, the general tab states the cert was issued by our old CA, but the Certification Path tab now only lists the endpoint cert. The the issuing CA is no longer listed there. That explains the error, but I don't understand why this is happening.

How does a cert chain suddenly disappear on a cert? I thought that information was static. Further, I just don't understand why AD would even be involved in this. The CA root/issuing certs still exist on the workstations.

Any thoughts on why this is occurring and how to fix it, outside of generating new certs from the new CA? That will be a large task.

------EDIT------

I just realized what might be the problem. It looks like the issuing CA crl file is missing on the http CDP. The root crl is there.. I thought I brought this over. Clients must have been using the ldap CDP until I performed that cleanup. Unfortunately the old CA no longer exists unless I can find it in a backup somewhere. Will update if I find this missing crl!

Answer 1

Hello Matthew,

It sounds like you have identified the issue - the issuing CA CRL file is missing on the HTTP CDP. This can cause certificate validation errors, as the client cannot verify the revocation status of the certificate.

If you cannot find the missing CRL file, you may need to generate new certificates from the new CA. This can be a large task, but it may be necessary to ensure that your systems are secure and functioning properly.

In the future, it's important to ensure that all necessary CRL files are properly configured and available to clients. This can help prevent issues like the one you are experiencing.

Best regards

Qiuyang

Answer 2

Yeah the old CRL file is unavailable unfortunately (backups already purged). I'm looking to restore information into LDAP that I recently removed to fix the issue in the meantime.

Interestinly, in looking at the ldifde export of the data deleted, it appears I may be able to copy the CRL file straight out of AD and regenerate the CRL file. I'm going to play with that as well.

With that said, I've had CRL issues before but the error specifically mentioned inability to check revocation. This is different. I wonder why.

Answer 3

So it looks I found the issue. It's not the CRL (at least for the specific error I'm getting now). The root CA certificate was automatically removed from their local cert trusted root store when it was deleted from AD. I just confirmed this in my lab.

Anyway I simply imported the CA cert on the test machine throwing the error and now the error has gone away.

I guess I'm going to have to redeploy this CA cert via GPO and that should take care of the issue. OH, I forgot, I was able to regenerate the .crl file with the information that was stored in the config partition from a DC backup, but I'm not exactly sure how to test it as working.

EDIT: One odd thing I can't figure out is this all started as I noticed the error on my own machine, but somehow while troubleshooting it yesterday it automatically cleared up. At that time, I noticed I still had that root CA cert myself hence why my OP stated 'the root CA certs still remained on the workstations', and I continue to have it. Can't explain how my issue cleared up and how I got that CA cert as I never readded it.

Answer 4

Hello Matthew,

Redeploying the CA cert via GPO should help prevent this issue from occurring again in the future. As for testing the regenerated .crl file, you can try using the Certutil tool to verify the revocation status of a certificate that was issued by the CA. Regarding the odd behavior you experienced, it's possible that the root CA cert was automatically re-added to your machine through a Windows update or some other automated process.

Best regards

Qiuyang

Answer 5

Thanks again for the certutil tip. I was able to do a revocation check with the following command and it worked.

certutil -f –urlfetch -verify [FilenameOfCertificate]