Inspecteur de certificat TLS

À quoi sert un certificat

Quand votre navigateur se connecte à https://example.com, quelque chose répond. Reste à savoir si ce quelque chose appartient bien à example.com. N’importe qui sur le réseau, entre vous et le site, aurait pu répondre à sa place.

Le serveur doit donc montrer patte blanche. Un certificat est un petit fichier qui contient une clé publique, la liste des noms d’hôte au nom desquels cette clé peut parler, une date de début, une date de fin et la signature d’une autorité de certification (AC) qui a vérifié qui contrôle ces noms. Le navigateur déroule sa liste. Le nom de la barre d’adresse doit figurer sur le certificat. La date du jour doit tomber entre les deux dates. La signature doit remonter à une autorité que l’appareil connaît déjà. Et le serveur doit prouver qu’il détient la clé privée correspondante. Il suffit qu’un seul de ces points manque pour que le visiteur voie l’avertissement plein écran.

Le chiffrement ne commence qu’une fois tout cela vérifié. Le cadenas signifie que le serveur a prouvé son identité et le chiffrement repose sur cette preuve.

Ce que l’inspecteur teste

Il se connecte deux fois au port 443. La première fois, il accepte tout, pour pouvoir lire le certificat quel que soit son état. La seconde fois, il vérifie tout par rapport à une liste standard de racines de confiance, comme le ferait un client strict.

Il demande ensuite les quatre formes de l’adresse (http et https, avec et sans www) et montre où chacune aboutit et si le site envoie un en-tête HSTS. Pour voir cette partie étape par étape, le suivi de redirections s’en charge.

Ça marche dans Chrome, ça échoue partout ailleurs

Les autorités ne signent pas votre certificat avec leur clé racine. Elles le signent avec un certificat intermédiaire, lui-même signé par la racine. Les appareils ne conservent que les racines, donc votre serveur doit envoyer l’intermédiaire avec son propre certificat. Les deux ensemble forment la chaîne.

Quand un serveur n’envoie que son propre certificat, Chrome et Edge sur ordinateur se montrent indulgents. Ils téléchargent souvent l’intermédiaire manquant ou réutilisent un intermédiaire vu sur un autre site. Firefox sur un profil neuf, les anciens téléphones Android, curl, les webhooks de paiement, les serveurs de messagerie et la plupart des bibliothèques de programmation ne vous feront pas cette faveur. C’est ainsi qu’on se retrouve avec un site parfait aux yeux de son propriétaire qui échoue pour un client d’API. L’inspecteur appelle cela Incomplete chain (chaîne incomplète) et le signale quand la vérification échoue et qu’un seul certificat a été envoyé.

Réparer les pannes courantes

• Expiré. Les certificats automatisés se renouvellent environ 30 jours avant la fin, donc si le vôtre a expiré, la tâche de renouvellement échoue depuis des semaines. Avec Certbot, lancez certbot renew --dry-run et lisez l’erreur. C’est souvent un enregistrement DNS qui a changé, un pare-feu qui ferme le port 80, ou une redirection qui avale /.well-known/acme-challenge/.
• Nom non couvert. Redemandez le certificat en listant tous les noms d’hôte : certbot -d example.com -d www.example.com. Un joker *.example.com couvre un seul niveau de sous-domaines. Il ne couvre pas example.com lui-même, ce qui piège beaucoup de monde.
• Chaîne incomplète. Faites pointer le serveur vers le fichier de chaîne complète. Dans nginx : ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;. Dans Apache 2.4.8 et plus, SSLCertificateFile accepte le même fichier.
• Autosigné. Remplacez-le par un certificat d’une autorité publique. Let’s Encrypt, ZeroSSL et Google Trust Services en offrent gratuitement.
• Ancien protocole. Activez TLS 1.2 et 1.3. Dans nginx : ssl_protocols TLSv1.2 TLSv1.3;

Vous pouvez voir la même chose depuis un terminal avec openssl s_client -connect example.com:443 -servername example.com.