Comment résoudre l'erreur GPG : « Les signatures suivantes n'ont pas pu être vérifiées » sous Ubuntu

Commencez par identifier le dépôt à l'origine de l'avertissement, puis corrigez sa clé ou sa configuration. Ne désactivez pas la vérification des signatures APT. Le message « Les signatures suivantes n'ont pas pu être vérifiées » signifie qu'APT ne peut pas confirmer que les métadonnées du dépôt ont été signées par une clé de confiance. Tant que la signature n'est pas vérifiée, APT peut refuser d'utiliser cette source. Ajouter une clé aléatoire ou définir une source comme fiable peut masquer l'avertissement, mais supprime la protection qu'il est censé offrir.

Par exemple, supposons que sudo apt updatedes erreurs surviennent NO_PUBKEYdans le dépôt d'un fournisseur de navigateur, alors que les lignes d'archive d'Ubuntu se mettent à jour correctement. La solution la plus probable consiste à installer la clé de signature actuellement publiée par ce fournisseur et à l'appliquer à ce dépôt. Réinstaller le trousseau de clés d'archive d'Ubuntu ne résoudrait pas un problème de clé tierce. Les commandes ci-dessous sont des modèles : remplacez les détails du dépôt d'exemple par les valeurs fournies dans les instructions officielles de l'éditeur du logiciel.

Lisez l'erreur exacte avant de changer les touches.

Exécutez la commande de mise à jour et notez l'URL du dépôt et le code d'erreur sur les mêmes lignes de sortie :

sudo apt update

