Quand un certificat TLS expire sans que personne ne le voie

Un certificat TLS n’expire presque jamais « d’un coup ». Il expire à une date connue, écrite dans le certificat lui-même, souvent renouvelable automatiquement. Pourtant, la panne reste banale : page d’erreur navigateur, API qui refuse la négociation, monitoring qui n’alerte que quand le service est déjà rouge.

Le pattern observé

1. Le renouvellement ACME est censé tourner.
2. Un redémarrage, un mauvais virtual host ou un certificat intermédiaire oublié laisse l’ancien fichier en place.
3. L’uptime HTTP reste vert tant que le port 443 répond.
4. Le premier signal utile arrive d’un humain externe.

Le trou n’est pas technique : c’est un trou de signal. Uptime ≠ validité du certificat ≠ date d’expiration du domaine.

Diagnostic minimal

Sans outil exotique :

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

Puis croiser :

• la date notAfter
• le SAN (le bon hostname est-il couvert ?)
• la chaîne complète (intermédiaire manquant = OK pour certains clients, KO pour d’autres)
• le monitoring : a-t-on une sonde dédiée à l’expiration, distincte de l’uptime ?

Correctif durable

• Une sonde d’expiration TLS (seuil J-30 / J-14 / J-7), pas seulement un ping HTTPS.
• Une alerte domaine (RDAP/WHOIS) séparée : le certificat peut être parfait sur un domaine qui expire.
• Un runbook de renouvellement testé hors production au moins une fois.
• Un rapport mensuel qui cite la date d’expiration constatée, pas « tout va bien ».

C’est exactement le périmètre d’une offre de supervision externe sobre : peu de métriques, mais les bonnes, avec un historique lisible.

Prévention

Si votre monitoring ne sait pas répondre à « dans combien de jours expire le certificat du hostname public X ? », ce n’est pas encore de la supervision d’infrastructure — c’est de la détection de panne.