« Votre connexion n'est pas privée » : lequel des cinq cas c'est, et quelle machine est fautive

Un seul écran d’avertissement rouge recouvre au moins cinq pannes sans rapport entre elles. C’est toute la difficulté avec « Votre connexion n’est pas privée » : la page qu’un utilisateur voit est identique, que votre certificat ait expiré la veille au soir, que son ordinateur portable pense être en 2019, ou que son employeur lise son trafic.

L’écran cache la seule chose qui permette de les distinguer, et elle se trouve derrière le lien Avancé : un code commençant par NET::ERR_CERT_. Tout ce qui est utile se trouve dans ce code, et presque aucun rapport de bug ne le mentionne.

Ce que fait réellement le navigateur

Avant l’envoi de toute requête, le navigateur vérifie le certificat présenté par le serveur. Trois de ces vérifications échouent assez souvent pour avoir chacune leur propre code d’erreur, et la liste des erreurs réseau de Chromium en donne une description en une ligne pour chacune.

ERR_CERT_COMMON_NAME_INVALID correspond, dans les mots de Chromium, au fait que « le serveur a répondu avec un certificat dont le nom commun ne correspondait pas au nom d’hôte ». Le certificat est réel et valide, mais pour un nom différent. Quelqu’un a atteint www.example.com alors que le certificat couvre example.com, ou une simple adresse IP, ou un hôte de préproduction jamais ajouté à la liste des noms.

ERR_CERT_DATE_INVALID est le cas le plus intéressant, et sa formulation mérite d’être lue deux fois : « le serveur a répondu avec un certificat qui, selon notre horloge, semble soit ne pas encore être valide, soit avoir expiré ».

Selon notre horloge. Le navigateur compare les dates du certificat à l’horloge de la machine sur laquelle il tourne. Un certificat parfaitement valide échouera à ce contrôle sur un appareil dont l’horloge est fausse, et un appareil dont l’horloge est fausse n’a rien d’exceptionnel : un ordinateur portable ressorti d’un tiroir après des mois, un téléphone qui a perdu sa synchronisation horaire, une machine virtuelle relancée depuis un instantané, un poste de travail dont quelqu’un a réglé la date à la main. La même page se charge chez vous et se bloque chez eux, et rien dans l’erreur n’indique de quelle horloge vient la faute.

ERR_CERT_AUTHORITY_INVALID signifie que « le serveur a répondu avec un certificat signé par une autorité à laquelle nous ne faisons pas confiance ». Trois situations très différentes produisent cette erreur, et il vaut la peine de les distinguer, ce que nous faisons plus bas.

ERR_CERT_REVOKED signifie que « le serveur a répondu avec un certificat qui a été révoqué ». Quelqu’un l’a retiré avant son expiration, généralement parce qu’une clé a fuité. Celui-ci est véritablement de votre fait, et véritablement urgent.

Les numéros sont stables eux aussi, si vous finissez par lire des journaux plutôt que des écrans : -200, -201, -202 et -206 respectivement.

Trois des cinq cas ne sont pas votre serveur

C’est la partie qui transforme une erreur de certificat en un problème de rapport de bug plutôt qu’en un problème d’exploitation.

L’horloge. Déjà vu plus haut. Votre certificat est bon. Leur appareil n’est simplement pas d’accord sur la date du jour. Vous ne pouvez pas reproduire cela, vous ne pouvez pas le corriger de votre côté, et aucun redéploiement, aussi nombreux soient-ils, n’y changera rien.

Le réseau lit leur trafic. Un proxy d’entreprise, certains antivirus et la plupart des portails captifs de wifi public fonctionnent en présentant leur propre certificat pour chaque site et en le signant avec une racine qu’ils installent sur la machine. Quand cela fonctionne, l’utilisateur ne voit rien. Quand la racine n’est pas installée, ou que l’appareil n’appartient pas à l’entreprise, chaque site sur ce réseau affiche ERR_CERT_AUTHORITY_INVALID. L’indice, c’est que le problème suit le réseau plutôt que le site : la même personne en données mobiles n’a aucun souci.

Le certificat intermédiaire manquant. Un certificat est validé via une chaîne de confiance : le vôtre est signé par un intermédiaire, lui-même signé par une racine que le navigateur reconnaît déjà. Votre serveur est censé envoyer l’intermédiaire en même temps que son propre certificat. S’il ne le fait pas, certains visiteurs s’en sortent quand même, parce que leur navigateur détient déjà cet intermédiaire par ailleurs ou va le chercher à la volée, et d’autres visiteurs reçoivent ERR_CERT_AUTHORITY_INVALID.

Ce dernier cas mérite une phrase à lui seul, car c’est le problème de configuration le plus mal diagnostiqué du web : une chaîne à qui il manque son intermédiaire fonctionne sur la machine de la personne qui l’a mise en place, et échoue pour une fraction d’inconnus. C’est réellement la faute de votre serveur, et votre propre navigateur est le pire instrument possible pour le découvrir.

Faible

Un client dit que le site n'est pas sécurisé. Vérifié dans Chrome et Safari ici, le cadenas est bon. On lui a dit de vider son cache.

Meilleur

