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)"

Folgendes Szenario angenommen:

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)

Mögliche Ursachen

Kennen Sie TameMyCerts? TameMyCerts ist ein Add-On für die Microsoft Zertifizierungsstelle (Active Directory Certificate Services). Es erweitert die Funktion der Zertifizierungsstelle und ermöglicht die Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikat-Ausstellungen zu realisieren. TameMyCerts ist einzigartig im Microsoft-Ökosystem, hat sich bereits in unzähligen Unternehmen auf der ganzen Welt bewährt und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden. Professionelle Wartung wird ebenfalls angeboten.

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 {Dateiname}.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 schlägt fehl mit Fehlermeldung "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

Siehe auch Artikel "Fehlersuche für die automatische Zertifikatbeantragung (Autoenrollment) via RPC/DCOM (MS-WCCE)".

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.

Für den Computerkontext:

certutil -pulse

Für den Benutzerkontext:

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.

Mögliche Ursachen

Weiterführende Links: