Ce que vérifie cet outil
Chaque connexion HTTPS repose sur un certificat auquel le navigateur fait confiance, qui n'a pas expiré, et qui couvre réellement le nom d'hôte visité. Si l'une de ces trois conditions échoue, votre site affiche un avertissement plein écran dans le navigateur — pas une petite icône, mais un interstitiel que la plupart des visiteurs ne cliqueront pas pour ignorer. Ce vérificateur ouvre une véritable connexion TLS vers le domaine saisi, exactement la même poignée de main qu'effectue un navigateur, et récupère l'émetteur, la période de validité, la version du protocole, et chaque nom d'hôte couvert par le certificat (ses Subject Alternative Names, ou entrées SAN).
Pourquoi l'expiration surprend souvent
Les certificats émis par des autorités automatisées gratuites comme Let's Encrypt sont valides 90 jours, et non plus les durées de vie d'un an ou plus qu'avaient les certificats autrefois. C'est bon pour la sécurité (des identifiants à durée de vie plus courte limitent les dégâts en cas de fuite), mais cela signifie que le renouvellement doit être automatisé, car une personne chargée de s'en souvenir tous les 90 jours finit toujours par l'oublier. La plupart des configurations utilisent certbot ou le renouvellement intégré d'une plateforme d'hébergement — cet outil existe pour les moments où cette automatisation tombe en panne silencieusement : une tâche cron qui s'est arrêtée après une migration de serveur, une étape de validation DNS qui a commencé à échouer après un changement de registrar, ou un hook de renouvellement qui n'a jamais redémarré le serveur web avec le nouveau certificat.
Le seuil de 30 jours utilisé ici n'est pas arbitraire — il reflète la fenêtre que la plupart des outils de renouvellement automatique utilisent pour leur première tentative, si bien qu'un avertissement à 30 jours signifie « votre automatisation aurait déjà dû renouveler ce certificat, allez comprendre pourquoi ce n'est pas le cas », pas « commencez à vous inquiéter ».
Entrées SAN : l'incohérence que personne ne pense à vérifier
Un certificat pour example.com seul ne couvre pas silencieusement www.example.com — les navigateurs les traitent comme des noms d'hôte différents et vérifient explicitement la liste SAN. C'est une faille courante après une refonte : le domaine principal reçoit un certificat tout neuf, quelqu'un oublie que www recevait encore du trafic direct (un ancien favori, un lien codé en dur chez un partenaire), et ces visiteurs reçoivent une erreur de certificat non correspondant alors que tous ceux qui testent example.com ne voient aucun problème. Vérifier la liste SAN ici révèle chaque nom d'hôte réellement couvert, pour que vous puissiez la comparer à tous les noms d'hôte que vous attendez de servir.
Certificats auto-signés et non reconnus
Un certificat auto-signé — un certificat qu'un serveur génère et signe lui-même plutôt que de l'obtenir auprès d'une autorité de certification — fera apparaître la connexion comme non reconnue dans ce vérificateur, ce qui est distinct d'un problème d'expiration. C'est tout à fait normal pour un panneau d'administration interne ou un environnement de développement local, et totalement inapproprié pour tout ce qui est public : les navigateurs ne peuvent pas vérifier l'authenticité d'un certificat auto-signé, donc chaque visiteur voit un interstitiel de sécurité complet, quelle que soit la date récente à laquelle il a été émis.
Un exemple concret
Un site derrière un CDN a souvent deux certificats distincts en jeu : celui que le CDN présente aux visiteurs, et celui que le serveur d'origine présente au CDN. Cet outil vérifie celui qui termine réellement la connexion pour le domaine saisi — généralement celui du CDN — ce qui correspond exactement à ce que voit le navigateur d'un visiteur. Si votre certificat d'origine expire mais pas celui du CDN, cet outil affichera correctement l'absence de problème, car de l'extérieur, il n'y en a effectivement pas encore.