Boîte à Outils Informatique
Guide

Comment vérifier la chaîne d’un certificat HTTPS avec OpenSSL

s_client permet de voir le certificat réellement présenté par un serveur et les certificats intermédiaires envoyés au client.

ThématiqueCybersécurité →
⌚ Environ 3 min de lecture
Voir mes favoris
SSL / PKI Intermédiaire 10 min

s_client permet de voir le certificat réellement présenté par un serveur et les certificats intermédiaires envoyés au client.

Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une sauvegarde ou un retour arrière lorsque l’action peut modifier la configuration.

Étapes à suivre

  1. 1

    Tester avec SNI

    Utilisez le même nom DNS pour -connect et -servername lorsque le site est mutualisé.

  2. 2

    Lire les dates

    Vérifiez notBefore et notAfter.

  3. 3

    Contrôler les SAN

    Assurez-vous que le nom utilisé par le client est couvert.

  4. 4

    Examiner la chaîne

    Vérifiez que les intermédiaires nécessaires sont présentés.

  5. 5

    Comparer depuis plusieurs réseaux

    Si un proxy TLS est présent, le certificat peut différer.

Commandes utiles

openssl s_client -connect exemple.fr:443 -servername exemple.fr -showcerts
openssl x509 -noout -subject -issuer -dates -ext subjectAltName

À retenir

  • Le certificat stocké sur le serveur n’est pas forcément celui présenté au client.
  • Une racine n’a généralement pas besoin d’être envoyée par le serveur.
  • Une erreur de nom d’hôte ne se corrige pas en ignorant la validation TLS.
← Tous les guides
Complément technique

HTTPS/TLS : séparer disponibilité HTTP, handshake TLS et identité du certificat

Repères techniques

  • Un port 443 ouvert ne prouve pas qu’un handshake TLS valide aboutit, et un handshake valide ne prouve pas que le code HTTP est 200.
  • Le certificat doit couvrir le nom utilisé via SAN, être dans sa période de validité et présenter une chaîne de confiance complète.
  • Avec SNI

OpenSSL + HTTP

Tester le handshake avec le bon servername puis lire le statut HTTP séparément.

openssl s_client -connect example.com:443 -servername example.com -showcerts
curl -I https://example.com/

Pièges spécifiques

  • Ne pas confondre certificat expiré et chaîne intermédiaire manquante : les messages clients diffèrent.
  • Schannel 36874/36888 doit être corrélé au protocole/cipher et au client qui déclenche l’alerte.

Comment valider

  • Le nom, la chaîne, les dates et le protocole sont valides depuis un client représentatif.
  • La requête HTTP atteint le backend attendu et retourne le statut prévu.

Preuves et vérifications

Un port 443 ouvert ne prouve pas qu’un handshake TLS valide aboutit, et un handshake valide ne prouve pas que le code HTTP est 200. Le certificat doit couvrir le nom utilisé via SAN, être dans sa période de validité et présenter une chaîne de confiance complète.

Contrôle de résultat

Le nom, la chaîne, les dates et le protocole sont valides depuis un client représentatif. La requête HTTP atteint le backend attendu et retourne le statut prévu.

Point d’attention

Ne pas confondre certificat expiré et chaîne intermédiaire manquante : les messages clients diffèrent. Avec SNI, tester l’IP seule peut présenter un certificat différent de celui du nom DNS.

Concepts liés

Référence primaire : OpenSSL Documentation — s_client.

♡ 0