Error response from daemon: Get "https://registry.example.com:5000/v2/": tls: failed to verify certificate: x509: certificate signed by unknown authority

L’hôte et le port du registre sont les vôtres ; docker push, pull et login le signalent tous sous la forme « Error response from daemon: Get \"https://<registry>/v2/\": … ». containerd, nerdctl, Podman et les nœuds Kubernetes qui récupèrent des images affichent le même texte x509 avec leurs propres préfixes.

Docker Engine (dockerd) — docker pull / push / login against a registry with an untrusted certificate

Ce que cela signifie

Le démon Docker (et non la CLI docker) a tenté de joindre l’API du registre à /v2/ et n’a pas pu vérifier son certificat TLS : la chaîne ne mène pas à une AC à laquelle le démon fait confiance. dockerd fait confiance au fichier d’AC système de l’hôte ainsi qu’aux AC par registre placées dans /etc/docker/certs.d/<registry>:<port>/. Les registres privés avec des certificats d’entreprise et les proxys d’inspection TLS en sont les causes habituelles.

Pourquoi cela se produit

• Un registre auto-hébergé avec un certificat privé

  fréquente

  Harbor, le registre GitLab, Nexus ou registry:2 derrière un certificat émis par une AC d’entreprise ou faite maison.

• Un proxy d’inspection TLS devant Docker Hub ou d’autres registres

  fréquente

  Le démon voit les certificats du proxy ; sans la racine de celui-ci dans le magasin de l’hôte, chaque récupération d’image échoue.

• L’AC a été installée là où le démon ne regarde pas

  occasionnelle

  Copier l’AC dans le magasin de la machine cliente ne sert à rien lorsque le démon s’exécute ailleurs (VM de Docker Desktop, DOCKER_HOST distant, runner de CI). Le nom du répertoire certs.d doit correspondre exactement à l’hôte et au port du registre.

• Le registre omet son certificat intermédiaire

  occasionnelle

  Go (dockerd) ne récupère pas les certificats intermédiaires : un registre qui n’envoie que le certificat feuille échoue même avec une AC publique.

Comment corriger l’erreur

1. 1.

   Installer l’AC de ce registre dans certs.d

   /etc/docker/certs.d/<host>:<port>/ca.crt est lu à chaque requête ; lors de la reproduction, docker login a réussi juste après son ajout.

   # Trust the registry's CA for this registry only (no daemon restart needed)
   sudo mkdir -p /etc/docker/certs.d/registry.example.com:5000
   sudo cp corp-root-ca.pem /etc/docker/certs.d/registry.example.com:5000/ca.crt
   docker login registry.example.com:5000

2. 2.

   Installer l’AC pour tout le système et redémarrer dockerd

   Pour les proxys, et lorsque les registres sont nombreux, ajoutez la racine au fichier d’AC de l’hôte ; le démon le lit au démarrage.

   # Or system-wide (proxy roots, many registries), then restart the daemon
   sudo cp corp-root-ca.pem /usr/local/share/ca-certificates/corp-root-ca.crt
   sudo update-ca-certificates
   sudo systemctl restart docker

3. 3.

   Docker Desktop : faire confiance à la racine sur l’hôte

   La VM de Docker Desktop reprend les racines de confiance du système d’exploitation hôte à son démarrage : installez donc la racine sur l’hôte et redémarrez Docker Desktop.

   Docker Desktop: the daemon runs in a VM. Add the root to the host's trust store
   (macOS Keychain "System" with "Always Trust", Windows "Trusted Root Certification Authorities")
   and restart Docker Desktop; it imports trusted host roots into the VM.

4. 4.

   Vérifier la chaîne du registre

   Si seul le certificat feuille est envoyé, configurez le registre ou son proxy inverse avec la chaîne complète.

   openssl s_client -connect registry.example.com:5000 -servername registry.example.com -showcerts </dev/null 2>/dev/null \
     | grep -E '^ *[0-9]+ s:|^ *i:'

← Parcourir toute la base de données des erreurs de signature