Smartcard-Anmeldung schlägt fehl mit Fehlermeldung „A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)“

Assume the following scenario:

Das Unternehmen möchte Smartcard-Anmeldung einsetzen.
Die Domänencontroller sind mit für Smartcard-Anmeldung verwendbaren Zertifikaten ausgestattet.
Die Benutzer sind mit für Smartcard-Anmeldung verwendbaren Zertifikaten ausgestattet.
Die Anmeldung an der Domäne per Smartcard schlägt mit folgender Fehlermeldung fehl:

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

Im deutschen lautet die Fehlermeldung:

Die Zertifizierungskette wurde richtig verarbeitet, doch wird eines der Zertifizierungsstellen-Zertifikate vom Richtlinienanbieter nicht für vertrauenswürdig gehalten. 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.

Der Fehlercode CERT_E_UNTRUSTEDCA deutet – wie die der dazugehörige Beschreibungstext impliziert – auf einen fehlenden Vertrauensstatus hin.

Üblicherweise überprüft man also die beteiligten Zertifikate (Domänencontroller und Benutzerzertifikat), indem man sie in eine Datei exportiert und folgenden Befehl ausführt:

certutil -verify -urlfetch {filename}.cer

Jedoch wird man feststellen, dass dieses Kommando keinerlei Fehler erkennen lässt:

Augenscheinlich ist also mit den Zertifikaten alles in Ordnung?

Nein.

Neben dem reinen Vertrauensstatus zur ausstellenden Zertifizierungsstelle gibt es weitere feingranulare Stati:

Ist die Zertifizierungsstelle zur Ausstellung von Zertifikaten mit den entsprechenden Erweiterten Schlüsselverwendungen (engl. Extended Key Usage, EKU) berechtigt? (Anwendungsrichtlinien, engl. Application Policies)
Ist die Zertifizierungsstelle zur Ausstellung von Zertifikaten mit den entsprechenden Zertifikatrichtlinien berechtigt? (Ausstellungsrichtlinien, engl. Issuance Policies)
Ist die Zertifizierungsstelle zur Ausstellung von Zertifikaten für eine PKINIT-Anmeldung berechtigt? (Mitgliedschaft im NTAuthCertificates Objekt)

Während die ersten beiden Kriterien von besagtem certutil-Befehl noch erkannt werden können, ist dies bei der NTAuthCertificates-Mitgliedschaft nicht der Fall.

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

certutil -dcinfo verify

Bitte unbedingt das Schlüsselwort „verify“ mit angeben!

Bitte auch folgenden Artikel berücksichtigen, sollte der Fehlercode „CRYPT_E_NOT_FOUND“ auftauchen: certutil -dcinfo fails with error message "KDC certificates: Cannot find object or property. 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)"

Hier treffen wir wieder auf die vorige Fehlermeldung:

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

Dann ist die Sache klar, oder? Eine unserer Zertifizierungsstellen ist nicht Mitglied von NTAuthCertificates!

Eine Prüfung ergibt jedoch, dass die Zertifizierungsstelle ordnungsgemäß hier eingetragen ist:

Warum wird das Zertifikat dann nicht als für PKINIT nutzbar betrachtet?

Dazu muss man wissen, dass nicht direkt gegen die Daten aus der Active Directory Konfigurationspartition gearbeitet wird, sondern gegen ein Replikat in der lokalen Registry des jeweiligen Systems.

Diese ist jedoch nicht automatisch aktiviert. Lasst uns also nachsehen:

certutil -v -getreg -GroupPolicy enroll\AEPolicy

Und hier stellen wir fest, dass die Synchronisierung offenbar deaktiviert wurde:

Tritt natürlich genau so auf, wenn gar nichts konfiguriert ist.

Damit die Replikation stattfindet, muss mindestens das Flag „AUTO_ENROLLMENT_ENABLE_TEMPLATE_CHECK“ aktiviert sein. In der entsprechenden Gruppenrichtlinie bekannt als „Update certificates that use certificate templates“.

Anschließend wenden wir die Gruppenrichtlinie an und starten den Synchronisierungsprozess mit folgenden Befehlen.

For the computer context:

certutil -pulse

For the user context:

certutil -pulse -user

Anschließend führt auch die Prüfung unserer Domänencontroller-Zertifikate zum Erfolg. Eine Anmeldung sollte nun problemlos möglich sein.

Possible causes

Related links: