Surveiller l'expiration des certificats SSL et des domaines

Un certificat SSL/TLS expiré affiche une page d'avertissement plein écran à chaque visiteur, casse les appels d'API et peut bloquer l'envoi d'e-mails. Un nom de domaine expiré, c'est pire : le site, les e-mails et tout ce qui repose sur ce domaine disparaissent d'un coup. Les deux pannes sont pourtant parfaitement prévisibles, puisque la date d'échéance est connue des mois à l'avance.

Ce guide explique pourquoi ces expirations arrivent encore malgré le renouvellement automatique, comment vérifier un certificat et un domaine à la main, quel calendrier d'alertes adopter, et comment tenir un inventaire quand on gère des dizaines de clients.

Pourquoi les expirations arrivent encore

Le renouvellement automatique a aussi créé une fausse impression de sécurité. Les causes les plus fréquentes :

• Le renouvellement automatique échoue en silence. Une tâche planifiée supprimée lors d'une migration de serveur, un challenge HTTP bloqué par une nouvelle règle de pare-feu ou une redirection, un enregistrement DNS modifié : le client ACME échoue et personne ne lit ses journaux.
• Le certificat est renouvelé mais pas déployé. Le nouveau fichier est bien sur le disque, mais le serveur web n'a pas été rechargé et sert toujours l'ancien certificat en mémoire. Même scénario quand le certificat doit être copié à la main sur un répartiteur de charge, un CDN ou un deuxième serveur.
• La chaîne intermédiaire est incomplète. Le certificat est valide, mais le serveur n'envoie pas le certificat intermédiaire. Certains navigateurs compensent, alors le site semble fonctionner, tandis que les clients API, les applications mobiles et les outils en ligne de commande échouent.
• Le domaine est enregistré au nom d'un ancien salarié. Compte chez le registrar créé avec une adresse personnelle, paiement sur sa carte bancaire : la carte expire, les rappels partent dans une boîte que plus personne ne lit, et le domaine expire.

Enfin, Let's Encrypt n'envoie plus d'e-mails de rappel avant expiration depuis 2025 : ce filet de sécurité a disparu.

Vérifier un certificat à la main avec openssl

Lire la date d'expiration

La commande suivante se connecte au serveur, récupère le certificat présenté et affiche son émetteur et sa date de fin de validité :

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

issuer=C = US, O = Let's Encrypt, CN = R11
notAfter=Dec 14 08:12:45 2026 GMT

L'option -servername est indispensable dès que plusieurs sites partagent la même adresse IP : sans elle, vous risquez de lire le certificat d'un autre site.

Tester l'échéance dans un script

L'option -checkend prend un nombre de secondes et renvoie un code de sortie non nul si le certificat expire avant ce délai. Ici, 14 jours :

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

Comparer le fichier et le certificat servi

Pour détecter un certificat renouvelé mais pas chargé, comparez la date du fichier sur le disque avec celle obtenue par la commande précédente :

openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -enddate

Si le fichier est plus récent que ce que le serveur présente, il manque un rechargement. Avec certbot, un hook de déploiement règle le problème durablement :

certbot renew --deploy-hook "systemctl reload nginx"

Vérifier la chaîne et les autres services

Lancez openssl s_client sans le second openssl x509 et regardez la ligne Verify return code en fin de sortie. 0 (ok) signifie que la chaîne est valide ; 21 (unable to verify the first certificate) trahit presque toujours un intermédiaire manquant. Les serveurs de messagerie ont aussi des certificats, à tester avec STARTTLS :

openssl s_client -connect mail.example.com:587 -starttls smtp -servername mail.example.com

Let's Encrypt : 90 jours de validité

Les certificats Let's Encrypt sont valables 90 jours. La pratique recommandée est de les renouveler quand il reste environ 30 jours, ce que fait certbot par défaut. Conséquence directe : un certificat Let's Encrypt qui n'a plus que 20 jours de validité n'est pas un certificat à renouveler bientôt, c'est un renouvellement qui a déjà échoué.

La tendance va vers des durées encore plus courtes. Les règles du CA/Browser Forum limitent la validité des certificats publics à 200 jours depuis mars 2026, puis la réduiront à 100 jours en 2027 et 47 jours en 2029, et Let's Encrypt a annoncé un passage progressif à 45 jours. Plus de renouvellements, donc plus d'occasions d'échec. La documentation de Let's Encrypt détaille les bonnes pratiques.

Vérifier un nom de domaine avec RDAP plutôt que WHOIS

WHOIS renvoie du texte libre dont le format varie selon le registre. RDAP, son successeur officiel, répond en JSON structuré et standardisé sur HTTPS. Pour les extensions génériques comme .com, l'ICANN en a fait la source de référence début 2025.

Le service rdap.org redirige vers le serveur RDAP du bon registre, d'où l'option -L :

