Vérifier depuis la ligne de commande, avec openssl, une chaîne de certificats TLS servie et son expiration

Objectif

Répondre, pour un nom d'hôte donné, à trois questions qu'un navigateur résout silencieusement : quels certificats le serveur envoie-t-il, forment-ils une chaîne qu'un client peut vérifier, et quand chacun expire-t-il. C'est le diagnostic ponctuel ; l'alerte planifiée fait l'objet d'un autre article.

Prérequis

Un binaire openssl, un accès réseau à l'hôte, et les noms d'hôte exacts utilisés par les clients (apex, www, hôtes d'API), car le serveur peut choisir un certificat différent selon le nom.

Étapes

1. Récupérer ce que le serveur envoie, avec le SNI défini explicitement : openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null > sent.txt. Le manuel indique que -showcerts affiche la liste de certificats du serveur telle qu'envoyée, dans l'ordre d'envoi, et que cette liste n'est pas une chaîne vérifiée. Il indique aussi que sans -servername, le SNI est rempli à partir du nom de -connect uniquement si celui-ci ressemble à un nom DNS ; le préciser donc en cas de connexion à une adresse IP.
2. Lire le résultat de vérification que s_client affiche après la poignée de main ; une chaîne qui se vérifie localement a quand même besoin de l'étape 4, car le magasin de confiance local peut contenir un intermédiaire dont les clients ne disposent pas.
3. Découper sent.txt en un fichier PEM par certificat et examiner chacun : openssl x509 -in cert1.pem -noout -subject -issuer -enddate -ext subjectAltName. Selon le manuel, -enddate affiche la date notAfter et -ext affiche des extensions nommées telles que subjectAltName. Le premier certificat devrait être la feuille dont les SAN contiennent le nom d'hôte ; chaque certificat suivant devrait être l'émetteur du précédent.
4. Reconstruire la chaîne indépendamment de ce que prétend le serveur : openssl verify -show_chain -untrusted intermediates.pem leaf.pem. Le manuel décrit -untrusted comme un fichier de certificats non fiables utilisé pour la construction de la chaîne, et -show_chain comme affichant la chaîne construite, avec les membres non fiables signalés. L'exécuter contre le magasin de confiance système et, si nécessaire, contre un -CAfile spécifique.
5. Répéter l'étape 1 avec -4 puis avec -6 ; le manuel documente ces options comme des connexions IPv4 seule et IPv6 seule. Un répartiteur de charge peut servir un certificat différent selon la famille d'adresses.
6. Répéter pour chaque nom d'hôte et chaque port qui termine TLS.
7. Consigner dans un tableau le nom d'hôte, la famille d'adresses, la date notAfter de la feuille, la date notAfter la plus proche parmi les intermédiaires, et le résultat de la vérification.

Résultat attendu

Un tableau court par nom d'hôte montrant que la chaîne envoyée est complète et ordonnée, que la vérification réussit sans que le magasin de confiance local ne masque un intermédiaire manquant, et l'expiration la plus proche dans la chaîne.

Limites et base de vérification

Un intermédiaire manquant peut passer sur une machine qui l'a mis en cache et échouer sur un client neuf ; l'étape 4 avec un magasin de confiance minimal constitue le test honnête. Les commandes suivent les manuels cités ; la disponibilité des options varie selon la version d'OpenSSL. Aucun résultat de terrain n'est avancé.