Erreur 0x800b0109 pendant une mise à jour : les solutions

L’erreur 0x800b0109 n’est pas une panne de Windows Update : c’est un refus de signature. Le code se traduit par CERT_E_UNTRUSTEDROOT, autrement dit une chaîne de certificats qui a bien été traitée mais qui aboutit à un certificat racine que le système ne considère pas comme fiable.

Points clés

• Microsoft traduit 0x800b0109 par CERT_E_UNTRUSTEDROOT : « a certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider ».
• Le blocage vient donc du magasin des autorités de certification racines de confiance, pas du fichier téléchargé lui-même dans la plupart des cas.
• Trois causes couvrent l’essentiel des situations : horloge système fausse, racine absente du magasin, inspection TLS ou stratégie d’entreprise qui filtre les racines.
• Le code apparaît aussi hors de Windows Update : installation de pilote, programme d’installation signé, connexion DirectAccess en IP-HTTPS.
• Désactiver la vérification de signature n’est pas une solution : cela revient à accepter un paquet dont l’origine n’est pas prouvée.

Ce que Windows vérifie exactement

Chaque mise à jour, chaque pilote et chaque programme d’installation signé porte un certificat. Ce certificat renvoie à une autorité émettrice, qui renvoie elle-même vers une autorité racine. Windows n’accorde sa confiance qu’aux racines présentes dans le magasin « Autorités de certification racines de confiance », que Microsoft documente comme le magasin de référence pour la validation des signatures de code en mode noyau.

Si un maillon de cette chaîne manque, expire ou ne correspond pas, le fournisseur de confiance rend un verdict d’échec. 0x800b0109 est précisément ce verdict, dans son cas le plus fréquent : la chaîne est complète et lisible, mais sa racine n’est pas dans le magasin.

Cause 1 : la date et l’heure du poste

Un certificat possède une date de début et une date de fin de validité. Si l’horloge du poste est décalée de plusieurs mois, ou si la pile de la carte mère est morte et que la machine redémarre en 2010, aucune chaîne ne peut être validée. C’est la première chose à contrôler, avant toute manipulation de certificats.

Vérifiez la date, l’heure et le fuseau, puis forcez une synchronisation. Microsoft documente les outils du service de temps Windows, dont w32tm, pour diagnostiquer et relancer la synchronisation. Le même mécanisme est derrière un code voisin détaillé dans notre article sur l’erreur 0x80072f8f, problème de date, d’heure ou de certificat.

Cause 2 : le magasin de racines est incomplet

Les certificats racines évoluent. Sur un poste resté longtemps hors ligne, réinstallé depuis une image ancienne, ou dont les mises à jour sont bloquées depuis des mois, le magasin peut ne plus contenir la racine qui signe le paquet présenté. Le symptôme est typique : l’erreur touche toutes les mises à jour, ou tous les installateurs d’un même éditeur.

Deux gestes utiles dans ce cas :

• Installer toutes les mises à jour déjà disponibles, redémarrer, puis réessayer l’opération qui échouait.
• Ouvrir le gestionnaire de certificats de l’ordinateur local et vérifier la présence de la racine attendue dans « Autorités de certification racines de confiance ». Microsoft documente certutil pour inspecter et manipuler les magasins en ligne de commande.

Si la racine manque, récupérez-la auprès de l’éditeur du logiciel ou de l’autorité de certification elle-même, jamais sur un site de partage de fichiers. Importer une racine inconnue donne à son propriétaire la capacité de faire passer n’importe quel code pour légitime.

Cause 3 : proxy, antivirus et inspection TLS

En entreprise, les passerelles qui inspectent le trafic chiffré remplacent le certificat du serveur par un certificat qu’elles signent avec leur propre autorité. Si cette autorité n’est pas déployée sur le poste, ou si la connexion sort par un chemin non prévu, la validation échoue avec ce même code. Certains antivirus grand public font la même chose localement pour analyser le trafic HTTPS.

Test rapide : refaire l’opération sur une connexion non filtrée, par exemple un partage de connexion mobile. Si l’erreur disparaît, le sujet est côté réseau, et la correction consiste à déployer correctement la racine de l’équipement d’inspection, ou à exclure les domaines de mise à jour de Microsoft de cette inspection.

Le cas est officiellement documenté sur un terrain proche : Microsoft explique qu’un client DirectAccess échoue à se connecter en IP-HTTPS avec l’erreur 0x800b0109 lorsque l’autorité qui a émis le certificat du serveur n’est pas présente dans les magasins racine et intermédiaire du client, et recommande d’importer ce certificat dans le magasin de l’ordinateur, par stratégie de groupe pour un parc entier.

Vérifier la chaîne pas à pas

Suivez ces étapes dans l’ordre sur le poste concerné, elles couvrent les causes potentielles les plus fréquentes avant tout dépannage plus lourd :

• Cliquez sur l’horloge de la barre des tâches, contrôlez la date et le fuseau, puis corrigez si nécessaire.
• Ouvrez les paramètres de Windows Update, essayez une nouvelle analyse, notez si l’erreur change de code.
• Tapez certlm.msc dans la fenêtre Exécuter, sélectionnez le magasin des racines de confiance, cherchez l’autorité approuvée attendue.
• Cliquez avec le bouton droit sur le fichier d’installation, ouvrez ses propriétés, puis l’onglet Signatures numériques.
• Redémarrez le poste avant de conclure, plusieurs éléments de sécurité ne se rechargent qu’au démarrage.

