Vérificateur de certificat TLS

Vérifiez le certificat TLS/SSL d'un site : sujet/émetteur, dates de validité, SANs, complétude de la chaîne et erreurs de configuration HTTPS courantes. Suivez optionnellement les redirections pour vérifier que la destination finale est en HTTPS avec un certificat valide. Exportez des rapports JSON/PDF.

Loading…

À propos Vérificateur de Certificat TLS

Lorsque HTTPS tombe en panne, les utilisateurs voient des avertissements effrayants et les bots cessent de faire confiance à votre site. Cet outil récupère une URL, suit optionnellement les redirections et inspecte le certificat TLS qui protège le point de terminaison HTTPS final. Il vous aide à détecter les certificats expirant, les chaînes incomplètes, les incohérences de nom d'hôte/SAN et autres problèmes qui causent couramment des erreurs de navigateur et des problèmes de référencement/disponibilité.

Fonctionnalités

  • Inspectez le sujet et l'émetteur du certificat (pour qui il est, qui l'a émis).
  • Validez les dates : notBefore / notAfter, et alertez en cas d'expiration imminente.
  • Vérifiez les SANs (Subject Alternative Names) et la couverture du nom d'hôte (www vs apex, sous-domaines).
  • Détectez les problèmes de chaîne de certificats (intermédiaires manquants / chaîne incomplète).
  • Suivi optionnel des redirections pour valider l'application HTTPS de l'URL finale.
  • Identifiez les pièges HTTPS courants (mauvais hôte, mauvais certificat, flux de redirection mixtes).
  • Résultats et constatations faciles à copier pour les tickets d'incident.
  • Téléchargez des rapports JSON et PDF pour la documentation et les vérifications de régression.

🧭 Comment utiliser for tls-certificate-checker

1

Collez l'URL à tester

Saisissez l'URL cible. Vous pouvez coller https://example.com ou même http://example.com si vous voulez confirmer qu'il passe finalement en HTTPS.

2

Activez "Suivre les redirections" pour un comportement réaliste

Si vous voulez valider la destination réelle atteinte par les utilisateurs et les robots d'indexation (http→https, non-www→www), gardez "Suivre les redirections" activé.

3

Exécutez la vérification et examinez le résumé

Vérifiez les éléments clés : dates de validité, correspondance du nom d'hôte/SAN, et si la chaîne est complète.

4

Inspectez les constatations et corrigez la cause racine

Si vous voyez des avertissements (expiration proche, incohérence, chaîne incomplète), corrigez-les au niveau de la terminaison TLS (CDN, proxy inverse, répartiteur de charge ou serveur web).

5

Exportez JSON/PDF pour le suivi

Téléchargez un rapport à joindre aux tickets ops/SEO ou pour conserver un instantané avant/après.

Spécifications techniques

Entrée et fonctionnement

Cet outil vérifie une URL et inspecte le certificat TLS pour le point de terminaison HTTPS résolu.

CapacitéDétails
Formes d'URL prises en chargeURL HTTP ou HTTPS (le suivi des redirections peut être activé).
Gestion des redirectionsOptionnel ; lorsqu'activé, suit jusqu'au nombre maximal configuré de redirections.
Focus TLSInspecte les propriétés du certificat et les mauvaises configurations courantes.

Valeurs par défaut et limites

Les paramètres par défaut de récupération et de sécurité sont ajustés pour un comportement prévisible.

