Problème
Le site que vous exploitez affiche à chaque visiteur un avertissement de sécurité en pleine page, et la plupart des navigateurs demandent une confirmation avant d'aller plus loin. Rien n'a été modifié, rien n'a prévenu : le certificat est simplement arrivé à échéance pendant la nuit. Cette fiche s'adresse à celui qui administre le serveur et qui doit réparer. Le visiteur qui rencontre l'alerte sur le site d'un tiers, lui, cherche autre chose, et la fiche sur l'avertissement de certificat côté navigateur traite son cas, y compris les fausses alertes dues à l'horloge du poste ou à un antivirus qui inspecte le trafic chiffré.
Solution recommandée
Identifier laquelle des trois causes est en jeu avant de toucher au serveur, parce qu'elles ne se réparent pas de la même façon : le certificat a réellement expiré et personne ne l'a renouvelé, le renouvellement automatique existait mais a échoué en silence, ou la chaîne de certification est incomplète et l'alerte n'apparaît que sur certains appareils. Émettre un nouveau certificat rétablit le service dans les minutes qui suivent, mais ce n'est qu'un dépannage : la réparation véritable consiste à rendre le renouvellement automatique et à le voir réussir, en simulation, avant la prochaine échéance. Un certificat renouvelé à la main réexpirera, et la même panne reviendra à la fin de sa validité.
Matériel & outils
Un accès administrateur au serveur qui héberge le site, le client d'autorité de certification installé dessus, le plus souvent certbot pour Let's Encrypt, le gestionnaire de services du système pour vérifier la tâche planifiée de renouvellement, la commande openssl pour lire une date d'expiration et une chaîne de certification, les journaux du serveur web et ceux du client de certificat, un navigateur et un vérificateur de certificat en ligne pour contrôler le résultat depuis l'extérieur
Étapes
1. Constatez la panne depuis l'extérieur avant tout, pas depuis le serveur : ouvrez le site depuis un poste et depuis un téléphone en réseau mobile. Cliquez sur l'avertissement du navigateur pour afficher le détail du certificat, qui nomme la cause en une ligne : date de validité dépassée, autorité non reconnue, ou nom du site qui ne correspond pas au certificat présenté 2. Lisez la date d'expiration réelle depuis n'importe quelle machine, sans toucher au serveur, avec openssl s_client -connect votre-domaine.fr:443 -servername votre-domaine.fr, dont la sortie passée à openssl x509 -noout -dates donne la date de début et la date de fin. Comparez avec la date du jour : c'est ce qui sépare une vraie expiration d'un problème de chaîne 3. Vérifiez l'heure du serveur au passage, avec date ou timedatectl. Une horloge très décalée fait rejeter un certificat parfaitement valide, et c'est la seule cause qui se répare sans toucher au certificat 4. Première cause, le certificat a réellement expiré et rien ne le renouvelait. C'est le cas le plus simple : renouvelez immédiatement pour rétablir le service, puis passez à l'automatisation, qui est la vraie réparation. Avec certbot, la commande certbot renew renouvelle tout ce qui approche de l'échéance ou l'a dépassée ; certbot certificates liste au préalable les certificats gérés par la machine, leurs domaines et leurs dates, et vous dira aussi si le certificat servi n'est pas géré par cet outil du tout 5. Deuxième cause, le renouvellement automatique existait et a échoué en silence. Le signe : le client de certificat est installé et un certificat précédent avait bien été renouvelé sans intervention. Cherchez alors d'abord si la tâche planifiée tourne encore. Sous un système à systemd, systemctl list-timers affiche les minuteries actives et leur dernier déclenchement ; l'absence de la minuterie de renouvellement, ou un dernier déclenchement très ancien, désigne la cause. Vérifiez également que le service associé n'est pas en échec avec systemctl status suivi de son nom 6. Si la tâche tourne bien, c'est la validation qui ne passe plus. Lisez les journaux du client, sous le répertoire /var/log/letsencrypt pour certbot, en regardant la tentative la plus récente : le message y est explicite. Deux causes dominent. La validation par requête web échoue parce que la configuration du serveur web a changé depuis l'installation, et que le chemin réservé à la vérification n'est plus servi, par exemple parce qu'une redirection systématique vers la version chiffrée du site a été ajoutée, parce qu'une authentification protège désormais tout le site, ou parce que la racine des fichiers a été déplacée. La validation par enregistrement DNS échoue parce que le jeton d'accès à l'hébergeur de la zone a expiré ou que la zone a été déplacée 7. Réparez la validation avant de réessayer, sinon la même erreur se reproduira. Pour la validation par requête web, assurez-vous que le chemin de vérification, situé sous la racine du site dans un répertoire bien connu réservé à cet usage, reste accessible en clair et sans authentification, avant toute redirection. Pour la validation par DNS, renouvelez les identifiants auprès de l'hébergeur de la zone et vérifiez les droits du fichier qui les contient 8. Troisième cause, la chaîne de certification est incomplète. C'est la plus déroutante, parce que le site fonctionne chez vous et pas chez vos clients : un navigateur de bureau récent complète souvent la chaîne manquante de lui-même, alors qu'un téléphone, un client de messagerie ou un appel entre applications la refusent. Le signe : la date d'expiration est bonne, l'erreur parle d'autorité inconnue ou de chaîne incomplète, et elle n'apparaît que sur une partie des appareils 9. Vérifiez la chaîne depuis l'extérieur avec openssl s_client -connect votre-domaine.fr:443 -servername votre-domaine.fr, dont la sortie énumère les certificats présentés par le serveur. Le serveur doit envoyer votre certificat et les certificats intermédiaires qui le relient à l'autorité, pas seulement le vôtre. Un vérificateur de certificat en ligne dit la même chose de façon plus lisible, et teste depuis un réseau qui n'est pas le vôtre, ce qui est précisément l'intérêt 10. Corrigez en faisant pointer le serveur web vers le fichier qui contient la chaîne complète, et non vers le seul certificat. Avec certbot, ces deux fichiers coexistent dans le répertoire du domaine et leurs noms ne diffèrent que d'un mot : c'est la confusion la plus fréquente de toute cette panne. Rechargez ensuite la configuration du serveur web plutôt que de le redémarrer, par exemple avec systemctl reload suivi du nom du service, pour ne pas couper les connexions en cours 11. Vérifiez que la réparation est visible de l'extérieur, et pas seulement sur le serveur. Rechargez le site depuis un navigateur en vidant son cache, puis depuis un téléphone en réseau mobile, et relisez la date d'expiration avec openssl : elle doit être repoussée. Un certificat renouvelé mais non rechargé par le serveur web reste invisible, et c'est l'erreur qui fait croire à un échec de renouvellement 12. Maintenant la vraie réparation : prouvez que le prochain renouvellement réussira, sans attendre l'échéance. Le client de certificat dispose pour cela d'un mode de simulation, qui rejoue toute la procédure sans consommer de quota ni remplacer le certificat en place. Avec certbot, c'est certbot renew --dry-run. Une simulation qui échoue annonce exactement la panne de dans trois mois ; une simulation réussie est la seule preuve acceptable. Un renouvellement automatique qu'on n'a jamais vu réussir n'est pas un renouvellement 13. Vérifiez aussi que le serveur web sera rechargé après le renouvellement, ce qui est un deuxième point de défaillance, distinct du premier. Un certificat renouvelé correctement mais jamais rechargé produit exactement la même alerte qu'un certificat non renouvelé. Les installations faites par paquet posent en général ce rechargement automatiquement, une installation faite à la main souvent non. En cas de doute, déclarez explicitement la commande de rechargement dans la configuration du client de certificat 14. Assurez-vous enfin que la tâche planifiée est bien activée au démarrage du serveur, et pas seulement lancée une fois à la main. Une machine redémarrée perd une tâche non activée, et personne ne s'en aperçoit avant la prochaine échéance 15. Posez une surveillance de l'échéance, car c'est exactement le type de panne qu'une supervision évite. Une sonde qui interroge le certificat servi par le site depuis l'extérieur et alerte trente jours avant l'expiration transforme une coupure visible de tous en une tâche de maintenance tranquille. Surveillez depuis l'extérieur plutôt que depuis le serveur : c'est ce que voient vos visiteurs, et cela couvre aussi le cas de la chaîne incomplète 16. Recensez pour terminer tous les noms servis par la machine, y compris les sous-domaines de préproduction, d'administration ou de messagerie, et vérifiez qu'ils sont tous couverts et tous renouvelés automatiquement. Le certificat oublié est presque toujours celui qui n'était pas sur la page d'accueil
Coût estimé
0 € pour un certificat émis par une autorité gratuite comme Let's Encrypt, cas de la grande majorité des sites, hors temps passé. Un certificat acheté auprès d'une autorité commerciale coûte de quelques dizaines à quelques centaines d'euros par an selon le type et la couverture des sous-domaines, et se renouvelle plus difficilement de façon automatique
Limites
Ne traite pas le cas où le certificat est servi par un intermédiaire placé devant le serveur, répartiteur de charge, service de diffusion de contenu ou passerelle d'hébergeur : la réparation se fait alors dans l'interface de cet intermédiaire, et le certificat présent sur le serveur d'origine n'est pas celui que voient les visiteurs. Ne couvre pas les certificats internes émis par une autorité d'entreprise, dont la confiance dépend du déploiement de l'autorité racine sur les postes. Ne couvre pas un nom de domaine expiré ou dont la zone ne répond plus, qui empêche toute émission et se reconnaît à ce que le site devient injoignable au lieu d'être averti. Ne couvre pas les certificats de messagerie ni ceux utilisés pour signer du code, qui suivent d'autres procédures.
Erreurs fréquentes
Renouveler à la main, constater que le site remarche, et refermer le sujet : la panne est alors programmée pour revenir à la fin de la nouvelle période de validité. Renouveler le certificat sans recharger le serveur web, puis conclure que le renouvellement a échoué alors qu'il a parfaitement fonctionné. Faire pointer la configuration vers le certificat seul au lieu du fichier contenant la chaîne complète, ce qui donne un site qui marche sur le poste de l'administrateur et casse sur les téléphones des clients. Vérifier la réparation uniquement depuis le serveur, ou depuis un navigateur qui a gardé l'ancienne réponse en cache. Multiplier les tentatives de renouvellement quand la validation échoue, jusqu'à se heurter à la limite d'émission de l'autorité et devoir attendre plusieurs jours, alors que le mode de simulation permet d'essayer sans rien consommer. Considérer qu'un renouvellement automatique installé un jour fonctionne toujours, sans l'avoir vu réussir une seule fois.
Alternatives
Déléguer le certificat à un intermédiaire placé devant le site, service de diffusion de contenu ou répartiteur de charge géré par l'hébergeur, qui l'émet et le renouvelle lui-même : le sujet disparaît de vos serveurs, au prix d'une dépendance supplémentaire. Utiliser un serveur web qui obtient et renouvelle les certificats de lui-même, sans client séparé ni tâche planifiée, ce qui supprime le point de défaillance le plus courant de cette panne. Sur un parc de plusieurs machines, centraliser l'émission sur un point unique qui distribue ensuite les certificats, plutôt que de laisser chaque serveur se débrouiller. Et dans tous les cas, garder une surveillance externe de l'échéance : elle reste utile même quand le renouvellement est délégué, parce qu'elle vérifie ce que voient les visiteurs et non ce que croit le serveur.
Besoin d'un accompagnement personnalisé ?
Cours 1:1, conseil de solution, ou simplement une question précise - contacte-moi directement.