SSL Certificate Checker

À quoi sert ce SSL certificate checker

Ton panneau de contrôle peut jurer ses grands dieux qu'un certificate existe. Le navigateur, lui, s'en fiche. Il ne regarde que ce qui est réellement servi pour le nom exact que quelqu'un a tapé. Du coup un check live gagne sa place juste après les moments un peu chaotiques : un changement d'hébergeur, une modif DNS, un reverse proxy qui passe en prod, un CDN qui s'allume, un nouveau sous-domaine, un auto-renewal qui s'est peut-être déclenché ou pas. Le piège, c'est qu'une couche a l'air nickel pendant que celle d'en dessous sert encore un certificate périmé ou faux.

Ce que tu obtiens ici, c'est ce qui décide vraiment de ton prochain geste. La fenêtre de validité. Les jours restants. L'issuer, le subject, les noms SAN, et si les hostnames que tu attends sont réellement couverts. Il y a aussi un petit check de contexte HTTPS, histoire de savoir si le host répond seulement et si HSTS est apparu sur cette réponse échantillonnée. Pour le boulot profond sur le protocole TLS, la chain et les ciphers, lance un scanner externe dédié en deuxième passe. Je ne m'appuierais pas là-dessus pour ça.

Comment lire le résultat

• Days remaining, c'est ta marge. Combien de temps avant que ce truc expire et que quelqu'un se fasse réveiller en pleine nuit.
• Valid from et valid to sont la fenêtre que le serveur a renvoyée, début et fin.
• Issuer, c'est la certificate authority, ou le label de chaîne d'émission que le cert parsé expose.
• Subject porte des champs d'identité, mais voilà le truc : le matching de hostname moderne l'ignore largement et s'appuie sur les noms SAN à la place.
• SAN coverage montre quels hostnames le cert dit couvrir. Wildcards inclus, quand il y en a.

Le hostname coverage, là où se cachent pas mal d'erreurs SSL

Un cert peut être totalement valide et complètement faux pour le nom qu'un visiteur a ouvert. Ça arrive tout le temps. Le domaine apex est couvert mais pas www. Un sous-domaine flambant neuf pointe vers la bonne machine mais sert un cert qui n'a jamais été émis que pour l'ancien site. Et les wildcards trompent leur monde : un wildcard peut couvrir un seul label comme app.example.com tout en ne faisant rien pour un nom plus profond comme api.app.example.com. Vérifier les noms que tu attends avant de basculer te coûte une minute. Courir après les alertes navigateur ensuite, avec les utilisateurs qui regardent, coûte bien plus cher.

Timing du renewal et habitudes opérationnelles

N'attends pas le dernier jour. S'il te plaît. Pour tout ce qui compte en prod, les sites, les API, les domaines d'admin, donne-toi une marge de 30 jours. Cette fenêtre, c'est ce qui rattrape les trucs qui cassent en silence : une validation DNS qui ne passe pas, un CDN qui échange son cert d'edge dans ton dos, un compte auquel plus personne ne peut se connecter, une automation morte il y a trois mois sans que personne s'en rende compte. Et quand un cert approche de la fin, pose les questions barbantes. Qui possède vraiment le renewal ? L'auto-renew est-il seulement activé ? Quel challenge utilise-t-il ? Si tout ça s'écroule, y a-t-il un fallback manuel, ou on improvise ?

Checks SSL courants après un changement

• Re-teste le hostname exact une fois le DNS propagé. Le domaine racine seul ne suffit pas.
• Re-teste après avoir allumé un CDN ou l'avoir contourné. Le cert d'edge et le cert d'origin ne correspondent pas toujours.
• Si l'apex et www restent publics tous les deux, teste les deux. On oublie toujours celui qu'on n'utilise pas.
• Une fois le HTTPS stable, regarde les headers HTTP pour que HSTS et les redirections soient un choix, pas un accident.
• Et garde la surveillance d'expiry dans son propre couloir, séparée du debug ponctuel que tu fais aujourd'hui.

Questions fréquentes