Cause 4 : les composants de mise à jour sont abîmés

Un cache de mises à jour corrompu peut présenter un paquet tronqué dont la signature ne se vérifie plus. Dans ce cas l’erreur est locale à Windows Update et n’affecte pas les autres installations. Microsoft documente une procédure de réparation des altérations et des échecs d’installation de Windows Update, appuyée sur DISM.

La séquence utile, invite de commandes en administrateur :

• sfc /scannow, détaillé dans notre article sur ce que répare vraiment sfc /scannow ;
• DISM /Online /Cleanup-Image /RestoreHealth, expliqué dans notre article sur DISM RestoreHealth ;
• remise à zéro du cache des mises à jour, procédure complète dans réinitialiser les composants Windows Update.

Un code d’échec voisin, qui se règle avec une partie des mêmes gestes, est traité dans notre article sur l’erreur 0x80070490.

Le dossier catroot2, cas particulier utile

Windows conserve les catalogues de signatures des paquets dans C:\Windows\System32\catroot2. Microsoft indique qu’une altération de ce dossier perturbe le processus CryptCATAdminAddCatalog, celui qui enregistre les catalogues de signature, et provoque des échecs de mise à jour même sans corruption du magasin de composants.

La procédure de remise à zéro suit toujours le même ordre. Ouvrez une invite de commandes en administrateur : appuyez sur les touches Windows et R, tapez cmd, puis validez avec Ctrl, Maj et Entrée. Arrêtez le service des services de chiffrement avec net stop cryptsvc, renommez le dossier, redémarrez le service, puis relancez la recherche de mises à jour. Si la commande échoue avec un accès refusé, redémarrez la machine et recommencez avant d’insister : le service tient encore les fichiers ouverts.

Cause 5 : le paquet lui-même

Reste le cas où le fichier est réellement en cause : téléchargement incomplet, installateur repackagé par un tiers, pilote ancien signé par une autorité qui n’est plus reconnue. Le réflexe est de retélécharger depuis la source officielle de l’éditeur, puis de comparer la signature affichée dans les propriétés du fichier, onglet Signatures numériques.

Sur un pilote non signé ou signé par une racine morte, la règle ne change pas : on cherche une version plus récente chez le fabricant. Contourner la vérification en désactivant l’application des signatures de pilotes affaiblit durablement la machine pour installer un composant obsolète.

Quand le problème résiste sur un seul paquet, une étape simple permet de trancher : télécharger la mise à jour depuis le Catalogue Microsoft Update, avec son numéro KB, puis lancer l’installation à la main. Si le fichier téléchargé s’installe sans erreur, le blocage venait des composants locaux de Windows Update et non de la confiance accordée à l’éditeur.

En entreprise, la même logique s’applique côté serveur. Un poste qui pointe vers un serveur WSUS reçoit ses paquets d’une source interne, et un certificat de signature mal déployé sur ce serveur reproduit le problème sur l’ensemble du parc. Testez alors un poste au démarrage sur les serveurs publics de Microsoft pour isoler la cause, puis corrigez le déploiement de l’autorité approuvée.

Ce qu’il ne faut pas faire

• Importer une racine trouvée sur un forum ou dans une archive. C’est la porte ouverte à la signature de n’importe quel code.
• Désinstaller « les certificats » en masse pour repartir de zéro. Un magasin racine vidé casse bien plus que les mises à jour.
• Reculer la date du système pour faire accepter un certificat expiré. L’effet de bord touche l’ensemble du chiffrement de la machine.
• Désactiver définitivement la vérification des signatures de pilotes.

FAQ

Que signifie littéralement 0x800b0109 ?

Le code correspond à CERT_E_UNTRUSTEDROOT. La chaîne de certificats a été traitée jusqu’au bout, mais elle se termine par une racine que le fournisseur de confiance du système ne reconnaît pas.

L’erreur touche aussi les pilotes et les installateurs, est-ce le même problème ?

Oui, le mécanisme est identique. Windows valide la signature de tout code qu’il installe, et le même verdict de confiance remonte sous le même code, que la demande vienne de Windows Update, d’un package MSI ou d’une connexion d’accès distant.

Faut-il être administrateur pour corriger ce blocage ?

Pour importer un certificat dans le magasin de l’ordinateur local, réparer l’image avec DISM ou resynchroniser l’heure, oui. Sur un poste géré par une entreprise, ces actions passent en général par le service informatique et une stratégie de groupe.

Comment savoir quelle racine manque ?

Ouvrez les propriétés du fichier concerné, onglet Signatures numériques, puis remontez le chemin d’accès de certification dans les détails. Le maillon signalé comme non fiable indique l’autorité à obtenir auprès de l’éditeur.

_{Photo d’en-tête : écran de mise à jour de Windows 10 version 22H2, capture par CSR2Forever, domaine public via Wikimedia Commons. La capture illustre le contexte où l’erreur apparaît le plus souvent, pas le message lui-même.
Sources : Microsoft Learn, erreur 0x800b0109 et CERT_E_UNTRUSTEDROOT · Microsoft Learn, magasin des autorités de certification racines de confiance · Microsoft Learn, corriger les altérations et les échecs d’installation de Windows Update · Microsoft Learn, certutil · Microsoft Learn, outils et paramètres du service de temps Windows · Microsoft Learn, réparer une image Windows · Microsoft Learn, altération du dossier catroot2}