SSL Expiry Monitor

Colle une liste de hosts et vérifie leurs SSL certs dans une seule watchlist qui se trie par days left, avec plan de renouvellement et rapport CSV.

Ce SSL expiry monitor prend une liste de hosts et vérifie le certificate en live que chacun sert sur le port 443, puis trie toute la watchlist par days restants pour que la falaise de renouvellement la plus proche soit tout en haut. Tu choisis un seuil de review, de quatorze jusqu'à quatre-vingt-dix jours, et chaque host reçoit un statut, une date valid-to, une review date calculée à rebours et l'indice issuer, plus un drapeau quand le hostname tapé n'est pas couvert par le SAN ou le subject name parsé. Les échecs et les coverage mismatches remontent en premier, parce que ce sont les lignes que tu veux d'abord. La liste se sauvegarde dans ton navigateur pour une relance en un clic, et tu copies un rapport CSV quand tu veux le transmettre. Ça tourne seulement quand tu cliques, donc traite-le comme un triage rapide avant une migration, un changement de DNS ou un swap de CDN, pas comme un service d'alerte en arrière-plan. Pour un seul host, enchaîne avec le certificate checker.

Les requêtes passent par le service de lookup PeopleAreGeek. Nous ne journalisons rien.

Pourquoi un SSL expiry monitor a sa place dans la routine admin

Un SSL expiry monitor ramène une panne idiote et fréquente à un truc ennuyeux et gérable, parce qu'un certificate mort, c'est une façon idiote de mettre un site à terre, et ça arrive tout le temps. Les visiteurs tombent sur un avertissement de navigateur flippant. Les clients API refusent simplement de se connecter. La moitié de tes widgets embarqués cassent. Et les tickets de support arrivent bien avant que quelqu'un comprenne que la cause est un truc aussi ennuyeux qu'un certificate expiré. Le pire, c'est que ça a pu se renouveler nickel le mois dernier et planter quand même ce mois-ci. Un DNS challenge qui a lâché. Quelqu'un qui a changé un hostname de CDN. Une machine de staging exposée. Ou la personne qui gérait les renouvellements est partie et plus personne ne surveille ce compte.

Une watchlist ramène ce risque à quelque chose de bien plus gérable. Plutôt que de tripoter un domaine quand l'idée te traverse l'esprit, tu gardes les hostnames publics au même endroit, tu les lances tous d'un coup, et tu laisses la liste se trier toute seule pour que la falaise la plus proche soit tout en haut. C'est pratique pour le site principal et son jumeau en www. Et c'est encore plus pratique pour ce qui compte sans faire de bruit : les dashboards, les API, tout ce qui gère des paiements ou des logins, le microsite client de temps en temps, le sous-domaine outil dont les gens dépendent vraiment.

Ce que ce monitor à la demande vérifie

Le certificate réellement servi sur le port 443 pour chaque host, à l'instant présent.
Les validity dates, et combien de days left il te reste.
Les indices issuer et subject common-name, quand le cert se donne la peine de les fournir.
Si le hostname que tu as tapé colle bien à une entrée SAN ou au subject name dans le résumé parsé. En général oui. Parfois vraiment pas.
Une review date calculée à rebours depuis le threshold que tu as choisi.
Tout ce qui n'a pas réussi à se connecter ou a raté le cert check, c'est-à-dire ce que tu veux regarder en premier.

Comment choisir un renewal threshold

Quatorze jours, c'est jouer serré. Honnêtement, c'est à peine un avertissement si un truc dans ta pipeline est cassé. Trente, c'est le plancher que je conseillerais pour un petit site tout simple. Soixante me paraît plus sain dès que la DNS validation, les CDN edges ou trois personnes qui pensent toutes qu'une autre gère les renouvellements entrent dans l'équation, et c'est là que j'atterris d'habitude. Quatre-vingt-dix, c'est pour les équipes qui veulent voir le travail de renouvellement apparaître sur un board avant qu'un cert n'arrive dans sa dernière ligne droite. Rien de tout ça ne consiste à paniquer trop tôt. C'est juste pour te laisser assez de marge pour réparer le challenge path et retester les hostnames en live sans transpirer.

