Surveillance de l'expiration des certificats SSL : ne l'apprenez pas du client

La surveillance de l'expiration des certificats SSL consiste à vérifier automatiquement et régulièrement combien de jours il reste au certificat TLS d'un site, et à envoyer une alerte assez tôt pour le renouveler. Quand un certificat expire, les navigateurs remplacent la page par un avertissement plein écran : formulaires, connexions et paiements cessent de fonctionner, et le trafic s'effondre presque aussitôt.

Les expirations touchent rarement le site vitrine que tout le monde surveille. Elles arrivent sur le site hérité d'une agence précédente, sur un sous-domaine que personne n'a recensé, pendant un week-end. Trop souvent, le client s'en aperçoit avant l'agence.

Ce que voient les visiteurs et les robots quand le certificat SSL expire

Dans Chrome, la page affiche « Votre connexion n'est pas privée » avec le code d'erreur NET::ERR_CERT_DATE_INVALID. Firefox affiche « Attention : risque probable de sécurité » avec SEC_ERROR_EXPIRED_CERTIFICATE. La plupart des gens s'en vont. Si le site envoie un en-tête Strict-Transport-Security (HSTS), les navigateurs ne proposent même pas de continuer : le site devient tout simplement inaccessible pour les visiteurs habituels.

Les statistiques tombent à plat, parce que la page ne se charge jamais et que le script de suivi ne s'exécute pas. Les formulaires de paiement et de contact échouent. Les appels de serveur à serveur, comme les webhooks d'un prestataire de paiement, rejettent le certificat et consignent en général l'erreur dans un endroit que personne ne consulte. Googlebot rencontre des erreurs de récupération et, si le problème dure des jours plutôt que des heures, l'exploration ralentit et des pages peuvent sortir de l'index.

Pourquoi un certificat expire malgré le renouvellement automatique

Les certificats Let's Encrypt durent 90 jours, et leur renouvellement est normalement une tâche planifiée lancée par Certbot ou par le panneau d'hébergement. Elle échoue de quelques façons prévisibles.

La tâche elle-même casse. Une mise à jour de paquet, un environnement Python modifié ou un disque plein fait sortir certbot renew en erreur, et cette erreur finit dans /var/log/letsencrypt/ et nulle part ailleurs. Let's Encrypt a en outre arrêté ses e-mails de rappel d'expiration en 2025 : l'avertissement sur lequel beaucoup comptaient n'arrive plus.

La validation ne passe plus. Le challenge HTTP-01 exige que /.well-known/acme-challenge/ soit accessible sur le port 80. Une nouvelle règle de redirection, un WAF ou une modification du pare-feu peut le bloquer. Pour le DNS-01, déménager le DNS chez un autre fournisseur casse les identifiants d'API qu'utilisait le renouvellement.

Le certificat est renouvelé mais jamais chargé. Nginx et Apache continuent de servir le certificat chargé au démarrage tant qu'ils ne sont pas rechargés. Certbot gère cela avec un deploy hook comme --deploy-hook "systemctl reload nginx" ; si ce hook n'a jamais été configuré, le fichier sur le disque est à jour pendant que les visiteurs reçoivent l'ancien, expiré.

La périphérie et l'origine divergent. Quand Cloudflare ou un load balancer termine le TLS, il y a deux certificats et deux dates d'expiration. Celui que voient les visiteurs est en périphérie, mais un certificat d'origine expiré coupe la connexion en arrière-plan lorsque le mode Full (strict) est activé.

Les sous-domaines sont oubliés. Un certificat pour example.com et www.example.com ne couvre ni shop.example.com ni staging.example.com, qui peuvent chacun avoir leur propre certificat et leur propre tâche de renouvellement.

La commande certbot renew --dry-run permet de tester la procédure de renouvellement sans rien remplacer.

Vérifier la date vous-même

Dans un navigateur, cliquez sur l'icône à gauche de la barre d'adresse, ouvrez les détails du certificat et lisez la date « Expire le » ou « Valide jusqu'au ».

En ligne de commande :

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

Cette commande affiche notBefore, notAfter et l'émetteur. Ajoutez toujours -servername : sans cette option, un serveur qui héberge plusieurs sites sur une même IP peut renvoyer son certificat par défaut plutôt que celui de votre nom d'hôte.

Profitez-en pour vérifier deux autres points. L'émetteur doit être celui que vous attendez, car un changement signifie souvent que l'hébergement ou le CDN a été reconfiguré. Et la chaîne doit être complète : un certificat intermédiaire manquant ou un nom d'hôte absent des Subject Alternative Names du certificat provoque le même avertissement qu'une expiration, même s'il reste des mois de validité.

Pour un site, cela prend une minute. Sur trente clients, avec leurs sous-domaines et quelques préproductions, cela devient une tâche qui saute pendant les semaines chargées. La checklist de surveillance de site web pour les agences couvre les autres vérifications récurrentes qui subissent le même sort.

Surveillance de l'expiration des certificats SSL dans Deltio

Deltio vérifie le certificat de chaque site que vous ajoutez, affiche les jours restants et l'émetteur dans le tableau de bord, et vous alerte sur Slack et par e-mail avant l'expiration ainsi que lorsqu'un certificat n'est pas valide. L'expiration du domaine est vérifiée au même endroit, ce qui compte, car un domaine expiré fait tomber d'un coup le certificat, le site et la messagerie. L'uptime, le robots.txt et les changements de sitemap sont suivis sur le même compte : le SSL devient une ligne dans une vue d'ensemble de chaque site client plutôt qu'un outil à part, l'approche décrite dans comment surveiller les changements sur les sites clients. Un certificat expiré équivaut en pratique à une panne, et c'est aussi pour cela qu'il figure dans notre comparatif alternative à UptimeRobot.