Diagnostiquer les erreurs de validation TLS en production

Une erreur Transport Layer Security (TLS) de validation n’est presque jamais mystérieuse : elle est seulement mal observée. La bonne méthode consiste à inspecter ce que le serveur présente réellement, puis à séparer les défauts de configuration serveur des défauts de confiance ou de temps côté client.

→ Lire l’explication complète de la marmotte

Validation TLS : le compromis entre disponibilité et identité vérifiée

La validation TLS apporte une garantie précise : le client accepte de parler à un serveur dont l’identité cryptographique correspond au nom demandé, dont le certificat est encore valide et dont la chaîne remonte vers une autorité de certification de confiance. Le prix est connu : un défaut de certificat devient une indisponibilité immédiate. C’est voulu. Désactiver la vérification pour restaurer le service transforme une panne visible en interception silencieuse.

La règle est donc tranchée : ne jamais contourner la validation en production avec verify=false, -k, InsecureSkipVerify ou leur cousin honteux caché dans une variable d’environnement. Ces options servent au diagnostic ponctuel, pas à l’exploitation. Une application qui accepte n’importe quel certificat ne fait pas du TLS, elle fait du transport chiffré vers une destination possiblement inconnue. Le cadenas reste affiché, la confiance est partie chercher du pain.

Les vérifications pertinentes sont les suivantes :

le nom demandé doit apparaître dans l’extension Subject Alternative Name (SAN) du certificat ;
la date courante doit être comprise entre Not Before et Not After ;
le serveur doit présenter les certificats intermédiaires nécessaires ;
le client doit posséder une autorité racine de confiance permettant de construire la chaîne ;
selon la politique du client, le statut de révocation doit être contrôlable.

Le protocole ne garantit pas la légitimité métier du service, l’intégrité du code exécuté derrière le point d’entrée, ni la sécurité d’une session déjà ouverte. La révocation d’un certificat ne coupe pas les sessions TLS établies. Elle ne protège pas non plus un client qui ignore les mécanismes de révocation, ce qui arrive davantage que les slides de vendeurs ne le laissent entendre.

Pour les mécanismes de négociation, de chiffrement et les limites structurelles du protocole, consulter le fonctionnement de TLS. Cette page traite du dépannage : constater, isoler, corriger.

Chaîne de certificats incomplète côté serveur

Un certificat de serveur est généralement signé par une autorité intermédiaire, elle-même rattachée à une autorité racine. Le serveur doit présenter son propre certificat et les intermédiaires nécessaires. Il ne doit habituellement pas envoyer la racine : celle-ci appartient déjà au magasin de confiance du client et son envoi ne résout rien.

Le défaut classique consiste à configurer uniquement le certificat de feuille, parfois appelé certificat serveur, au lieu du fichier regroupant certificat serveur et intermédiaires. Certains navigateurs semblent alors fonctionner parce qu’ils ont récupéré l’intermédiaire lors d’une connexion antérieure ou parce que le système l’a en cache. Un poste neuf, un conteneur minimal ou une bibliothèque applicative stricte échoue. Ce comportement variable est un signal, pas une excuse pour laisser le défaut en place.

Le serveur ne doit pas compter sur le téléchargement d’un intermédiaire via l’extension Authority Information Access. Cette récupération dépend du client, de son réseau et de sa politique. Elle échoue souvent dans les environnements filtrés, hors ligne ou durcis. Une chaîne présentée complète est la seule configuration défendable.

L’ordre compte : certificat de feuille d’abord, puis intermédiaire directement émetteur, puis éventuels intermédiaires supérieurs. Un certificat non lié cryptographiquement au maillon suivant produit une chaîne décorative, équivalent cryptographique d’un organigramme dessiné au feutre.

Pour distinguer certificat, clé privée, autorité racine et intermédiaire, voir les principes d’une PKI. La clé privée du serveur ne doit jamais être concaténée au fichier de chaîne ni distribuée aux clients. Cette erreur existe encore, ce qui prouve que certains dépôts Git ont une vie intérieure.

Nom demandé et SAN : l’erreur de correspondance la plus banale

Le champ Common Name, ou nom commun historique du sujet, ne suffit plus comme source de vérité pour les clients conformes. La correspondance de nom repose sur l’extension SAN. Un certificat destiné à api.exemple.fr doit contenir DNS:api.exemple.fr. Un certificat contenant seulement DNS:exemple.fr est invalide pour le sous-domaine.

Le nom vérifié est celui effectivement demandé par le client, pas celui affiché dans un fichier de configuration, un inventaire ou un portail d’administration. Les erreurs apparaissent fréquemment derrière un répartiteur de charge, un proxy inverse ou une passerelle d’API : le client contacte service.exemple.fr, mais le frontal présente le certificat de origine.interne.exemple.fr.

