Problème
Le certificat a expiré un week-end : remettre le site en ligne
Le site n’est pas cassé. Il est refusé par le navigateur parce que son certificat n’est plus valide — et un certificat se réémet en quelques minutes, y compris un dimanche.
Relancez le renouvellement automatique sur le serveur, puis rechargez le serveur web : c’est l’étape que tout le monde oublie. Si vous n’avez pas la main sur le serveur, réémettez depuis le panneau de l’hébergeur. Et si vous n’avez ni l’un ni l’autre, passez le domaine derrière un proxy qui fournit son propre certificat — c’est le seul contournement qui tienne en dix minutes un jour férié.
À faire tout de suite
Quatre gestes. Le premier évite de réparer la mauvaise panne : trois erreurs différentes affichent le même écran.
Lisez le code d’erreur, pas le titre
1 minLe titre de l’écran d’avertissement est le même pour toutes les causes. Le code sous le message, lui, nomme la panne. « DATE_INVALID » : le certificat est expiré, ou pas encore valide. « COMMON_NAME_INVALID » : il est valide mais ne couvre pas ce nom-là. « AUTHORITY_INVALID » : la chaîne est incomplète ou l’autorité n’est pas reconnue. Trois codes, trois réparations différentes.
Relancez le renouvellement, puis rechargez le serveur
5 minSur un serveur que vous administrez, forcez le renouvellement avec votre client ACME, puis rechargez Nginx, Apache ou Caddy. Le piège est là : un certificat renouvelé sur le disque mais pas rechargé ne change rien pour le visiteur, le serveur garde l’ancien en mémoire. C’est la moitié des « je l’ai renouvelé et ça ne marche toujours pas ».
Si le renouvellement échoue, lisez l’erreur de la vérification
10 minL’autorité de certification doit vérifier que vous contrôlez le domaine avant de signer. Deux causes reviennent tout le temps : le domaine ne pointe plus vers ce serveur — quelqu’un a changé un enregistrement DNS — ou une règle ajoutée depuis intercepte le chemin « /.well-known/acme-challenge/ » et répond une erreur à la place du fichier de vérification. Testez ce chemin à la main avant de toucher au reste.
Contrôlez depuis l’extérieur, sur les deux noms
3 minVotre navigateur peut accepter un certificat qu’un autre refusera, parce qu’il a gardé la chaîne intermédiaire en mémoire d’une visite précédente. Vérifiez depuis l’extérieur, sur le domaine nu et sur le www. Un certificat qui ne couvre que l’un des deux casse pour la moitié des visiteurs.
L’écran que voit votre client, décodé
Il vous enverra une capture de ceci, souvent sans le code. Demandez-lui de déplier le bas de l’écran : c’est la seule ligne qui apprend quelque chose.
Votre connexion n’est pas privée
Suit un paragraphe d’avertissement, puis un bouton replié en bas de l’écran.
NET::ERR_CERT_DATE_INVALID
Paramètres avancés
- Le titre est identique pour toutes les causes. Il ne vous apprend rien : ne cherchez pas la panne là, et n’en tirez surtout pas la conclusion que le site est piraté.
- Le code, lui, nomme la panne. « DATE_INVALID » veut dire expiré — ou pas encore valide, ce qui arrive quand l’horloge du serveur est fausse : vérifiez l’heure avant de tout réémettre.
- Ce bouton déplie un lien « continuer vers le site ». C’est ce que votre client va faire, et il croira que le problème est réglé. Il ne l’est pas : chaque visiteur voit le même écran, et les moteurs de recherche aussi.
Quel geste, selon ce que vous avez sous la main
Un samedi soir, la question n’est pas « quelle est la meilleure solution » mais « laquelle m’est accessible maintenant ». Les trois branches mènent au même résultat, avec des accès différents.
Avez-vous encore accès au serveur qui sert le site ?
- Oui, en ligne de commande
Forcez le renouvellement, puis rechargez le serveur web.
Dans cet ordre, et les deux. Un certificat renouvelé sur le disque et pas rechargé ne change rien pour le visiteur.
- Non, mais j’ai le panneau de l’hébergeur
Réémettez depuis l’interface, puis forcez le rechargement.
Chez la plupart des hébergeurs mutualisés, c’est un bouton et deux minutes. Vérifiez ensuite que le certificat réémis couvre le domaine nu et le www, pas seulement celui que vous avez saisi.
- Ni l’un ni l’autre, personne ne répond
Passez le domaine derrière un proxy qui fournit son propre certificat.
Vous changez les serveurs de noms du domaine chez le registrar, le proxy émet son certificat et sert le site en HTTPS. Vous avez besoin de l’accès au registrar, pas au serveur. Comptez le temps que les serveurs de noms soient repris partout.
Ce que vous écrivez au client, un samedi
Le client a vu « votre connexion n’est pas privée » et il pense à un piratage. La première phrase doit démonter cette idée-là, pas expliquer ce qu’est une autorité de certification.
Objet : Site momentanément inaccessible — remise en service en cours
Bonjour,
Le site affiche un avertissement de sécurité depuis [heure]. Il ne s’agit pas d’un piratage ni d’une perte de données : le certificat qui chiffre les échanges entre les visiteurs et le site est arrivé à échéance, et le navigateur refuse d’afficher la page tant qu’il n’est pas renouvelé.
Je procède à la réémission. Comptez [délai] avant que l’avertissement disparaisse pour tout le monde ; certains navigateurs gardent quelques minutes de retard.
Rien à faire de votre côté, et rien à annoncer à vos clients : les commandes, les formulaires et les données ne sont pas touchés.
Je vous écris dès que le site est de nouveau normal.
Le mot à ne pas employer : « sécurité ». Il transforme une panne technique en incident, et vous passerez la semaine à rassurer. « Le certificat est arrivé à échéance » dit la même chose et ne déclenche rien.
Pourquoi c’est arrivé
Un certificat n’expire jamais par surprise : sa date de fin est connue le jour de son émission. Ce qui a expiré, c’est l’automatisme qui devait le remplacer.
Let’s Encrypt délivre des certificats valables 90 jours et recommande de les renouveler tous les 60 jours. Cette marge de trente jours existe précisément pour absorber une panne de renouvellement. Quand un certificat expire vraiment, c’est que le renouvellement a échoué en silence pendant des semaines.
Et depuis le 4 juin 2025, Let’s Encrypt n’envoie plus de courriel d’expiration. L’annonce de janvier 2025 le dit sans détour : le service coûtait cher, obligeait à conserver des millions d’adresses, et la plupart des abonnés ont désormais une automatisation fiable. Le filet qui rattrapait ces pannes a été retiré — surveiller l’échéance est maintenant à la charge de chacun.
Cette surveillance va compter de plus en plus. Le CA/Browser Forum a adopté (scrutin SC-081v3) un calendrier de réduction de la durée maximale d’un certificat public, de 398 jours à 47 jours, par paliers échelonnés entre mars 2026 et mars 2029. Moins de durée, c’est plus de renouvellements, donc plus d’occasions qu’un automatisme casse sans qu’on le voie.
Comment l’éviter la prochaine fois
Surveillez la date de fin du certificat réellement servi au visiteur, depuis l’extérieur, et pas le fichier posé sur le serveur. Un certificat valide sur le disque et un certificat servi sur le port 443 sont deux choses différentes — c’est exactement l’écart que crée un serveur non rechargé.
Alertez à trente jours, pas à trois. Trente jours, c’est encore le temps de comprendre pourquoi l’automatisme a lâché et de le réparer un mardi. Trois jours, c’est le temps de bricoler un samedi.
Et vérifiez les deux noms à chaque livraison. Un certificat qui couvre « example.com » mais pas « www.example.com » ne déclenchera aucune alerte d’expiration, puisqu’il n’est pas expiré — il casse simplement pour tous ceux qui tapent le www.
Vérifiez le certificat servi, pas celui du disque
L’outil ouvre une connexion comme le ferait un visiteur, lit le certificat présenté, sa date de fin, les noms qu’il couvre et l’état de sa chaîne. Entrez le domaine du site.
Le certificat, relu plusieurs fois par jour.
DomainVigil rouvre la connexion comme un visiteur, sur tous les domaines de vos clients, et prévient quand une échéance approche ou qu’une chaîne s’est cassée. Cinq domaines gratuits, sans carte bancaire.
Cinq domaines gratuits, pour toujours. Sans carte bancaire.