Ce qu'inspecte le vérificateur SSL
L'outil ouvre une connexion TLS sur le port 443 du nom d'hôte saisi, envoie ce nom dans l'extension SNI comme le ferait un navigateur, et relève le certificat renvoyé par le serveur. Il affiche l'émetteur, le sujet, la période de validité, les noms alternatifs du sujet (SAN), la version de TLS négociée et si la chaîne se valide auprès d'un magasin de confiance standard. Il lit ensuite la réponse HTTP à la recherche d'un en-tête Strict-Transport-Security.
Dates de validité et renouvellement
Un certificat n'est valide qu'entre ses horodatages not-before et not-after. Les certificats expirés restent l'une des causes les plus fréquentes de pannes évitables, généralement parce qu'un renouvellement automatisé a échoué en silence. Le résultat affiche les jours restants pour qu'un certificat proche de l'expiration saute aux yeux.
La durée de vie maximale des certificats publiquement reconnus ne cesse de raccourcir. La limite du secteur est passée de 398 à 200 jours en mars 2026 et doit encore baisser dans les années qui suivent. À ce rythme, le renouvellement manuel n'est plus réaliste ; l'automatisation via ACME ou les certificats managés de votre fournisseur est la réponse pratique, et la supervision, le filet de sécurité.
Noms d'hôtes : les noms alternatifs du sujet
Les navigateurs comparent le nom d'hôte demandé aux noms alternatifs du sujet inscrits dans le certificat et ignorent l'ancien champ common name. Un certificat pour example.com ne couvre pas www.example.com, sauf si les deux sont listés. Un wildcard comme *.example.com couvre une seule étiquette : il correspond à shop.example.com, mais ni à example.com lui-même ni à a.b.example.com. Une discordance de nom produit le même type d'avertissement du navigateur qu'un certificat expiré.
Les erreurs de confiance et leurs causes
L'échec de confiance le plus fréquent est une chaîne incomplète : le serveur envoie son propre certificat, mais pas l'intermédiaire qui le relie à une racine reconnue. Les navigateurs de bureau masquent souvent le problème en récupérant l'intermédiaire ou en le gardant en cache, alors que les clients d'API, les applications mobiles et les outils en ligne de commande échouent. Autres causes : certificats autosignés, certificats d'une autorité privée, expiration et discordance de nom d'hôte. L'outil rapporte l'erreur de validation reçue pour que vous sachiez laquelle s'applique.
Version du protocole et HSTS
TLS 1.3 et TLS 1.2 sont les versions d'usage courant. TLS 1.0 et 1.1 sont obsolètes et refusés par les navigateurs actuels. L'outil indique la version négociée sur sa propre connexion, qui reflète la meilleure version prise en charge par les deux parties, pas la liste complète de ce que le serveur accepte.
HSTS est un en-tête de réponse qui demande aux navigateurs d'utiliser HTTPS pour le domaine pendant une durée donnée, ce qui empêche les attaques par rétrogradation lors des visites suivantes. Sa présence est un bon signe de configuration réfléchie. Soyez prudent avec includeSubDomains et preload : ils engagent tous les sous-domaines à HTTPS et sont longs à annuler.
Ce qu'un certificat valide ne signifie pas
Un certificat reconnu montre que la connexion est chiffrée et que l'autorité de certification a vérifié le contrôle du nom de domaine. Il ne dit rien de qui exploite le site, de l'honnêteté du contenu ni de la bonne maintenance du serveur. Les sites d'hameçonnage ont couramment des certificats valides. La vérification ne porte en outre que sur le point de terminaison atteint ; d'autres ports, d'autres sous-domaines et d'autres serveurs derrière un répartiteur de charge peuvent être configurés différemment.