L’indication Server Name Indication (SNI) transmet le nom visé pendant l’ouverture de la connexion TLS afin que le serveur choisisse le bon certificat. Sans SNI, un frontal mutualisé présente souvent son certificat par défaut. Le diagnostic doit donc toujours envoyer le nom réellement utilisé. Tester une adresse IP sans SNI pour diagnostiquer un nom de domaine revient à vérifier une serrure avec la clé du local voisin.

Les caractères génériques ne couvrent qu’un niveau de sous-domaine. *.exemple.fr couvre api.exemple.fr, mais pas v2.api.exemple.fr, ni le domaine nu exemple.fr. Les adresses IP exigent une entrée SAN de type IP, pas une entrée DNS contenant une représentation textuelle de l’adresse.

Horloge système : quand un certificat valide devient invalide

Un certificat possède une période de validité. Si l’horloge locale du client est antérieure à Not Before, le certificat paraît prématuré. Si elle est postérieure à Not After, il paraît expiré. Le serveur peut être correctement configuré et le certificat parfaitement valable dans le temps réel : le client le rejettera tout de même.

Les postes utilisateurs ne sont pas les seuls concernés. Les conteneurs héritent généralement de l’horloge de l’hôte, les machines virtuelles dépendent de leur mécanisme de synchronisation, et les équipements réseau ont parfois une notion du temps aussi stable qu’un réveil de cuisine. Une dérive de quelques minutes suffit à casser un certificat émis récemment ou un mécanisme de révocation avec fenêtre temporelle courte.

Synchroniser les systèmes avec une source de temps de confiance, surveiller la dérive et alerter avant que l’écart ne dépasse la tolérance applicative. Network Time Protocol (NTP) doit être accessible ou relayé dans les zones isolées. Un redémarrage de machine virtuelle, une restauration de sauvegarde ou une perte de synchronisation peuvent faire reculer l’horloge : ces événements doivent être couverts par la supervision.

Ne pas confondre une erreur temporelle avec un renouvellement raté. Le premier incident dépend de l’horloge du validateur ; le second dépend de la date réelle du certificat et de la chaîne de renouvellement. Les deux produisent volontiers le même ticket d’astreinte, avec une priorité déclarée « critique absolue » à 08 h 57.

Inspection reproductible avec OpenSSL

OpenSSL permet d’observer la chaîne envoyée par le serveur, sans dépendre du cache d’un navigateur. La commande suivante doit être exécutée depuis le réseau et l’environnement qui rencontrent l’échec. Le paramètre -servername est obligatoire pour un service mutualisé utilisant SNI.

# Inspecter le certificat et les intermédiaires réellement présentés.
# Remplacer api.exemple.fr par le nom exact appelé par le client.
openssl s_client \
  -connect api.exemple.fr:443 \
  -servername api.exemple.fr \
  -showcerts \
  -verify_return_error \
  -verify_hostname api.exemple.fr \
  </dev/null

# Extraire et lire les dates, l'émetteur et les SAN d'un certificat local.
openssl x509 -in serveur.pem -noout \
  -subject -issuer -dates -ext subjectAltName

# Vérifier une chaîne locale contre un magasin de racines contrôlé.
openssl verify \
  -CAfile racines.pem \
  -untrusted intermediaires.pem \
  serveur.pem

La sortie de s_client doit être lue dans cet ordre :

vérifier le nom dans Verify return code et rechercher une erreur de type hostname mismatch ;
vérifier les dates NotBefore et NotAfter du certificat présenté ;
compter les certificats envoyés et identifier leurs émetteurs ;
relever le code final de vérification ;
comparer le certificat observé avec celui configuré sur le frontal réellement atteint.

Une erreur unable to get local issuer certificate peut désigner deux causes distinctes. Si le serveur n’envoie pas l’intermédiaire, le défaut est serveur. Si la chaîne est complète mais que le client ne reconnaît pas la racine, le défaut est côté client : magasin de confiance obsolète, racine privée absente, image de conteneur non mise à jour ou politique de confiance restrictive.

Ne pas utiliser openssl s_client comme verdict exclusif sur la révocation. Son comportement dépend des options et de l’environnement. Pour une authentification mutuelle, les mêmes principes s’appliquent aux certificats clients, avec une difficulté supplémentaire : le serveur décide aussi quelles autorités il accepte. La page sur mTLS détaille cette seconde validation.

Surface d’attaque et limites du dépannage TLS

Un certificat valide pour le bon nom ne prouve pas que le service est sain. Un attaquant ayant compromis le serveur, la clé privée ou le mécanisme de déploiement peut présenter un certificat parfaitement acceptable. TLS protège le transport et authentifie une identité de certificat, pas l’absence de compromission derrière cette identité.

La chaîne de confiance est aussi une surface d’attaque. Une autorité de certification compromise, une racine ajoutée abusivement au magasin de confiance, un proxy d’inspection TLS installé comme autorité locale ou une résolution DNS détournée peuvent modifier l’identité observée. Le diagnostic doit donc inclure la provenance du magasin de confiance et la liste des autorités ajoutées par la politique système.

