Surveiller l'expiration des certificats TLS sur chaque point d'accès, pas seulement sur le site web principal

Objectif

Ne jamais apprendre l'expiration d'un certificat par un utilisateur. Chaque certificat présenté par l'organisation a une date d'expiration connue et une alerte qui se déclenche assez tôt pour permettre de rétablir le renouvellement par une intervention manuelle.

Prérequis

Un inventaire des noms d'hôtes et des ports qui assurent la terminaison TLS (443, mais aussi SMTP, IMAP, LDAP, les ports de bases de données, les interfaces d'administration, les points d'écoute des répartiteurs de charge, les points d'accès VPN) ; un système de supervision qui exécute des sondes à intervalles planifiés ; la connaissance du mode d'émission de chaque certificat (client ACME, gestion par un fournisseur, émission manuelle).

Étapes

1. Construire l'inventaire à partir de ce qui est réellement présenté, pas de ce qui est documenté : scanner les adresses et les noms DNS appartenant à l'organisation à la recherche de points d'écoute TLS, et consigner l'hôte, le port, le sujet et l'émetteur.
2. Pour chaque point d'accès, sonder depuis l'extérieur de l'hôte et lire la chaîne telle qu'un client la voit. La RFC 5280 définit la période de validité par notBefore et notAfter ; le certificat final et chaque intermédiaire possèdent leur propre période.
3. Calculer le nombre de jours restant jusqu'à notAfter pour le certificat final et les intermédiaires, et l'exporter comme métrique. Pour un script, le manuel d'OpenSSL documente openssl x509 -checkend <seconds>, qui se termine avec un code non nul lorsque le certificat expire dans ce nombre de secondes ; le manuel de la version 3.6 ajoute -multi, avec lequel -checkend échoue si l'un des certificats fournis en entrée (par exemple une chaîne enregistrée) expire pendant cette période. Le manuel de la version 3.5 ne mentionne pas -multi ; sur les versions plus anciennes, vérifier donc séparément le certificat final et chaque intermédiaire.
4. Fixer le seuil en fonction du mécanisme d'émission. Let's Encrypt indique que ses certificats par défaut sont valides 90 jours et recommande de les renouveler tous les 60 jours, et que ses certificats de courte durée sont valides six jours avec un renouvellement tous les trois jours. Dans le cas des 90 jours, un renouvellement au jour 60 laisse 30 jours de marge ; une alerte à 20 jours restants signifie donc que le renouvellement automatisé a déjà manqué un cycle, alors qu'il reste encore du temps pour une intervention humaine. Les certificats de six jours nécessitent un seuil mesuré en heures.
5. Alerter également en cas d'échec de la sonde (port fermé, erreur de négociation) et lorsque le sujet ou l'émetteur d'un certificat diffère de celui attendu.
6. Tester l'alerte en sondant un certificat à durée de validité délibérément courte, ou en relevant le seuil au-dessus du nombre de jours actuellement restants pour un point d'accès.
7. Consigner, pour chaque point d'accès, qui renouvelle le certificat et comment ; la procédure associée à l'alerte est « effectuer le renouvellement, puis sonder à nouveau ».

Résultat attendu

Une vue d'ensemble de la durée de validité restante de chaque certificat, une alerte qui se déclenche alors qu'il reste une marge confortable pour un renouvellement manuel, et aucun point d'accès dont le certificat réserve une surprise.

Limites et base de vérification

Sonder depuis l'intérieur de l'hôte ne permet pas de voir les certificats présentés par un répartiteur de charge ou un CDN placé en amont. Les certificats clients et les certificats de signature de code nécessitent le même inventaire, mais des sondes différentes. Les durées de validité suivent les déclarations citées des émetteurs ; aucune statistique de défaillance n'est avancée.