APT identifie généralement une source par son URL et sa suite de distribution, par exemple `/ nobleetc/apt/lib jammy...

Vérifiez d'abord l'horloge système lorsque l'erreur mentionne l'heure.

Les signatures et les métadonnées du dépôt ont une durée de validité. Un serveur restauré à partir d'un ancien instantané, un ordinateur à double démarrage ou une machine dont le service de temps est défaillant peuvent avoir une horloge suffisamment déréglée pour que les métadonnées actuelles apparaissent comme invalides. Vérifiez l'heure système :

timedatectl status

Vérifiez que la date et l'heure affichées sont exactes et que la synchronisation horaire est activée. Si l'horloge est incorrecte, corrigez le service de temps de l'hôte ou activez la méthode de synchronisation horaire réseau configurée, puis réessayez sudo apt update. Évitez de définir manuellement une date approximative : l'horloge doit afficher l'heure réelle. Une correction horaire ne résoudra pas le problème d'une clé de référentiel manquante ou expirée. Si le message d'erreur persiste NO_PUBKEY, EXPKEYSIGsuivez les étapes relatives à la clé.

Corriger une clé de dépôt tierce manquante ou expirée

Les recommandations actuelles d'Ubuntu préconisent de stocker les clés tierces dans un trousseau dédié et de référencer cette clé depuis la source correspondante Signed-By. Cela limite la clé autorisée à authentifier ce dépôt. Ubuntu décrit cette approche dans son guide des dépôts tiers et APT documente Signed-Byla vérification des étendues dans le manuel sources.list .

1. Trouvez la source qui a généré l'erreur.

Lister les entrées du dépôt et rechercher l'hôte indiqué dans la sortie APT :

grep -RniE '^[[:space:]]*(deb|URIs:)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Ubuntu 24.04 et versions ultérieures utilisent généralement des fichiers deb822 se terminant par `.deb822`.sources ; les versions plus anciennes utilisent généralement des fichiers d'une seule ligne se terminant par `.deb822` .list. La documentation de gestion des paquets Ubuntu décrit ces formats de code source. Ne modifiez pas l'entrée de l'archive Ubuntu pour réparer un dépôt d'un fournisseur non lié.

2. Obtenez et vérifiez la clé actuelle de l'éditeur

Ouvrez la page de configuration du dépôt officiel de l'éditeur du logiciel et vérifiez qu'elle indique l'URL du dépôt, la version d'Ubuntu prise en charge, l'emplacement de téléchargement de la clé de signature et l'empreinte complète de la clé. Téléchargez la clé uniquement depuis une source identifiée par l'éditeur. Comparez l'empreinte complète, et non seulement l'identifiant hexadécimal court affiché après la clé NO_PUBKEY. Le manuel de sécurité d'APT insiste sur l'importance d'obtenir les clés via un canal de confiance ; utiliser une clé erronée compromettrait la vérification du dépôt.

L'exemple suivant utilise une clé blindée ASCII. Remplacez l'URL et le nom de fichier de l'exemple par les valeurs officielles de l'éditeur :

curl -fsSLo /tmp/vendor-archive.asc https://packages.vendor.example/ubuntu/archive-key.asc
gpg --show-keys --with-fingerprint /tmp/vendor-archive.asc

Procédez uniquement si l'empreinte digitale affichée correspond à celle documentée par l'éditeur. Convertissez-la en un trousseau binaire et placez-le dans le répertoire local des trousseaux d'APT :

sudo install -d -m 0755 /etc/apt/keyrings
gpg --dearmor --output /tmp/vendor-archive.gpg /tmp/vendor-archive.asc
sudo install -m 0644 /tmp/vendor-archive.gpg /etc/apt/keyrings/vendor-archive-keyring.gpg

Le domaine d'exemple est fourni à titre indicatif et ne permettra pas de télécharger une véritable clé fournisseur. Utilisez l'URL exacte de la clé vérifiée fournie par l'éditeur du logiciel. Ne vous fiez pas aux résultats de recherche d'un serveur de clés pour confirmer la propriété de la clé.

3. Délimiter la clé dans la source du dépôt

Pour une entrée sur une seule ligne .list, le modèle est le suivant :

deb [signed-by=/etc/apt/keyrings/vendor-archive-keyring.gpg] https://packages.vendor.example/ubuntu noble main

Pour un fichier deb822 .sources, les champs correspondants ressemblent à ceci :

Types: deb
URIs: https://packages.vendor.example/ubuntu
Suites: noble
Components: main
Signed-By: /etc/apt/keyrings/vendor-archive-keyring.gpg

Il s'agit de modèles, et non d'entrées sources universellement valides. Conservez l'URI, la suite et les composants indiqués dans les instructions d'installation officielles du fournisseur ; un nom de code Ubuntu incorrect peut engendrer des conflits de paquets, même si la clé est valide. Assurez-vous que le chemin du trousseau de clés corresponde au fichier installé. Le trousseau de clés doit être accessible en lecture par _aptl'utilisateur non privilégié d'APT ; c'est pourquoi l'exemple l'installe en mode `sudo` 0644. Supprimez ou corrigez les entrées dupliquées pour un même dépôt afin qu'une ancienne entrée non définie ne génère plus d'avertissement.

La commande APT apt-keyest obsolète pour la configuration courante des dépôts. Évitez les guides qui ajoutent des clés tierces globalement apt-key advou qui placent toutes les clés de fournisseurs dans un trousseau de clés de confiance commun. Une Signed-Byentrée limitée à un seul dépôt clarifie la relation de confiance et limite l'impact de la confiance accordée à une seule clé de dépôt.

Si l'avertissement concerne les archives d'Ubuntu

Vérifiez d'abord que la suite de dépôts correspond à votre version d'Ubuntu installée et que l'horloge système est correcte. Les clés de signature des archives Ubuntu sont fournies par le ubuntu-keyringpaquet. Si le trousseau de clés installé est endommagé ou obsolète, et qu'APT peut toujours télécharger et vérifier les paquets à partir d'une source Ubuntu valide et configurée, réinstallez-le avec :

sudo apt install --reinstall ubuntu-keyring

Relancez ensuite la sudo apt updatecommande. Si la seule source défaillante est une archive de version obsolète ou un miroir diffusant des métadonnées incohérentes, la réinstallation du trousseau de clés risque de ne pas résoudre le problème. Consultez la documentation Ubuntu concernant la prise en charge des versions et la configuration des dépôts avant de modifier les clés. Ne remplacez pas la clé d'archive Ubuntu par une clé téléchargée depuis un site non officiel et ne désactivez pas la vérification pour forcer une mise à jour.

Effacer les index mis en cache uniquement en cas d'incohérence de métadonnées

Si APT signale une erreur BADSIGsuite à une interruption réseau temporaire ou à un problème de miroir/proxy, les listes de paquets mises en cache localement peuvent être incomplètes ou incohérentes. Après avoir vérifié que la source configurée est légitime, effacez uniquement les fichiers d'index APT mis en cache et récupérez-les à nouveau :

sudo rm -rf /var/lib/apt/lists/*
sudo apt update

Cette opération supprime les index des dépôts téléchargés, et non les paquets installés. APT reconstruit les index lors de la prochaine mise à jour. Si BADSIGle problème persiste, arrêtez le nettoyage : vérifiez si un proxy réseau, une passerelle de cache ou un miroir réécrit ou diffuse des métadonnées incorrectes, et vérifiez l’état du dépôt auprès de son éditeur. La suppression répétée des index ne corrige pas une signature publiée incorrectement par le dépôt lui-même.

Confirmez la réparation et maintenez la protection activée

Relancez la commande sudo apt updateet vérifiez que le dépôt concerné s'exécute sans avertissements de vérification de signature. Ensuite, vérifiez un paquet de cette source avec la commande NO_PUBKEY` EXPKEYSIGgit check` , en remplaçant `<nom_du_paquet>` par le nom du paquet. Assurez-vous que sa version candidate provient bien du dépôt attendu avant de l'installer ou de la mettre à jour.BADSIGapt-cache policy package-name

N'utilisez pas les options trusted=yes`--no -signature`, allow-insecure=yes`--no- --allow-unauthenticatedsignature`, `--no-signature` ou similaires comme solution permanente. La vérification de signature d'APT garantit que les métadonnées du dépôt sont signées par une clé que vous avez choisie et approuvée ; la désactiver empêche APT d'effectuer cette vérification d'intégrité. Le manuel de sécurité d'APT explique la chaîne d'authentification des archives et ses limites. Si l'éditeur a retiré un dépôt, cessé de signer les métadonnées ou ne fournit pas d'empreinte de clé vérifiable, supprimez ou désactivez cette source plutôt que de contourner la vérification.

Documentation vérifiée le 6 octobre 2026. Les formats des dépôts Ubuntu et les recommandations de gestion des clés peuvent varier selon la version ; veuillez utiliser la documentation de votre version d’Ubuntu installée et les instructions actuelles de l’éditeur du dépôt.