ParamètreValeur
Suivre les redirectionsActivé
Redirections max10
Délai d'attente15000 ms
Agent utilisateurEncode64Bot/1.0 (+https://encode64.com)
Réseaux privésNon autorisé

Ce qui est vérifié

Les vérifications sont conçues autour des pannes les plus fréquentes observées en production : expiration, inadéquation du nom d'hôte (couverture SAN) et complétude de la chaîne. Le suivi des redirections aide à détecter les cas où le HTTPS n'est valide que sur l'hôte canonique final.

Un certificat valide est nécessaire mais pas suffisant pour une sécurité robuste. Associez cela à des audits HSTS et des en-têtes de sécurité pour des déploiements renforcés.

Ligne de commande

Utilisez OpenSSL et curl pour confirmer les détails du certificat depuis votre propre terminal et comparez avec ce que l'outil rapporte.

macOS / Linux

Afficher la chaîne de certificats (SNI) pour un hôte

echo | openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null

Utile pour inspecter le certificat feuille présenté et la chaîne intermédiaire.

Extraire rapidement la date d'expiration

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Affiche notBefore / notAfter.

Lister les SANs

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Montre quels noms d'hôte le certificat couvre.

Vérifier les redirections HTTP vers HTTPS

curl -I http://example.com

Vérifier l'en-tête Location et le schéma final.

Suivre les redirections et afficher l'URL finale

curl -IL http://example.com | sed -n '1,120p'

Aide à détecter les chaînes de redirection et les points de terminaison non canoniques.

Utilisez toujours -servername avec openssl s_client sur les serveurs hébergés virtuellement/CDN. Sans SNI, vous pouvez obtenir le mauvais certificat.

Cas d'utilisation

Prévenir les pannes d'expiration de certificat

Identifiez les certificats approchant de l'expiration pour pouvoir les renouveler avant que les utilisateurs et les robots ne rencontrent des erreurs de navigateur.

  • Contrôles hebdomadaires de santé des certificats
  • Auditer les domaines après des changements DNS ou CDN

Corriger les problèmes de chaîne de certificats incomplète

Détectez les intermédiaires manquants (courants sur les configurations serveur personnalisées) qui cassent les anciens clients et certains robots d'indexation.

  • Bundle de chaîne Nginx/Apache mal configuré
  • Équilibreur de charge sans certificats intermédiaires

Déboguer les incohérences de nom d'hôte/SAN (www vs apex)

Confirmez que le certificat couvre exactement l'hôte atteint par les utilisateurs, y compris www/non-www et les sous-domaines.

  • L'apex fonctionne mais www casse
  • Sous-domaine API manquant dans la liste SAN

Vérifier l'application HTTPS via les redirections

Assurez-vous que les URL http redirigent vers le point de terminaison https canonique avec un certificat valide.

  • http→https avec 301
  • canonicalisation non-www→www

❓ Frequently Asked Questions

❓Pourquoi un navigateur peut-il dire "certificat non fiable" même si HTTPS est activé ?

Les causes courantes sont un certificat expiré, une chaîne incomplète (intermédiaire manquant), une incohérence de nom d'hôte (SAN n'inclut pas l'hôte), ou la présentation du mauvais certificat due à une mauvaise configuration SNI/hébergement virtuel.

❓Que sont les SAN et pourquoi sont-ils importants ?

Les SAN (Subject Alternative Names) sont les noms d'hôte pour lesquels un certificat est valide. Si votre site est accessible via example.com et www.example.com, le certificat doit couvrir les deux (ou vous devez rediriger de manière cohérente vers un hôte couvert).

❓Est-ce acceptable si http redirige vers https ?

Oui — c'est recommandé. Assurez-vous simplement que la destination HTTPS finale présente un certificat valide et que la chaîne de redirection est courte et cohérente (préférez 301 pour les redirections canoniques).

❓Cet outil vérifie-t-il les versions/cipher suites TLS ?

Cet outil se concentre sur l'inspection des certificats et les mauvaises configurations courantes. Pour le renforcement des protocoles/cipher suites (TLS 1.2/1.3, cipher suites faibles), utilisez un scanner de configuration TLS dédié.

❓Quelle est la différence entre les certificats feuille, intermédiaire et racine ?

Le certificat feuille est celui de votre site. Les intermédiaires le relient à une autorité de certification racine de confiance. Les navigateurs font confiance aux racines, donc des intermédiaires manquants peuvent empêcher la construction d'une chaîne de confiance valide.

Pro Tips

Best Practice

Renouvelez les certificats tôt et automatisez les renouvellements (ACME) autant que possible.

Best Practice

Assurez-vous que les SAN couvrent chaque nom d'hôte public que vous servez (www, apex, sous-domaines API) ou imposez un seul hôte canonique via des redirections.

Best Practice

Servez toujours la chaîne complète (feuille + intermédiaires). De nombreuses pannes proviennent de chaînes incomplètes après des migrations.

Best Practice

Si vous activez des redirections, gardez-les minimales : un seul saut vers l'URL HTTPS canonique est idéal.

Best Practice

Associez un TLS valide avec HSTS et des en-têtes de sécurité pour une protection renforcée en conditions réelles.

Additional Resources

Documentation OpenSSL s_client
Documentation
RFC 5280 : Profil de certificat et CRL de l'infrastructure à clé publique Internet X.509
Documentation
Let's Encrypt : Bases des certificats
Documentation

Other Tools