NET::ERR_CERT_AUTHORITY_INVALID, uniquement sur le wifi du bureau, fonctionne en données mobiles. Même page ici, aucun souci. Proxy ou intermédiaire manquant, chaîne vérifiée depuis l'extérieur avant d'accuser leur réseau.

Les distinguer en une minute

Le code réduit le champ à l’une de trois causes. Trois questions suffisent à conclure.

Quelle heure leur appareil pense-t-il qu’il est ? Demandez l’heure, pas la date. Pour certaines choses, les minutes comptent ; ici, c’est plutôt le cas d’un décalage d’un an, ce qui saute aux yeux une fois qu’on regarde. Si l’horloge est fausse, ERR_CERT_DATE_INVALID s’explique et il n’y a plus rien d’autre à investiguer. Une horloge d’appareil décalée de plusieurs mois en silence est aussi la raison pour laquelle « ça a cassé vers trois heures » peut vous envoyer vers la mauvaise heure dans vos journaux, ce qui vaut la peine d’être su au-delà de cette seule erreur. Le guide du rapport de bug place l’environnement dans son modèle pour la même raison.

Est-ce que ça suit le réseau ou le site ? Une seule question : est-ce que ça arrive en données mobiles ? Un problème de certificat qui disparaît quand l’utilisateur quitte le wifi signifie que le réseau présente son propre certificat, et la correction se fait de leur côté ou du côté de leur service informatique.

Est-ce que ça arrive à quelqu’un en dehors de votre bureau ? Vérifiez la chaîne depuis une machine qui n’a jamais visité votre site, ce qu’est justement un vérificateur SSL externe : il se connecte à zéro et rapporte ce que votre serveur a réellement envoyé, plutôt que ce que votre navigateur a appris à compléter de lui-même. S’il signale un intermédiaire manquant, c’est votre déploiement, et c’est probablement cassé pour une partie des visiteurs depuis le dernier renouvellement de certificat.

Le renouvellement à moitié réussi

Une configuration qu’il vaut la peine de connaître, car elle produit la version la plus déroutante de ce problème.

Les certificats sont désormais renouvelés automatiquement, et un renouvellement qui installe le nouveau certificat mais pas le nouvel intermédiaire, ou qui recharge un processus mais pas un autre, laisse un serveur correct sous certains angles et fautif sous d’autres. Les utilisateurs derrière un répartiteur de charge tombent au hasard sur le nœud corrigé ou sur l’ancien. La moitié des signalements disent que c’est cassé, l’autre moitié dit que tout va bien, les deux moitiés disent la vérité, et on passe une heure à chercher un schéma du côté des utilisateurs alors que le schéma se trouve du côté des serveurs.

La solution consiste à arrêter de tester depuis un navigateur qui vous aide peut-être sans que vous le sachiez. Testez le point de terminaison, depuis l’extérieur, à répétition.

Ce qu’un rapporteur peut réellement vous envoyer

Voici la limite honnête, et elle s’applique à nous autant qu’à quiconque. Un avertissement de certificat signifie que la page ne s’est jamais chargée. Il n’y a ni console, ni journal réseau, ni rien qu’un outil de capture puisse enregistrer, parce que le navigateur a refusé avant même que votre site ait pu s’exécuter. Ce sur quoi vous comptez d’habitude pour voir une panne à travers les yeux de quelqu’un d’autre n’est pas disponible pour celle-ci.

Tout revient donc à poser des questions, et à demander les trois bonnes choses :

• Le code, celui qui se trouve derrière Avancé, en entier. NET::ERR_CERT_AUTHORITY_INVALID, pas « un avertissement de sécurité ».
• La date et l’heure sur leur appareil, lues directement sur leur propre horloge.
• Le réseau, et si les données mobiles se comportent différemment.

Trois réponses, et la cause est généralement établie avant même que quiconque ait regardé un serveur. C’est un meilleur taux de réussite que ce qu’offrent la plupart des erreurs, et il n’est disponible que parce que le navigateur a déjà fait le diagnostic et l’a placé derrière un lien que personne ne clique.

Une chose à ne pas leur dire : passer outre l’avertissement. C’est le réflexe, le bouton est juste là, et en cas d’interception réelle, cela livre le trafic à celui qui l’intercepte. Si la cause est l’horloge, la corriger prend les mêmes trente secondes et laisse le contrôle fonctionner pour le prochain site.

Ce qu’il faut en retenir

L’écran rouge est une catégorie, pas un diagnostic. Le code sous Avancé est le diagnostic, et il est fourni gratuitement à chaque occurrence.

Trois des causes résident sur la machine de l’utilisateur ou sur son réseau, si bien que les reproduire sur la vôtre est impossible par construction, et celle qui est réellement la vôtre, l’intermédiaire manquant, est celle que votre propre navigateur a le moins de chances de vous montrer. Ces deux constats vont dans le même sens : pour les erreurs de certificat, demandez le code puis testez depuis l’extérieur, dans cet ordre.

La liste de ces erreurs tenue par Chromium, avec la définition en une ligne de chacune, se trouve dans net_error_list.h. C’est la source à partir de laquelle les pages d’erreur sont générées, et elle tranche les débats plus vite qu’aucun article ne le pourrait.