curl -sL https://rdap.org/domain/example.com \
  | jq '{status, nameservers: [.nameservers[].ldhName], expiration: (.events[] | select(.eventAction == "expiration") | .eventDate)}'

Vous pouvez aussi interroger directement le registre, par exemple Verisign pour le .com ou l'Afnic pour le .fr. La liste officielle des serveurs par extension est publiée par l'IANA dans son fichier d'amorçage RDAP.

curl -s https://rdap.verisign.com/com/v1/domain/example.com
curl -s https://rdap.nic.fr/domain/example.fr

Les statuts à surveiller

Le champ status mérite autant d'attention que la date. Les statuts clientHold (posé par le registrar) et serverHold (posé par le registre) retirent le domaine de la zone DNS : il est toujours enregistré à votre nom, mais il ne résout plus. Les causes typiques sont un impayé, une adresse e-mail du titulaire non vérifiée ou une procédure pour abus. En RDAP, ces statuts apparaissent sous la forme client hold et server hold. D'autres, comme redemption period ou pending delete, signifient que le domaine a déjà expiré.

Les changements de serveurs de noms

Un changement de serveurs de noms que vous n'avez pas demandé est un signal classique de détournement de domaine, par exemple après la compromission du compte chez le registrar. Comparez régulièrement la liste RDAP à la réalité avec dig NS example.com +short, et traitez toute différence inattendue comme un incident de sécurité. Une surveillance DNS complète ce contrôle en détectant les modifications des enregistrements eux-mêmes.

Quel calendrier d'alertes adopter

Un seul rappel ne suffit pas : il tombe pendant les congés ou se perd dans une boîte partagée. Échelonnez-les.

Les domaines ont besoin d'un préavis plus long : il faut parfois obtenir l'accord du client, retrouver l'accès au compte du registrar, mettre à jour un moyen de paiement ou lancer un transfert, qui prend plusieurs jours. Un certificat, en revanche, se renouvelle en quelques minutes une fois la cause trouvée.

Envoyez ces rappels vers un canal d'équipe plutôt que vers une personne, et évitez de réveiller l'astreinte pour un rappel à 30 jours : c'est un avertissement, pas une panne.

Tenir un inventaire quand on gère plusieurs clients

Pour une agence ou un freelance, le vrai problème est de savoir quels domaines existent et qui en est responsable. Un inventaire tenu à jour contient pour chaque domaine :

• le registrar et le compte qui le détient (adresse générique de l'agence ou du client, jamais une adresse personnelle) ;
• qui paie, avec quel moyen de paiement et sa date d'expiration ;
• le renouvellement automatique activé ou non ;
• l'hébergeur DNS et l'endroit où vivent les certificats (serveur, CDN, répartiteur de charge) et leur mode de renouvellement ;
• le contact côté client à prévenir.

Stockez les accès dans un gestionnaire de mots de passe partagé, et relisez l'inventaire à chaque arrivée ou départ dans l'équipe. Notre checklist de surveillance pour les agences web couvre le reste du périmètre.

Ce que LucidStack fait automatiquement

LucidStack s'appuie sur ce que vous surveillez déjà. Chaque moniteur HTTPS vérifie le certificat à chaque exécution, tout comme les serveurs de messagerie en STARTTLS ou TLS et les WebSockets chiffrés. Vous recevez des rappels 30, 14, 7 et 1 jour avant l'expiration, et une alerte immédiate si le certificat devient invalide : chaîne incomplète, nom d'hôte qui ne correspond pas, certificat expiré. Un changement d'émetteur est également signalé. Le détail est sur la page surveillance des certificats SSL.

Côté domaines, ceux de vos moniteurs sont détectés automatiquement et vérifiés chaque jour via RDAP, avec des rappels 60, 30, 7 et 1 jour avant l'échéance, un signalement immédiat de tout changement de serveurs de noms et des statuts bloquants comme clientHold ou serverHold. Cela concerne les extensions dont le registre publie un service RDAP, soit la grande majorité des extensions courantes. Voir la page expiration des noms de domaine.

Un tableau regroupe toutes les échéances de certificats et de domaines, triées par urgence, et elles figurent dans les rapports mensuels. Les rappels arrivent sur le canal d'alerte de votre choix, et vos heures calmes les retiennent jusqu'à la fin de la plage définie, tandis que les vraies pannes passent toujours.

En résumé

Ces expirations sont rarement une surprise technique, presque toujours un problème d'organisation : une tâche qui échoue en silence, un rechargement oublié, un compte au mauvais nom. Vérifiez à la main avec openssl et RDAP en cas de doute, puis automatisez avec des rappels échelonnés et un inventaire à jour. LucidStack le fait pour chaque moniteur HTTPS que vous créez, sans configuration supplémentaire.