Smartcard login fails with error message "A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)"

Author Uwe GradeneggerPosted on Categories Active Directory, Security, Smartcard, Troubleshooting, Certificate usageTags , , , , , , , , ,

Assume the following scenario:

  • The company would like to use smartcard logon.
  • The domain controllers are equipped with certificates that can be used for smartcard logon.
  • The users are equipped with certificates that can be used for smartcard logon.
  • The login to the domain via smartcard fails with the following error message:
A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)

In German, the error message reads:

The certification chain was processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)

Possible causes

Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the Application of regulationsto realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can downloaded via GitHub and can be used free of charge. Professional maintenance is also offered.

The error code CERT_E_UNTRUSTEDCA indicates - as the corresponding description text implies - a lack of trust status.

Usually, the certificates involved (domain controller and user certificate) are checked by exporting them to a file and executing the following command:

certutil -verify -urlfetch {filename}.cer

However, you will notice that this command does not reveal any errors:

So apparently everything is fine with the certificates?

No.

Neben dem reinen Vertrauensstatus zur ausstellenden Zertifizierungsstelle gibt es weitere feingranulare Zustände:

  • If the certification authority is authorized to issue certificates with the corresponding extended key usages (Extended Key Usage, EKU) authorized? (Application Policies)
  • Is the certification body authorized to issue certificates with the corresponding certificate guidelines? (Issuance Policies)
  • Is the certification body authorized to issue certificates for a PKINIT application? (Membership of the NTAuthCertificates object)

While the first two criteria can still be recognized by the certutil command, this is not the case for NTAuthCertificates membership.

Eine Möglichkeit, diese zu überprüfen ist folgender Befehl:

certutil -dcinfo verify

Please be sure to include the keyword "verify"!

Please also consider the following article if the error code "CRYPT_E_NOT_FOUND" appears: certutil -dcinfo fails with error message "KDC certificates: Cannot find object or property. 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)"

Here we encounter the previous error message again:

A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)

Then it's clear, isn't it? One of our certification authorities is not a member of NTAuthCertificates!

Als Faustregel gilt: Der Fehlercode CERT_E_UNTRUSTEDCA deutet grundsätzlich immer auf ein Problem mit der Mitgliedschaft einer beteiligten Zertifizierungsstelle in NTAuthCertificates hin.

However, a check shows that the certification body is duly registered here:

Then why is the certificate not considered usable for PKINIT?

It is important to know that it does not work directly against the data from the Active Directory configuration partition, but against a replica in the local registry of the respective system.

However, this is not automatically activated. So let's have a look:

certutil -v -getreg -GroupPolicy enroll\AEPolicy

See also article "Troubleshooting for automatic certificate request (autoenrollment) via RPC/DCOM (MS-WCCE)„.

And here we notice that synchronization has apparently been deactivated:

Of course, this is exactly what happens if nothing is configured.

For replication to take place, at least the "AUTO_ENROLLMENT_ENABLE_TEMPLATE_CHECK" flag must be activated. In the corresponding group policy known as "Update certificates that use certificate templates".

We then apply the group policy and start the synchronization process with the following commands.

For the computer context:

certutil -pulse

For the user context:

certutil -pulse -user

The verification of our domain controller certificates will then also be successful. You should now be able to log in without any problems.

Related links:

External sources

en_USEnglish
de_DEDeutsch en_USEnglish