Dépannage des chaînes de certificats

Portail > Sujets avancés et opérationnels

Cette page recense les pannes de chaîne les plus fréquentes, leurs causes et la démarche pour les diagnostiquer. Elle synthétise, côté opérationnel, tout ce qui précède.

Démarche générale

1. Voir la chaîne réellement présentée par le service (et pas seulement le fichier sur disque).
2. Identifier le maillon fautif : feuille, intermédiaire manquant, racine non installée.
3. Préciser « de confiance pour qui » : le client en échec (navigateur, Java, Python, mTLS…) a-t-il la bonne racine ? (Ancres de confiance et magasins de confiance)
4. Vérifier dates, ordre, noms, révocation.

# Chaîne présentée par le serveur (la référence)
openssl s_client -connect clipsy.tech:443 -servername clipsy.tech -showcerts </dev/null

# Validation explicite feuille + intermédiaires + racine
openssl verify -CAfile racine.pem -untrusted intermediaires.pem feuille.pem

# Dates et sujet/émetteur d'un certificat
openssl x509 -in cert.pem -noout -subject -issuer -dates

Erreurs courantes

Message	Cause probable	Correctif
unable to get local issuer certificate	Intermédiaire absent de la chaîne servie, ou racine absente du magasin du client	Servir le fullchain (feuille + intermédiaires) ; installer la racine dans le magasin du client (Construction du chemin de certification)
self-signed certificate in certificate chain	Racine interne non présente dans le magasin de confiance du client	Déployer la racine interne (update-ca-certificates, cacerts…)
certificate has expired / certificate is not yet valid	notAfter dépassé ou notBefore futur — sur la feuille ou un intermédiaire/CA	Renouveler ; vérifier aussi les CA internes ; contrôler l'horloge système
Hostname mismatch / certificate name does not match	Le nom demandé n'est pas dans le SAN	Réémettre avec le bon SAN ; corriger le nom d'hôte/SNI
certificate verify failed (générique)	Échec d'un des contrôles de validation	Isoler le maillon avec openssl verify / -showcerts
unable to verify the first certificate	Intermédiaire(s) manquant(s) côté serveur	Ajouter les intermédiaires au fichier servi, dans le bon ordre

Pièges classiques

• Mauvais ordre dans le fichier de chaîne : feuille d'abord, puis intermédiaires, sans la racine (Formats et encodage des certificats).
• Racine incluse à tort dans le fullchain servi : inutile, parfois source d'avertissements.
• AIA non suivie : beaucoup de clients (bibliothèques, mTLS) ne téléchargent pas les intermédiaires manquants → ne pas compter dessus, servir le fullchain.
• Magasin différent selon le runtime : « OK dans le navigateur, KO dans le conteneur/CI/Java/Python » → la racine manque dans ce magasin précis.
• Horloge décalée : un système à l'heure fausse voit des certificats « expirés » ou « pas encore valides ».
• Transition de racine : un chemin via une racine expirée alors qu'un chemin croisé valide existe (Certification croisée et cross-signing).

Spécificités Kubernetes / cert-manager / RKE2

• Secret pas rechargé : cert-manager a renouvelé le Secret, mais le pod/ingress sert encore l'ancien certificat → recharger/redémarrer le consommateur.
• Réplication de secret (External Secrets Operator…) : un secret source mis à jour mais non répliqué, ou une CA interne expirée, provoque des échecs en cascade ; vérifier la fraîcheur du secret et la validité de la CA qui l'a émis.
• PKI interne RKE2/Vault : ces composants ont leurs propres CA et échéances ; une CA interne expirée invalide tout ce qu'elle a signé, indépendamment des certificats applicatifs.
• Chaîne dans le Secret TLS : s'assurer que tls.crt contient bien la feuille et les intermédiaires.

# Inspecter un Secret TLS Kubernetes
kubectl get secret mon-tls -o jsonpath='{.data.tls\.crt}' | base64 -d \
  | openssl crl2pkcs7 -nocrl -certfile /dev/stdin \
  | openssl pkcs7 -print_certs -noout

Points clés à retenir

• Toujours partir de la chaîne réellement présentée (s_client -showcerts), pas du fichier supposé.
• La question centrale : « de confiance pour quel client/magasin ? ».
• Causes n°1 : intermédiaire manquant (servir le fullchain) et racine interne non installée.
• Vérifier dates, ordre, SAN, révocation, et en Kubernetes la fraîcheur des Secrets + validité des CA internes.

Voir aussi

• Validation du chemin de certification
• Construction du chemin de certification
• Ancres de confiance et magasins de confiance
• Certification croisée et cross-signing