La clé privée doit être protégée par des permissions restrictives, idéalement dans un module matériel ou un service de gestion de clés quand l’architecture le justifie. Son renouvellement doit être découplé du certificat : remplacer un certificat sans rotation de clé conserve le risque lié à une clé potentiellement exfiltrée. Inversement, une rotation de clé sans déploiement atomique peut provoquer un décalage entre frontal, sauvegarde et nœud de secours.

Les journaux doivent contenir le nom demandé, l’autorité émettrice, l’empreinte du certificat présenté et le code d’erreur de validation, sans jamais enregistrer de clé privée ni de secret de session. Conserver les anciens certificats et chaînes facilite le retour arrière, mais la sauvegarde de la clé privée doit suivre un contrôle d’accès distinct. Une sauvegarde accessible à tous est une copie de production avec moins de surveillance.

Checklist de déploiement TLS avant production

Avant chaque bascule de certificat ou de frontal, vérifier :

le nom de domaine exact utilisé par chaque client, y compris les alias, domaines internes et accès par adresse IP ;
la présence de chaque nom dans les SAN du certificat ;
l’envoi du certificat de feuille et de tous les intermédiaires, dans le bon ordre ;
l’absence de racine dans la chaîne envoyée ;
la validation depuis une image de conteneur neuve et depuis un poste sans cache d’intermédiaires ;
le comportement avec SNI et le certificat par défaut du frontal ;
la confiance de la racine par tous les magasins clients ciblés ;
la synchronisation horaire du serveur, des clients critiques et des équipements intermédiaires ;
les permissions de la clé privée, son emplacement, sa rotation et sa restauration ;
la supervision de la date d’expiration, avec alerte assez tôt pour corriger la chaîne entière ;
le test de reprise après restauration et de bascule vers le nœud de secours ;
l’absence de désactivation de validation dans les paramètres applicatifs.

La vérification finale doit partir d’un environnement externe au serveur cible. Tester localement un fichier PEM valide prouve que le fichier PEM est lisible. Cela ne prouve ni que le bon frontal le sert, ni que le proxy a rechargé sa configuration, ni que le réseau atteint ce frontal. La production adore ces différences minuscules, surtout à 02 h 13.

🐝 Ce qui arrive si on s’en passe

Sans méthode de diagnostic reproductible, une erreur de validation reste une alerte indistincte : une chaîne incomplète, une horloge décalée et une tentative d’interception produisent des codes d’erreur voisins. Quand ces échecs sont traités comme du bruit de configuration, un certificat présenté par un attaquant placé sur le chemin réseau (DNS détourné, proxy intercalé) passe inaperçu parmi les incidents ordinaires, et sans empreinte journalisée, aucune enquête ne peut ensuite établir quel certificat a réellement été servi. Si le contournement est choisi pour rétablir le service, les en-têtes d’authentification, jetons porteurs et identifiants transmis par le client partent vers quiconque répond sur ce nom ; ils restent réutilisables après l’incident. L’option de contournement, une fois ajoutée dans une image ou une variable partagée, se propage aux déploiements suivants sans nouvelle panne visible pour la signaler.

🦫 Explication de la marmotte 🍫

Quand une application ouvre une connexion protégée vers un site, elle demande un nom précis, par exemple api.exemple.fr. Le serveur répond avec un certificat. Ce document contient son identité, les noms pour lesquels il est valable, ses dates de début et de fin, ainsi qu’une signature faite par une autorité reconnue.

L’application vérifie d’abord que le nom demandé figure dans le certificat. Si le serveur donne un certificat prévu pour un autre nom, la connexion doit être refusée. Elle vérifie ensuite les dates avec sa propre horloge. Une horloge en retard peut faire croire que le certificat n’est pas encore valable ; une horloge en avance peut le faire paraître expiré.

Enfin, l’application vérifie qui a signé le certificat. Le serveur doit fournir les documents intermédiaires permettant de relier son certificat à une autorité déjà connue du système. Si un document intermédiaire manque, certains appareils peuvent réussir grâce à une copie conservée auparavant, tandis que d’autres échouent immédiatement.

Pour trouver la cause, il faut observer ce que le serveur envoie réellement depuis le réseau concerné, vérifier le nom, les dates et tous les documents de signature. Si le serveur envoie une chaîne incomplète ou le mauvais certificat, la correction est côté serveur. Si la chaîne est correcte mais que le client refuse encore, il faut examiner son horloge et sa liste d’autorités de confiance.

Pages voisines

La citent

Diagnostiquer les erreurs de validation TLS en production

Elle cite

Diagnostiquer les erreurs de validation TLS en production

Diagnostiquer les erreurs de validation TLS en production

Validation TLS : le compromis entre disponibilité et identité vérifiée

Chaîne de certificats incomplète côté serveur

Nom demandé et SAN : l’erreur de correspondance la plus banale

Horloge système : quand un certificat valide devient invalide

Inspection reproductible avec OpenSSL

Surface d’attaque et limites du dépannage TLS

Checklist de déploiement TLS avant production

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines