Aller au contenu principal

Vérifier la chaîne de certificats d’un serveur avec openssl s_client

Fiche écrite en 2021, pour les navigateurs et les versions de l’époque. Vérifiez qu’elle correspond encore à votre environnement avant de l’appliquer.

À une semaine de l’expiration de l’ancienne racine de Let’s Encrypt, c’est le bon moment pour vérifier deux choses : ce que vos sites présentent aux visiteurs, et ce que votre serveur accepte quand il appelle d’autres services. Un navigateur affiche un cadenas ; openssl montre tout le détail.

Terminal
# Chaîne complète envoyée par le serveur, et verdict de vérification
openssl s_client -connect www.exemple.fr:443 -servername www.exemple.fr -showcerts < /dev/null

# Émetteur, sujet et dates de validité du certificat
echo | openssl s_client -connect www.exemple.fr:443 -servername www.exemple.fr 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

Dans la première sortie, on lit la section Certificate chain et la dernière ligne, Verify return code: 0 (ok). Un code différent signale une chaîne incomplète : le serveur envoie souvent cert.pem au lieu de fullchain.pem. Le second bloc se lance depuis le serveur lui-même : c’est lui qui, avec un OpenSSL trop ancien ou des certificats racine périmés, refusera demain de parler à la banque ou au transporteur.

Terminal
# Depuis le serveur : ses propres appels sortants passent-ils ?
curl -sSvI https://api.exemple-transporteur.fr/ 2>&1 | grep -Ei 'SSL|issuer|expire|verify'

# Versions à surveiller
openssl version
dpkg -l ca-certificates | tail -1

Sources

  1. OpenSSL, s_client openssl.org
  2. Let’s Encrypt, expiration de DST Root CA X3 letsencrypt.org