Certificat SSL expiré : ce que voient vos visiteurs

Un certificat expiré ne produit pas un avertissement discret. Il produit une page entière, généralement rouge, expliquant que la connexion n'est pas privée et que des attaquants tentent peut-être de voler vos informations. La plupart des visiteurs ne la franchissent pas. Beaucoup en concluent que le site a été piraté.

Pendant ce temps, votre serveur va très bien. Il sert les pages exactement comme hier, il répond en quelques millisecondes, et aucun de vos journaux ne signale quoi que ce soit.

Le message exact vous dit lequel des quatre problèmes vous avez

Avant de toucher à quoi que ce soit, lisez le code d'erreur affiché sous le message. Les navigateurs le cachent derrière un lien « avancé », et c'est lui qui contient toute l'information.

Les deux premières lignes se corrigent en une commande. La troisième est la plus sournoise et mérite sa propre section. La quatrième n'est pas un problème de certificat du tout.

Pourquoi cela arrive à des sites qui fonctionnent

Le rappel est parti vers une adresse que personne ne lit. Les autorités de certification préviennent par email, à l'adresse saisie lors de l'émission : souvent une boîte générique, parfois un développeur parti depuis deux ans.

Le renouvellement automatique a échoué en silence. La tâche est programmée et elle sort en erreur. Rien ne tombe bruyamment : le certificat cesse simplement d'être remplacé. C'est la cause la plus fréquente sur les serveurs modernes, et elle a trois variantes classiques.

Le certificat a été renouvelé mais pas déployé. Un nouveau fichier existe sur le disque, daté d'aujourd'hui, parfaitement valide. Le serveur web garde l'ancien en mémoire, parce que personne ne l'a rechargé. Réellement exaspérant, et très courant.

Un sous-domaine a été oublié. Le certificat couvre exemple.com et www, mais pas le boutique. que vous avez ajouté en mars. Le site principal va bien, et une partie du trafic tombe sur un mur.

Ce que fait un visiteur devant cette page

Il ne lit pas le code d'erreur. Il voit un cadenas barré, un fond rouge, et une phrase qui parle de vol d'informations. Trois réactions se partagent l'essentiel : fermer l'onglet, revenir aux résultats de recherche et cliquer sur le suivant, ou écrire à quelqu'un pour signaler que votre site a été piraté.

Aucune de ces trois réactions n'est réparable après coup. C'est ce qui distingue cette panne d'une erreur serveur ordinaire : une page qui renvoie un code 500 ou 503 inquiète un visiteur, une page qui annonce une tentative de vol le fait fuir et lui laisse un souvenir.

Méfiez-vous des chiffres qui circulent sur la proportion de gens qui passent outre : ils viennent d'échantillons anciens et de contextes qui ne sont pas le vôtre. Ce qui est sûr, c'est que le bouton pour continuer est volontairement caché derrière deux clics, et que la conception de cette page vise exactement à ce que personne ne la franchisse.

La demi-journée qui coûte le plus cher

Le blocage apparaît à l'instant exact de l'expiration, souvent la nuit, souvent un week-end, parce que c'est là que les quatre-vingt-dix jours sont tombés. Le temps que quelqu'un s'en aperçoive le lundi matin, le site affiche un avertissement de sécurité à chaque visiteur depuis trente-six heures.

Personne ne vous appellera pendant ce temps : vos outils internes ne verront rien, et votre hébergeur non plus, puisque de son point de vue la machine répond parfaitement. C'est la panne qui ressemble le plus à une panne sans en être une, et c'est pourquoi elle relève du même réflexe que les quinze premières minutes d'un incident : regarder depuis l'extérieur avant de regarder le code.

Vérifier en trente secondes

Une seule commande donne la date d'expiration du certificat réellement présenté au public, ce qui n'est pas toujours celui qui traîne sur votre disque :

echo | openssl s_client -servername exemple.fr -connect exemple.fr:443 2>/dev/null \
  | openssl x509 -noout -dates -subject

notAfter donne l'échéance, subject et les noms alternatifs disent quels hôtes sont couverts. Répétez la commande pour chaque sous-domaine que vous servez : chacun est une question distincte.

Si vous n'avez pas de terminal sous la main, ou si vous voulez simplement le chiffre : notre lecteur de certificat fait la même chose depuis le navigateur, et vous donne la date, les hôtes couverts et l'état de la chaîne.

Le cas de la chaîne incomplète

C'est le piège qui fait perdre le plus de temps, parce qu'il ne se voit pas sur la machine de celui qui vérifie.

Un certificat n'est pas seul : il est signé par un intermédiaire, lui-même signé par une racine. Votre serveur doit servir le certificat et l'intermédiaire. S'il oublie le second, les navigateurs de bureau s'en sortent souvent, parce qu'ils ont mis l'intermédiaire en cache lors d'une visite précédente sur un autre site. Les mobiles, eux, refusent.

Résultat : le site marche parfaitement sur votre poste, et affiche un avertissement à une partie de vos visiteurs. Le test se fait depuis un téléphone en données mobiles, ou avec la commande ci-dessus depuis une machine qui n'a jamais visité le site.

Ce que la durée de vie courte a changé

Il y a dix ans, un certificat durait un an ou plus, et le rappel dans un agenda partagé faisait le travail. Les certificats gratuits d'aujourd'hui durent quatre-vingt-dix jours, et la tendance générale va vers des durées encore plus courtes, pour de bonnes raisons de sécurité.

Cela déplace complètement le problème. Un renouvellement annuel est un événement dont quelqu'un se souvient ; un renouvellement trimestriel est une routine automatique que personne ne regarde. La question n'est donc plus « qui pense à renouveler » mais « qui vérifie que l'automatisme fonctionne encore ».

C'est un renversement qui mérite d'être énoncé, parce qu'il rend inutiles deux réflexes anciens. Noter la date d'expiration dans un agenda ne sert plus à rien : elle change quatre fois par an. Faire confiance au journal du renouvellement non plus : les trois pannes classiques y laissent une trace que personne n'ouvre, et la troisième n'y laisse même pas d'erreur.

Reste une seule vérification qui garde du sens, et c'est celle qui regarde depuis l'extérieur.

Ce qui l'évite réellement

Surveiller la date d'expiration, pas la tâche de renouvellement. Une vérification qui lit le certificat présenté par votre serveur et compte les jours restants dit la vérité : elle voit le certificat qu'un visiteur recevrait, pas celui qui existe sur le disque. Les trois causes ci-dessus finissent toutes au même endroit, et cette mesure les attrape toutes les trois.

Alerter avec une vraie marge. Trente jours, puis sept, puis un. Trente jours suffisent à réparer calmement un renouvellement cassé ; un jour suffit à rattraper un déploiement qui n'a pas rechargé.

Vérifier chaque nom d'hôte que vous servez. Chaque sous-domaine est une question de certificat distincte, et celui qu'on oublie est toujours celui qui a été ajouté après.

Mettre une adresse humaine sur le certificat. Cela ne coûte rien et c'est la dernière ligne de défense quand tout le reste a été oublié.

Ce que ce n'est pas

Ce n'est pas un piratage, et le dire clairement à qui vous le signale évite une heure de panique inutile. Ce n'est pas une panne serveur : rien à redémarrer, rien à restaurer. Et ce n'est pas d'abord un problème de référencement.

Ce que HTTPS change vraiment pour les moteurs est plus modeste que l'urgence de cette page ne le laisse croire. La raison de réparer un certificat, c'est le visiteur qui voit du rouge, pas l'algorithme.