Un certificat TLS expiré n’éteint pas toujours le serveur. La page peut être générée normalement, et le navigateur du visiteur la bloque quand même, ou affiche un avertissement que presque personne ne dépasse. Le contrôle utile lit la date de fin du certificat présenté au visiteur, plusieurs semaines avant, pas le code HTTP du jour.
Let’s Encrypt et les autorités automatiques délivrent souvent des certificats d’environ 90 jours. Le renouvellement est censé se faire seul. Il échoue en silence quand le défi HTTP ne passe plus, quand le compte a changé, ou quand un proxy s’est mis devant. L’ancien certificat continue de marcher jusqu’à sa date de fin. C’est cette date qu’il faut surveiller, pas le succès du dernier script.
Ce qu’on lit sur le certificat
On interroge le nom d’hôte public, port 443, comme un navigateur. Trois contrôles suffisent.
| Contrôle | Échec typique |
|---|---|
Date de fin (notAfter) encore loin | Certificat expiré ou trop proche de l’échéance |
| Nom d’hôte couvert (CN ou SAN) | Certificat d’un autre site, ou www absent |
| Chaîne jusqu’à une racine reconnue | Intermédiaire manquant : erreur sur une partie des clients |
Alertez une première fois autour de 30 jours avant la fin, et une seconde fois autour de 7 jours si le certificat n’a pas été remplacé. Ces seuils laissent le temps d’un renouvellement manuel. Les ajuster d’une semaine ne change pas le principe : l’alerte du matin même de l’expiration arrive trop tard pour les visiteurs déjà bloqués.
Le nom doit couvrir l’URL que les gens utilisent. Un certificat valide pour exemple.fr mais pas pour www.exemple.fr casse une des deux adresses. Après un ajout de sous-domaine (boutique, app), vérifiez qu’il est dans le certificat ou qu’il a le sien.
Si un CDN ou un pare-feu termine le HTTPS, le visiteur voit ce certificat-là. L’origine, derrière, peut en avoir un autre. Les deux se renouvellent. Une sonde qui vise l’origine en contournant le CDN ne voit pas ce que voient les visiteurs, et l’inverse rate l’origine. Surveillez au minimum le certificat public. Ajoutez l’origine si un échec de ce second certificat coupe le CDN de votre serveur.
La façon de lire la date à la main, pour un contrôle ponctuel de diagnostic, est dans vérifier la date d’expiration SSL. Ce geste ne remplace pas une alerte : un certificat de 90 jours se termine un dimanche comme un mardi.
Renouvellement qui échoue sans que le site tombe
Le symptôme avant l’échéance est invisible pour une sonde HTTP classique : 200, cadenas encore valide. Seule la date qui se rapproche trahit le renouvellement cassé. Causes fréquentes :
- la validation HTTP ou DNS ne passe plus (redirection, pare-feu, enregistrement retiré) ;
- le certificat a été installé à la main et rien ne le renouvelle ;
- le CDN a son propre certificat, renouvelé chez le CDN, et plus chez vous ;
- l’horloge du serveur est fausse, et le certificat est « pas encore valide » ou déjà rejeté.
Le jour où il est expiré, les visiteurs voient un avertissement. La correction d’urgence est décrite dans certificat expiré : que faire. Mieux vaut ne pas y arriver : l’alerte à 30 jours existe pour renouveler pendant que le site répond encore.
Ne confondez pas cette alerte avec celle du nom de domaine. Un domaine expiré et un certificat expiré coupent tous les deux l’accès, pour des raisons différentes, chez des fournisseurs parfois différents. Le domaine se suit à part.
Brancher le contrôle
- Listez les noms d’hôte publics (apex,
www, sous-domaines qui servent des pages). - Pour chacun, notez qui émet le certificat et s’il y en a un second à l’origine.
- Faites lire la date de fin par une sonde externe, pas seulement par un script sur le serveur : un script local ne voit pas le certificat du CDN. Le monitoring SiteGarde peut porter cette vérification sur l’URL publique.
- Réglez l’alerte vers 30 jours, puis vers 7 jours, vers une boîte lue dans la semaine. Ce n’est pas une alerte de nuit, sauf le jour où vous avez déjà laissé passer les deux seuils.
- Après un renouvellement, vérifiez que la date de fin lue par la sonde a bien avancé. L’ancien certificat peut rester en place si le nouveau n’a pas été installé sur le bon proxy.
Refaites la liste des noms d’hôte quand vous ouvrez un sous-domaine. Le certificat surveillé de l’accueil ne couvre pas, à lui seul, une nouvelle boutique sur un autre hôte.