À quoi sert cet outil ?
Le SSL Certificate Checker répond à une question que le navigateur laisse sans réponse : ce certificat HTTPS est-il valide, de confiance, correspond-il au domaine, et quand expire-t-il ? Un navigateur affiche « connexion sécurisée » ou « votre connexion n'est pas privée », jamais le pourquoi.
L'outil ouvre une vraie connexion TLS vers l'hôte, inspecte le certificat serveur et la chaîne présentée, puis rend un verdict à états discrets. Pas de « ça a l'air d'aller ». Une réponse.
La différence avec la barre d'adresse tient en un point : le navigateur juge la connexion telle que lui la voit, après avoir déjà rattrapé en coulisse une chaîne bancale. Le checker juge la chaîne telle que le serveur la sert vraiment, comme le verrait curl, un serveur d'API distant ou un smartphone. C'est cette vue honnête qui débusque les pannes fantômes.
Trois usages qui reviennent sans cesse :
- Avant un incident : un certificat expire dans huit jours, aucune alerte navigateur, panne totale à l'échéance. Vous le voyez venir.
- Après un déploiement : le site s'ouvre chez vous, mais le webhook du partenaire renvoie une erreur TLS. Chaîne incomplète, presque toujours.
- En audit : clé RSA de 1024 bits ou signature SHA-1 qui traîne sur un vieux service interne. Le verdict la pointe du doigt.
Comment lire le verdict
Le verdict tient en un mot coloré, et ce mot suffit à décider. Voici comment le décoder.
| Verdict | Couleur | Ce que ça veut dire |
|---|---|---|
| Valide | vert | De confiance, correspond au domaine, chaîne complète, clé et signature à jour. Rien à faire. |
| Expire bientôt | orange | Correct aujourd'hui, mais l'échéance approche ou la crypto est faible. À corriger sans panique. |
| Invalide | rouge | Expiré, pas encore valide, mauvais nom d'hôte, ou chaîne non vérifiable. Le navigateur affichera une erreur. |
| Auto-signé | rouge distinct | Le certificat s'est signé lui-même. Aucune confiance publique. |
| Injoignable | technique | Le serveur n'a pas répondu : timeout, refus, ou IP bloquée. |
Sous le verdict, le détail : date d'expiration et jours restants, chaîne présentée dans l'ordre, liste des SAN, version TLS, cipher, type et taille de clé, algorithme de signature. De quoi diagnostiquer, pas seulement constater.
Un cas mérite qu'on s'y arrête. Invalide ne veut pas toujours dire « certificat pourri ». Quand la seule anomalie est une chaîne servie incomplète, le message bascule sur un diagnostic précis : servez le fullchain. Le certificat est bon ; c'est sa livraison qui cloche.
Les cas concrets que l'outil débusque
Chaîne incomplète : le serveur ne présente que le certificat serveur
C'est le grand classique. Le serveur envoie son certificat serveur, mais oublie l'intermédiaire qui le relie à la racine. Résultat : la chaîne ne remonte à aucune autorité reconnue, telle qu'elle est servie.
Chrome et Edge s'en sortent : ils téléchargent l'intermédiaire manquant tout seuls (AIA fetching). Le site « marche chez vous ». Mais curl refuse, le client mail rejette la connexion, l'app mobile plante et la bibliothèque HTTP du partenaire lève une erreur TLS. Un enfer à diagnostiquer sans outil dédié, parce que le symptôme dépend de qui regarde.
Le correctif est unique et sans surprise : servir le fullchain, c'est-à-dire le certificat serveur suivi du ou des intermédiaires, concaténés dans le bon ordre. Let's Encrypt vous fournit directement un fichier fullchain.pem prêt à l'emploi.
# Compter les certificats réellement servis
openssl s_client -connect captaindns.com:443 -servername captaindns.com -showcerts </dev/null 2>/dev/null | grep -c "BEGIN CERTIFICATE"
# 1 seul certificat = chaîne incomplète
Un cas particulier passe souvent pour un bug de l'outil : le certificat serveur servi seul qui se vérifie quand même. Ça n'arrive que si ce certificat a été émis directement par une racine, ce que le CA/Browser Forum interdit désormais. En pratique, un certificat public servi seul sort invalide, et la reco est toujours la même : fullchain.
Expiration : la panne qu'aucun navigateur n'annonce
Un certificat qui expire dans dix jours ne déclenche aucun avertissement. Le jour J, tout tombe. HTTPS bloqué, API muette, webhooks en erreur, et le support qui prend feu.
L'outil met la date d'expiration et les jours restants en tête de résultat. En dessous d'un mois, il passe en avertissement. Mais un instantané ne prévient pas : pour ça, il faut une surveillance qui tourne en boucle (voir plus bas).
Nom d'hôte : le domaine absent des SAN
Le certificat est valide et de confiance, mais il ne couvre pas le nom demandé. Les navigateurs ignorent le vieux champ Common Name : ils lisent uniquement les SAN (Subject Alternative Names). Si le domaine n'y est pas, erreur NET::ERR_CERT_COMMON_NAME_INVALID, quoi que dise le CN.
Le piège le plus fréquent, c'est le wildcard. *.captaindns.com couvre www.captaindns.com, mais pas l'apex captaindns.com, ni un niveau plus bas comme a.b.captaindns.com. Un wildcard ne descend que d'un cran. La correction : réémettre en listant tous les noms voulus dans les SAN.
Auto-signé : chiffré, mais sans confiance
Un certificat auto-signé a le même émetteur et le même sujet. Il chiffre la connexion, donc les données transitent bien à l'abri. Mais personne ne garantit à qui appartient la clé. Le navigateur refuse et affiche un avertissement.
Parfait pour un service interne ou un environnement de test. Sur un site public, c'est un cul-de-sac : émettez plutôt un certificat gratuit via Let's Encrypt et automatisez-le avec ACME. L'outil isole ce cas dans un verdict à part, pour ne pas le confondre avec un certificat cassé.
Crypto faible : les fossiles qui traînent
Une clé RSA sous 2048 bits, une clé ECDSA sous 256 bits, une signature SHA-1 ou MD5 : autant de reliques qui rôdent sur de vieux services jamais migrés. Le navigateur peut les tolérer un temps, mais elles sont sur la sellette. L'outil les signale sur le certificat serveur, avant qu'un durcissement client ne les fasse rejeter du jour au lendemain.
Automatisation et surveillance : la seule stratégie tenable
Vérifier à la main, c'est bon pour un incident ponctuel. Ça ne tient pas dans la durée, et le calendrier le rend intenable.
Le CA/Browser Forum réduit la durée de vie des certificats par paliers : 200 jours en mars 2026, 100 jours en 2027, 47 jours en 2029. À 47 jours, renouveler à la main devient absurde. Deux réflexes s'imposent.
Automatiser l'émission avec ACME. Le protocole ACME (celui de Let's Encrypt, via certbot, Caddy, Traefik, lego) renouvelle et réinstalle le certificat sans intervention humaine. Configuré une fois, oublié ensuite. C'est la seule façon de suivre le rythme.
Surveiller l'expiration en continu. L'automatisation échoue parfois en silence : quota d'émission atteint, DNS cassé pour la validation, hook de rechargement muet. Une surveillance qui vérifie l'expiration à intervalle régulier et alerte à l'avance rattrape ces trous. L'HTTP Uptime Monitor de CaptainDNS remplit ce rôle pour vos endpoints HTTPS.
Ce checker et le monitor se répondent : l'un diagnostique à l'instant T, l'autre monte la garde. Pour creuser le calendrier et ses conséquences, lisez notre guide sur la réduction de la durée des certificats à 47 jours. Et pour passer de la vérification ponctuelle à une démarche complète (inventaire, automatisation ACME, surveillance d'expiration), notre guide sur la gestion du cycle de vie des certificats déroule la méthode.
Web HTTPS uniquement
Cette version couvre le web HTTPS : connexion TLS implicite sur host:port, port 443 par défaut. Le mail est hors périmètre. Un serveur SMTP négocie généralement le TLS après coup, via STARTTLS, sur les ports 25, 587 ou 465 : un dial direct n'y verrait rien.
Pour le certificat d'un serveur de messagerie, deux outils prennent le relais : le SMTP/MX Tester inspecte le certificat présenté en STARTTLS, et le vérificateur DANE/TLSA confirme qu'il correspond bien à l'empreinte publiée dans le DNS. Ne mélangez pas les deux mondes : un certificat web et un certificat MX ne se vérifient pas de la même façon.
FAQ - Questions fréquentes
Q : Comment vérifier un certificat SSL en ligne ?
R : Entrez le nom de domaine dans le champ hôte et lancez la vérification. L'outil ouvre une connexion TLS vers l'hôte et le port (443 par défaut), inspecte le certificat serveur et la chaîne présentée, puis renvoie un verdict : validité, correspondance du nom d'hôte, confiance système, expiration, robustesse de la clé et de la signature.
Q : Quelle différence entre certificat serveur, intermédiaire et racine ?
R : Le certificat serveur porte votre nom de domaine. L'intermédiaire fait le lien entre lui et la racine. La racine (root CA) vit dans le magasin de confiance du système. Le serveur doit présenter le certificat serveur suivi des intermédiaires ; la racine n'a pas à être envoyée. Cette suite, c'est le fullchain.
Q : Pourquoi mon site marche dans Chrome mais casse ailleurs ?
R : C'est le symptôme d'un intermédiaire manquant. Chrome et Edge récupèrent l'intermédiaire absent tout seuls (AIA fetching), mais curl, les clients de messagerie et beaucoup de mobiles rejettent la connexion. Servez la chaîne complète (fullchain) pour corriger partout.
Q : Combien de temps un certificat SSL est-il valide ?
R : Jusqu'à 398 jours aujourd'hui, mais la durée fond. Le CA/Browser Forum impose 200 jours en mars 2026, 100 jours en 2027, 47 jours en 2029. Let's Encrypt émet déjà sur 90 jours. À ce rythme, renouveler à la main ne tient plus : il faut automatiser via ACME.
Q : Comment surveiller l'expiration d'un certificat SSL ?
R : Ce checker donne un instantané. Pour être prévenu avant la panne, branchez une surveillance continue avec l'HTTP Uptime Monitor : il vérifie l'expiration à intervalle régulier et alerte à l'approche de l'échéance.
Q : Que signifie un certificat auto-signé ?
R : Son émetteur et son sujet sont identiques : il s'est signé lui-même. Il chiffre la connexion mais n'offre aucune confiance publique, d'où l'avertissement du navigateur. Bon pour un usage interne ; pour un site public, prenez un certificat émis par une autorité reconnue comme Let's Encrypt.
Q : Que faire si le nom d'hôte ne correspond pas ?
R : Le domaine demandé n'est pas dans les SAN du certificat. Cas courant : un wildcard *.captaindns.com ne couvre ni l'apex ni un sous-sous-domaine. Réémettez le certificat avec tous les noms voulus dans les SAN. Le Common Name ne compte plus : seuls les SAN sont lus.
Outils complémentaires
| Outil | Utilité |
|---|---|
| Analyseur de CSR | Décoder un CSR avant de le soumettre à votre autorité de certification |
| Vérificateur DANE/TLSA | Confirmer l'empreinte du certificat mail publiée dans le DNS |
| Vérificateur TLS-RPT | Recevoir des rapports sur les échecs TLS de vos serveurs mail |
| HTTP Uptime Monitor | Surveiller la disponibilité et l'expiration de vos endpoints HTTPS |
Ressources utiles
- RFC 5280 - Profil des certificats X.509 (structure et validation des certificats)
- RFC 6125 - Vérification du nom d'hôte (correspondance SAN et wildcards)
- CA/Browser Forum - Baseline Requirements (règles d'émission et durée de vie)
- Documentation Let's Encrypt - Certificats de chaîne (fullchain et intermédiaires)