Le renouvellement automatique promet que vous pouvez cesser de penser aux certificats. Il tient presque toujours cette promesse, et c’est pourquoi le jour où il échoue est une surprise. Le site fonctionnait hier, et aujourd’hui les navigateurs affichent un avertissement en pleine page.
La raison est que le « renouvellement automatique » n’est pas une seule chose. Pour un certificat émis via le protocole automatisé courant (ACME), utilisé par Let’s Encrypt et d’autres, plusieurs étapes doivent toutes fonctionner à chaque fois. Pour le fonctionnement général des certificats et la lecture de leurs dates, consultez Comment éviter l’expiration d’un certificat SSL. Ce guide traite du cas où l’automatisation était activée et où le certificat a pourtant expiré.
La chaîne d’étapes
- Une tâche démarre. Quelque chose s’exécute selon un calendrier : un minuteur, une entrée cron ou une tâche intégrée de votre hébergement.
- Le client de renouvellement demande un nouveau certificat. Il contacte l’autorité de certification.
- L’autorité vérifie que vous contrôlez le nom. Un défi doit être relevé, par le web ou dans le DNS.
- Le nouveau certificat est enregistré dans un fichier ou un magasin.
- Le serveur le charge. De nombreux serveurs ne lisent le fichier qu’au démarrage ou lors d’un rechargement.
- Les visiteurs le reçoivent. Sur chaque adresse, chaque port et chaque couche qui présente un certificat.
Si l’étape 1 ne s’exécute jamais, le reste n’a aucune importance. Si l’étape 5 n’a jamais lieu, le fichier renouvelé reste inutilisé. Chaque échec se présente de la même façon vu de l’extérieur : un ancien certificat qui expire.
Où ça casse
| Étape | Ce qui se passe mal | Un signe typique |
|---|---|---|
| 1 | La tâche planifiée a été supprimée, désactivée ou n’a jamais été déplacée après une migration de serveur ou une mise à niveau | Rien dans le journal de renouvellement depuis des semaines |
| 2 | Le client est trop ancien, ou son compte ou son accès a disparu | Des erreurs dans le journal de renouvellement à propos du compte ou de la requête |
| 3 | L’étape de validation ne fonctionne plus : un pare-feu modifié, une redirection qui bloque le chemin utilisé par le défi, un enregistrement DNS ou un accès API qui a été changé | Une erreur « challenge failed » ou « unauthorized » |
| 3 | Trop de requêtes échouées ou répétées ont atteint la limite de débit de l’autorité | Un message de limite de débit ; les renouvellements échouent jusqu’à la fin de la limite |
| 4 | Le fichier n’a pas pu être écrit, ou un script qui le copie a échoué | Le nouveau fichier existe dans un dossier et pas dans un autre |
| 5 | Le serveur n’a jamais été rechargé, ou il lit un autre fichier que celui que le client met à jour | Le fichier affiche une nouvelle date, le navigateur en affiche une ancienne |
| 6 | Le certificat est présenté par une autre couche : un répartiteur de charge, un CDN, un serveur de messagerie, un autre port, un autre hôte virtuel | Une adresse est renouvelée, une autre non |
Les forums et les guides d’hébergement décrivent tous ces cas. Les histoires les plus fréquentes sont une tâche disparue après une modification, et un certificat renouvelé alors qu’un serveur a continué à servir l’ancienne copie.
Trouver le maillon cassé
Travaillez en partant de la fin, car c’est ce que voient les visiteurs.
Ce qui est servi
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject
Cette commande affiche les dates de début et de fin du certificat que le serveur présente sur cette adresse. Si la date de fin est proche ou dépassée, le certificat n’est pas renouvelé là où cela compte. Lancez-la pour chaque nom et chaque port que vous utilisez, pas seulement le principal.
Ce qui est sur le disque
Avec Certbot, la liste des certificats et de leurs dates d’expiration s’obtient ainsi :
sudo certbot certificates
Si le fichier a une nouvelle date et que le serveur en montre une ancienne, le problème se situe à l’étape 5 ou 6 : le serveur ne s’est pas rechargé, ou il lit un autre fichier. Si le fichier lui-même est ancien, le problème se situe aux étapes 1 à 4.
La tâche s’exécute-t-elle ?
Sur un système qui utilise des minuteurs, systemctl list-timers liste les tâches planifiées. Cherchez celle du renouvellement et sa dernière exécution. Une configuration cron classique se trouve dans crontab -l et dans les fichiers sous /etc/cron.d/.
Le renouvellement fonctionne-t-il maintenant ?
sudo certbot renew --dry-run
Un essai à blanc parcourt les étapes sans rien remplacer. Une erreur ici est la même que celle qui a bloqué le vrai renouvellement, et elle nomme l’étape.
Note
Ces commandes supposent Certbot sur un serveur Linux. Les autres clients et panneaux d’hébergement ont leurs propres outils. L’ordre reste le même : ce qui est servi, ce qui est enregistré, si la tâche s’exécute, si le renouvellement fonctionne.
Corriger et prévenir
- Corrigez la cause, puis renouvelez une fois à la main pour ne pas attendre la prochaine exécution planifiée.
- Rechargez le serveur après chaque renouvellement. La plupart des clients peuvent lancer une commande après un renouvellement réussi. Sans cela, un fichier renouvelé peut rester inutilisé.
- Listez tous les endroits où vit un certificat. Le site web, le serveur de messagerie, l’hôte de l’API, l’hôte de préproduction, le répartiteur de charge. Chacun a besoin de son propre renouvellement et de sa propre vérification.
- Ne vous fiez pas au silence de la tâche. Une tâche qui échoue sans bruit ressemble à une tâche qui fonctionne. La seule preuve que le renouvellement a marché est la nouvelle date sur le certificat réellement servi.
- Gardez une alerte indépendante. Un avertissement venu de l’extérieur, bien avant la date de fin, ne dépend d’aucune étape de la chaîne.
Ce qu’apporte un moniteur
Un moniteur qui se connecte à votre adresse depuis l’extérieur lit le certificat que les visiteurs recevraient. C’est l’étape 6, la seule que vous ne pouvez pas simuler depuis l’intérieur du serveur, et elle détecte toutes les défaillances ci-dessus, quelle que soit l’étape en cause.
UptimeWire vérifie le certificat de chaque adresse https environ toutes les six heures et vous prévient par e-mail et par Telegram, dans le délai que vous avez choisi pour ce site web, de 1 à 60 jours avant son expiration. L’avertissement n’est envoyé qu’une fois. C’est un rappel pour que vous agissiez : UptimeWire ne renouvelle, n’installe ni ne répare les certificats, et il ne cherche pas pourquoi un renouvellement a échoué. Il vérifie le certificat de l’adresse que vous ajoutez ; les autres noms et ports ont donc besoin de leurs propres entrées.
Comme les certificats sont vérifiés environ toutes les six heures, un avertissement arrive quelques heures après le franchissement du seuil, pas à l’instant exact. Pour un certificat renouvelé automatiquement, un délai d’avertissement de 14 ou 30 jours sert de filet de sécurité : s’il se déclenche, l’automatisation a déjà manqué sa chance, et il vous reste du temps pour corriger avant que les visiteurs ne soient touchés. Consultez surveillance de l’expiration des certificats SSL pour la marche à suivre après l’arrivée d’un avertissement.
Liste de contrôle
- Quel certificat chaque adresse et chaque port servent-ils, et quand se termine-t-il ?
- La tâche de renouvellement est-elle planifiée, et quand s’est-elle exécutée pour la dernière fois ?
- Un essai à blanc réussit-il, ou quelle étape nomme-t-il ?
- Le serveur est-il rechargé après le renouvellement ?
- Chaque nom, sous-domaine et service qui présente un certificat est-il renouvelé ?
- Existe-t-il un avertissement venu de l’extérieur, réglé bien avant la date de fin ?