Un workflow de renouvellement concret

Garde la liste aux hostnames que de vraies personnes ou de vraies intégrations ouvrent vraiment. Ne la gonfle pas inutilement.
Lance-la avant tout truc risqué : une migration, un changement de DNS, un swap de CDN, une fenêtre de release.
Regarde d'abord le cert le plus proche de l'échéance. Puis les échecs francs. Puis les hostname mismatches qui ne sont pas en feu mais qui sentent quand même mauvais.
Avant la dernière semaine, confirme que l'auto-renew est vivant, que tu maîtrises le DNS challenge, et qu'il existe un fallback manuel si tout part en vrille.
Une fois renouvelé, relance exactement le même hostname public. Et si HTTPS s'est mis à se comporter différemment, va fouiller les headers ou les redirects.

Le monitoring, c'est plus qu'une seule date

L'expiry est le signal bruyant. Ce qui l'entoure, plus discret, fait trébucher les gens tout aussi souvent. Un cert avec des mois devant lui peut quand même être complètement faux pour un hostname que tu viens d'ajouter. Un renouvellement peut réussir sur l'origin pendant que ton CDN continue gentiment de servir l'ancien. Et un wildcard couvre un niveau de sous-domaines pendant qu'un nom plus profond reste en dehors, totalement découvert. Donc garde les deux outils à portée. Sers-toi de ce monitor pour un triage rapide, et quand un host a l'air bizarre, ouvre le certificate checker et lis-le pour de vrai.

Questions fréquentes

Est-ce que ça va m'envoyer un email quand le SSL expire ?

Non. Ça vérifie la watchlist en live, mais seulement quand tu cliques, et ça range la liste de hosts dans ce navigateur. C'est tout. Une vraie alerte, ça veut dire des checks planifiés qui tournent tout seuls plus quelque chose qui délivre vraiment la notification, et ça, ça vit sur un serveur, pas sur une page que tu as ouverte.

Dois-je surveiller l'apex et le www séparément ?

Si les deux sont publics, oui, surveille-les chacun de son côté. Ils peuvent terminer sur des edges différents ou se cacher derrière des redirects différents, donc ce n'est vraiment pas le même check. Et une casse sur le nom dont personne ne parle gâche quand même la journée de celui qui tombe dessus.

Que dois-je faire quand un host rate le SSL check ?

Commence par les bases. Est-ce que le DNS résout. Est-ce que tu arrives seulement à atteindre le port 443. Ensuite regarde la config du CDN ou du proxy, puis l'automatisation censée renouveler le cert. L'un des trois est généralement le coupable. Et franchement, si le host ne devrait plus être public, retire-le simplement de la liste et coupe l'exposition exprès plutôt que de la laisser traîner.

Combien de temps à l'avance dois-je renouveler un SSL certificate ?

Deux à quatre semaines avant, au minimum. Une fois qu'un cert expire, les navigateurs balancent ce blocage plein écran et le site disparaît purement et simplement pour les visiteurs, donc tu veux de la marge pour le déploiement qui, inévitablement, coince au pire moment.

Pourquoi mon certificate a-t-il expiré alors que j'utilise l'auto-renouvellement Let's Encrypt ?

Parce que l'auto-renouvellement échoue en silence, ce qui est la pire façon d'échouer. Le cron arrête de se déclencher. Le validation path casse. Ou le cert se renouvelle bien mais le serveur web n'est jamais rechargé pour le prendre en compte. Tu ne remarques rien de tout ça tant que le site n'est pas déjà à terre. Alors surveille l'expiry depuis l'extérieur, séparément, et un renouvellement raté devient une alerte au lieu d'une panne.