I ran into this error today while configuring Certificate Based Authentication (CBA), and it was a weird enough of an issue that I thought it would be useful to post it, and share the fix.
After configuring my CRL so that it was published publicly (this is required for both your Root CA, as well as your Enterprise CA), and installing my certificates on both my ADFS servers and WAP servers (again, both the Root CA certificate and the Enterprise CA certificate are required), CBA was still failing when trying to log in to the Office 365 Portal.
Well, we’re no stranger to error logs and troubleshooting, right? Off we go to the ADFS logs to see what’s going on.
The Error: Event ID 342
This error basically states that it couldn’t build the trust chain for the certificate, usually because it can’t properly access your CRL all the way up the line.
I knew this wasn’t the case, because I had already tested that using one of my issued certificates – the command to do this is:
certutil -f -urlfetch -verify certname.cer
(replace certname.cer with the name of your cert)
This command will go through and check all of the URLs listed on the cert and verify connectivity to them – it’s great for checking your CRL/CDP/AIA distribution points and making sure that they’re all accessible internally and externally.
Next, I checked all my certificates on the local computer certificate store to verify that I didn’t have any old certificates, duplicates with wrong information, etc. – everything was as it was supposed to be. I eventually found an answer indirectly on this forum post – it didn’t list my issue exactly, or provide the fix I used, but it DID provide me with the tools I needed to figure it out.
The Fix: clear out old certificates
It turns out that the issue was being caused by old certificates sitting in the NTAuth store on my ADFS servers – it’s bizarre, because I had deleted all my old certificates and replaced them with new ones containing updated CRL distribution points, etc. However, that did not clear them out of this certificate store, as these certificates are being pulled directly from Active Directory.
Here’s how you check for these little deviants, and how to get ’em all fixed up:
Start by running the following command:
certutil -viewstore -user -enterprise NTAuth
This will pop up a view of your NTAuth certificate store: scroll through the list of certificates until you find the one relating to your Enterprise CA:
Now, you can see that the certificate is definitely still valid (not expired) – however, I know that I updated my CRL & AIA locations and the new certificate that I’ve installed on all my servers is valid from today’s date, not August 2017.
Next, open the certificate properties by clicking on the link below the date, and note the thumbprint of the certificate:
Next, open the registry, and match that certificate thumbprint against the certificates found in HKLMSoftwareMicrosoftEnterpriseCertificatesNTAuthCertificates.
Then I simply deleted the registry key that matched that thumbprint (always make a backup of your reg key before you delete it!). This time when I run checked my NTAuth store by running the command above, that Enterprise CA certificate was completely gone.
Finally, to update the NTAuth store and pull in a new certificate, I ran the following command:
Now when I check my NTAuth store, I can see that it’s pulled in the correct certificate:
You can, of course, verify this by opening the certificate and making sure that the thumbprint matches your current certificate, and that the correct CRL & AIA distribution points are listed. Once this was done, my trust chains were able to build correctly, and certificate based authentication immediately started working. 😀
There you have it… if your struggling to get CBA configured, and you know you’ve updated all your certs with the correct CDP, give this a shot and see if it solves your problem!