Vérifier l'expiration d'un certificat SSL et être alerté à temps

Pour savoir quand un certificat SSL expire, vous avez trois options : cliquer sur le cadenas du navigateur, lancer une commande openssl, ou lire la sortie du handshake de curl. Chacune prend moins d'une minute et donne la date notAfter du certificat que le serveur présente en ce moment. C'est la partie facile. La partie difficile, c'est que les certificats vivent désormais 90 jours, bientôt 47, et qu'une date vérifiée le trimestre dernier ne dit rien d'aujourd'hui. Ce guide couvre d'abord la vérification ponctuelle, puis la mise sous surveillance quotidienne pour qu'un renouvellement cassé vous parvienne avant de parvenir à vos utilisateurs. Il s'agit du certificat, pas du nom de domaine : l'expiration du domaine est une affaire de registre, avec son propre calendrier.

Lire la date d'expiration dans le navigateur

Cliquez sur le cadenas (ou l'icône d'informations du site) à gauche de l'adresse. Dans Chrome, ouvrez « La connexion est sécurisée » puis « Le certificat est valide » ; dans Firefox, « Connexion sécurisée » puis « Plus d'informations » et « Afficher le certificat » ; dans Safari, « Afficher le certificat ». La visionneuse montre une période de validité avec deux dates. La seconde, « Valide jusqu'au » ou « Not after », est l'expiration. Le navigateur l'affiche dans votre fuseau horaire, mais le certificat la stocke en UTC : un certificat qui « expire à 01:59 » est peut-être déjà mort pour un utilisateur deux fuseaux plus à l'est.

C'est suffisant pour vérifier un site tiers ou répondre à un collègue qui a vu un avertissement. Ça ne suffit pas pour vérifier sa propre infrastructure, parce qu'un navigateur ne montre qu'un hostname à la fois, et seulement celui auquel vous avez pensé.

Vérifier avec openssl et curl en ligne de commande

La commande openssl à connaître

openssl s_client -servername example.com -connect example.com:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -dates -issuer -subject

La sortie donne notBefore, notAfter, l'émetteur et le sujet. Gardez l'option -servername : elle envoie le hostname dans le handshake TLS (SNI), et sans elle un serveur qui héberge plusieurs sites vous tend son certificat par défaut, qui peut être différent de celui du site que vous vouliez vérifier. Beaucoup de mystères du type « chez moi le certificat est bon » viennent d'une vérification sans SNI.

Tester un seuil dans un script

openssl s_client -servername example.com -connect example.com:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -checkend 1209600 \
  || echo "example.com expire dans moins de 14 jours"

-checkend prend un nombre de secondes (14 jours ici) et renvoie un code de sortie non nul si le certificat aura expiré d'ici là. C'est ce code de sortie qu'un cron ou une étape de CI attend.

curl et un fichier local

curl -vI https://example.com 2>&1 | grep -iE "expire date|issuer"

curl affiche les dates du certificat qu'il a négocié, pratique sur une machine sans openssl. Pour un fichier de certificat dans un pipeline de déploiement, avant même qu'il soit servi :

openssl x509 -in cert.pem -noout -enddate

Pourquoi une vérification ponctuelle ne suffit plus

La durée de vie des certificats raccourcit depuis dix ans, et le CA/Browser Forum a voté les prochaines étapes.

Certificat	Durée de vie maximale
Let's Encrypt (par défaut)	90 jours
Tout certificat public depuis mars 2026	200 jours
Tout certificat public à partir de mars 2027	100 jours
Tout certificat public à partir de mars 2029	47 jours

À 47 jours, personne ne renouvelle à la main. Le renouvellement est automatisé, et l'automatisation échoue en silence : un challenge DNS casse après une migration, quelqu'un ajoute un enregistrement CAA qui exclut l'émetteur, un jeton d'API expire, un sous-domaine survit à la personne qui en avait la charge. Le cron écrit une erreur que personne ne lit, et l'ancien certificat continue de fonctionner jusqu'au jour où il ne fonctionne plus. Le guide des renouvellements Let's Encrypt en échec liste les causes ; celui sur ce qui se passe quand un certificat expire décrit les dégâts. Le point ici est plus simple : avec des certificats courts, ce qu'on surveille c'est le renouvellement, et le seul témoin fiable est le certificat servi vu de l'extérieur.

Mettre la date d'expiration sous surveillance avec Domain Sentinel

Ajoutez le domaine à votre watchlist et activez la surveillance du certificat TLS. Laissez le hostname vide pour contrôler le domaine lui-même, ou saisissez www ou api si le HTTPS est servi là. À partir de là, Domain Sentinel se connecte à cet hôte chaque jour, lit le certificat comme le ferait un navigateur, et garde un instantané dès que quelque chose change : émetteur, dates, empreinte. Vous recevez un e-mail 14, 7, 3 et 1 jours avant l'expiration, et une alerte au contrôle suivant si le certificat a expiré, est auto-signé, est émis pour un autre nom, ou vient d'un émetteur différent du précédent. Un bouton « Vérifier maintenant » lance le même contrôle à la demande.

Les limites, dites clairement : un hostname par domaine surveillé, pas de découverte automatique de vos sous-domaines, et pas de renouvellement à votre place. Constituez vous-même l'inventaire de vos hostnames publics (site, www, api, mail), le guide de la surveillance des journaux Certificate Transparency montre comment, et ajoutez chacun d'eux. Ce n'est pas non plus de la surveillance d'uptime : on lit le certificat, on ne vérifie pas que la page se charge, une distinction que la comparaison entre surveillance DNS et surveillance d'uptime explique.

Ce que les seuils d'alerte signifient pour vos certificats

Les seuils sont fixés à 14, 7, 3 et 1 jours, et l'absence d'alerte à 30 jours est voulue. Let's Encrypt renouvelle un certificat de 90 jours quand il en reste 30 : une alerte à J-30 sonnerait à chaque cycle sain et vous apprendrait à l'ignorer. Quatorze jours signifie que le renouvellement qui aurait dû avoir lieu n'a pas eu lieu, et qu'il vous reste deux semaines.

Votre certificat	Comment lire les alertes
Certificat d'un an, renouvelé à la main	J-14 laisse le temps d'un renouvellement manuel ; traitez l'alerte J-7 comme urgente
Certificat de 90 jours, automatisé	Toute alerte signifie que l'automatisation a cassé ; l'alerte de changement d'émetteur est votre confirmation qu'un renouvellement a bien eu lieu
Certificat de 47 jours	Même logique, avec moins de marge : vérifiez le job de renouvellement le jour où l'alerte J-14 arrive

À faire maintenant

Lancez la commande openssl sur votre hostname principal et lisez notAfter. Listez tous les hostnames qui servent du HTTPS, y compris ceux que vous aviez oubliés, et ajoutez chacun à une watchlist avec la surveillance TLS activée. Puis arrêtez de vérifier les dates à la main : avec des certificats de 90 jours, ce n'est pas le calendrier qu'il faut surveiller, c'est le renouvellement.