L'inscription par carte à puce échoue avec un message d'erreur „A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)“

Supposons le scénario suivant :

L'entreprise souhaite utiliser la connexion par carte à puce.
Les contrôleurs de domaine sont avec des certificats utilisables pour l'inscription par carte à puce équipée.
Les utilisateurs sont munis de certificats utilisables pour la connexion par carte à puce.
La connexion au domaine par carte à puce échoue avec le message d'erreur suivant :

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

En allemand, le message d'erreur est le suivant :

Die Zertifizierungskette wurde richtig verarbeitet, doch wird eines der Zertifizierungsstellen-Zertifikate vom Richtlinienanbieter nicht für vertrauenswürdig gehalten. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)

Causes possibles

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

Le code d'erreur CERT_E_UNTRUSTEDCA indique - comme l'indique le texte de description correspondant - un statut de confiance manquant.

En général, on vérifie donc les certificats impliqués (contrôleur de domaine et certificat d'utilisateur) en les exportant dans un fichier et en exécutant la commande suivante :

certutil -verify -urlfetch {Dateiname}.cer

Cependant, vous constaterez que cette commande ne laisse apparaître aucune erreur :

Tout est donc apparemment en ordre avec les certificats ?

Non.

Outre le simple état de confiance envers l'autorité de certification émettrice, il existe d'autres états à granularité fine :

Si l'autorité de certification est habilitée à délivrer des certificats avec les utilisations étendues de clés correspondantes (angl. Extended Key Usage, EKU) sont-elles autorisées ? (Politiques d'application, en anglais Application Policies)
L'organisme de certification est-il autorisé à délivrer des certificats avec les directives de certification correspondantes ? (Directives d'émission, en anglais Issuance Policies)
L'organisme de certification est-il autorisé à délivrer des certificats pour une demande PKINIT ? (Adhésion à l'objet NTAuthCertificates)

Alors que les deux premiers critères peuvent encore être reconnus par ladite commande certutil, ce n'est pas le cas de l'appartenance à NTAuthCertificates.

Une manière de les vérifier est d'utiliser la commande suivante :

certutil -dcinfo verify

Veuillez impérativement indiquer le mot-clé „verify“ !

Veuillez également tenir compte de l'article suivant si le code d'erreur „CRYPT_E_NOT_FOUND“ apparaît : certutil -dcinfo échoue avec le message d'erreur "KDC certificates : Cannot find object or property. 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)"

Nous retrouvons ici le message d'erreur précédent :

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

L'affaire est donc claire, n'est-ce pas ? Une de nos autorités de certification n'est pas membre de NTAuthCertificates !

En règle générale, le code d'erreur CERT_E_UNTRUSTEDCA indique en principe toujours un problème d'adhésion d'une autorité de certification impliquée à NTAuthCertificates.

Une vérification permet toutefois de constater que l'autorité de certification est dûment enregistrée ici :

Alors pourquoi le certificat n'est-il pas considéré comme utilisable pour PKINIT ?

Pour cela, il faut savoir que l'on ne travaille pas directement contre les données de la partition de configuration Active Directory, mais contre une réplique dans le registre local du système concerné.

Celle-ci n'est toutefois pas automatiquement activée. Vérifions donc :

certutil -v -getreg -GroupPolicy enroll\AEPolicy

Voir aussi l'article "Dépannage de la demande automatique de certificat (auto-enrollment) via RPC/DCOM (MS-WCCE)„ .

Et c'est là que nous constatons que la synchronisation semble avoir été désactivée :

Cela se produit naturellement de la même manière lorsque rien n'est configuré.

Pour que la réplication ait lieu, il faut au moins que le drapeau „AUTO_ENROLLMENT_ENABLE_TEMPLATE_CHECK“ soit activé. Dans la stratégie de groupe correspondante connu sous le nom de „Update certificates that use certificate templates“.

Ensuite, nous appliquons la stratégie de groupe et démarrons le processus de synchronisation avec les commandes suivantes.

Pour le contexte informatique :

certutil -pulse

Pour le contexte de l'utilisateur :

certutil -pulse -user

Ensuite, la vérification de nos certificats de contrôleur de domaine est également un succès. La connexion devrait maintenant être possible sans problème.

Liens complémentaires :

Sources externes

certutil | Microsoft Learn