Aller au contenu
D1
FR
EnglishРусскийEspañolFrançaisPortuguêsDeutschItalianoPolski

Audit de certificat

Vérificateur de certificat SSL

Vérifiez la validité du certificat, l'expiration, l'émetteur, les SAN et les détails TLS négociés pour n'importe quel hôte.

Ce formulaire appelle le point de terminaison relatif: /site-api/tools/ssl

Comment utiliser le Vérificateur de certificat SSL

  1. Saisissez un hostname (port 443 implicite sauf documentation). L'outil ouvre TLS et récupère la chaîne présentée — sans UI cadenas navigateur.
  2. Examinez subject, émetteur, dates, liste SAN, complétude chaîne et version TLS négociée. Intermédiaires manquants donnent chaînes courtes échouant sur clients stricts malgré Chrome OK.
  3. Comparez couverture SAN avec l'URL visitée — apex vs www, staging et API nécessitent noms explicites ou wildcards. Copiez détails pour tickets renouvellement ou conformité.
  4. Revérifiez après cutover DNS avec Vérificateur DNS d'abord — mauvaise IP diagnostique le mauvais serveur. Historique local uniquement ; pas moteur CT ni dashboard multi-années sans API.

Champs du certificat SSL expliqués

Les certificats TLS lient identités et clés publiques. Le tableau mappe les champs courants lors de renouvellements, migrations et incidents. La validité ne prouve pas la sécurité du site — un domaine phishing peut obtenir des certs DV. Combinez SSL avec âge WHOIS, en-têtes HTTP et enregistrements Vérificateur DNS.

ChampQue vérifierValeur type
Subject / CNNom d'hôte principal du certificatCN=www.example.com
SANTous les hostnames couverts par le certexample.com, www.example.com
ÉmetteurAutorité de certification signataireLet's Encrypt R3
Valide du / auFenêtre not-before et not-after2025-01-01 — 2025-04-01
ChaîneCertificats intermédiaires jusqu'au trust storeFeuille → R3 → ISRG Root X1
Version TLSProtocole négocié avec l'hôteTLS 1.3
Algorithme de signatureHash et type de clé de la feuilleECDSA avec SHA-256
Numéro de sérieIdentifiant unique pour révocation03:ab:cd:...
OCSP / CRLIndices du mécanisme de révocationOCSP stapling si configuré

Quand lancer une vérification SSL

Lancez avant/après renouvellements, migrations CA ou incidents rate-limit Let's Encrypt. Expiration sous trente jours doit déclencher automation ou réémission — l'outil lit not-after live, pas rappels calendrier.

Après moves CDN/origine, confirmez que l'edge présente la liste SAN voulue. Clients sur www alors que le cert ne couvre que apex (ou inverse) voient des avertissements malgré curl « OK » avec Host.

Chaînes incomplètes échouent sur Android/Java alors que Safari desktop passe. Inspectez intermédiaires et installez le bundle documenté. DIG CAA avant de blâmer la CA — CAA restrictif bloque émission jusqu'à fix DNS.

Questionnaires conformité demandent version TLS et posture chiffrement. L'outil rapporte protocoles négociés pour attestations « TLS 1.2+ » — pas remplacement scan PCI ASV.

Réponse incident MITM compare émetteur et serial à vos archives saines. DN01 montre présentation wire actuelle — pas diffs CT historiques sans snapshots API.

SaaS multi-tenant sur wildcard doit lister domaines vanity clients BYO — *.platform.com ne couvre pas tenant.com sans SAN ou cert séparé.

Flottes IoT long-lived peuvent faire confiance à roots expirés — upgrade TLS 1.3 serveur casse firmware legacy ; l'outil sur prod montre ce que voient clients modernes.

Health checks LB avec certs auto-signés backend n'affectent pas le leaf public — gardez Vérificateur de certificat SSL sur VIP client lors des drills infra.

Renouvellements automatisés certbot/acme.sh peuvent laisser ancienne chaîne CDN alors que l'origine sert la nouvelle — comparez Vérificateur de certificat SSL sur URL publique et panneau CDN après émission.

Sous-domaines tiers en CNAME (email SaaS, helpdesk) présentent certs du fournisseur — l'outil confirme ce que voit le client final, pas ce que vous croyez avoir délégué en DNS.

Les équipes email marketing oublient parfois d'inclure domaines tracking dans SAN — le Vérificateur de certificat SSL sur chaque host CNAME évite surprises après campagne.

Multicloud avec cert manager Kubernetes exige resync CDN après rotation secret — relancez le check sur apex, www et api après chaque déploiement Helm.

Après migration vers ZeroSSL ou Sectigo, les clients Java legacy exigent parfois cross-sign — le Vérificateur de certificat SSL montre la chaîne réellement servie, pas le PDF d'achat CA.

Lors d'un incident, comparez serial et issuer avec archive interne — le Vérificateur de certificat SSL ne remplace pas réponse juridique registrar mais accélère triage technique avant escalade CA.

Domaines multi-région avec cert geo edge peuvent diverger — échantillonnez depuis réseaux client réels ; DN01 montre présentation depuis notre chemin fetch documenté dans ticket.

Résoudre les erreurs de certificat

Hostname mismatch : SAN ne contient pas votre label — corrigez CNAME/A ou réémettez avec bons SAN. Wildcards couvrent un niveau (*.example.com) pas api.staging.example.com sauf listé.

Certs expirés ou not-yet-valid : skew horloge serveurs — NTP sur VMs origin. Renouvellement auto peut échouer si HTTP-01 casse par dérive A — Vérificateur DNS d'abord.

Émetteur non fiable ou chaîne incomplète : installez intermédiaires sur origin/CDN, pas seulement feuille. Panneaux n'uploadent parfois que la feuille ; browsers cachent AIA interdit aux API strictes.

TLS trop bas : upgrade serveur ou LB. Clients legacy TLS 1.0 peuvent encore échouer après hardening.

OCSP stapling absent n'est pas toujours fatal — notez stapling pour sites à fort trafic.

Lors d'un incident, comparez serial et issuer avec archive interne — le Vérificateur de certificat SSL ne remplace pas réponse juridique registrar mais accélère triage technique avant escalade CA.

Domaines multi-région avec cert geo edge peuvent diverger — échantillonnez depuis réseaux client réels ; DN01 montre présentation depuis notre chemin fetch documenté dans ticket.

Certificats, CAA et validation HTTP

Validations HTTP-01 et TLS-ALPN-01 exigent hôtes joignables sur noms du CSR. Vérificateur DNS confirme A/AAAA avant debug SSL.

CAA restreint quelles CA peuvent émettre. DIG ou Vérificateur DNS sur CAA avant tickets support CA.

HSTS et redirects du Vérificateur d'en-têtes HTTP réduisent échecs http-01. Mixed content et CSP n'affectent pas validité cert mais cassent cadenas — headers après chaîne saine.

Vérificateur de certificat SSL DN01 connecte depuis notre infra — pass ici ne garantit pas même cert partout en multi-CDN.

CA privées mTLS interne hors trust stores publics — checker sur noms internes aide debug ops.

Les records CAA avec issuewild restreignent wildcards séparément des apex — DIG avant migration wildcard pour éviter blocage silencieux chez Let's Encrypt.

Workflow de renouvellement TLS en cinq étapes

  1. Vérificateur DNS sur tous noms CSR/SAN — A, AAAA, CNAME vers endpoint validation.
  2. DIG CAA si émissions passées ont échoué — retirez tags issue trop stricts si politique le permet.
  3. Émettez ou renouvelez chez CA ; installez chaîne complète origin/CDN.
  4. Vérificateur de certificat SSL sur chaque variante publique (apex, www, api).
  5. Vérificateur d'en-têtes HTTP pour HSTS et redirects ; archivez — DN01 ne garde pas calendriers renouvellement partagés.
  6. Archivez sortie Vérificateur de certificat SSL avec horodatage dans ticket renouvellement — DN01 ne synchronise pas calendrier enterprise PKI.

Vérificateur de certificat SSL vs SSL Labs et services de monitoring

Qualys SSL Labs : grades profonds et CVE — excellent trimestriel, lent pour « cert expiré aujourd'hui ? » DN01 optimise chaîne/SAN rapides avec Vérificateur DNS et Vérificateur d'en-têtes HTTP.

Moniteurs uptime alertent expiration — DN01 snapshots manuels/API sans paging.

UI cadenas cache parfois — checker wire évite cache navigateur.

Pas de badge A+ faux, pas scan subnets, pas cartes propagation. Huit langues, historique local, API.

Calendriers PKI enterprise ne sont pas remplacés — checker pour vérité wire Sev2.

Pinning mobile casse silencieusement à rotation leaf — checker valide TLS public.

EV rare en stacks DV — focus SAN et chaîne pour Let's Encrypt.

Sunset TLS 1.0 : testez partners legacy après désactivation.

Self-signed staging échoue trust public — confirmez issuer CN interne.

CT logs hors scope DN01 — complète produits CT.

Monitoring CT type crt.sh détecte émission surprise — DN01 complète par lecture wire immédiate quand CT alerte mais ops doivent confirmer chaîne live.

Load balancers F5 ou Citrix servent certs différents par SNI — testez chaque hostname public ; un check apex ne couvre pas api.client.exemple.com.

mTLS entre microservices utilise CA internes — Vérificateur de certificat SSL sur noms internes aide debug même si navigateurs publics rejettent l'émetteur.

Rotations d'urgence après compromission clé privée exigent révocation et réémission — archivez serial ancien et nouveau avec sortie vérificateur.

HashiCorp Vault ou step-ca internes ne remplacent pas contrôle public — combinez Vérificateur de certificat SSL pour VIP clients et procédures PKI pour mesh interne.

Auditeurs demandent preuve TLS 1.2 minimum — exportez sortie vérificateur avec date dans ticket conformité, pas capture padlock navigateur seule.

Les hébergeurs mutualisés renouvellent en masse — vérifiez chaque domaine client même si le panel affiche vert ; DN01 lit le fil, pas l'icône du tableau de bord.

Pour les boutiques PrestaShop ou WooCommerce, TLS sur admin et checkout doit couvrir SAN checkout — un check www seul laisse des warnings sur sous-domaines paiement.

Lors d'un incident, comparez serial et issuer avec archive interne — le Vérificateur de certificat SSL ne remplace pas réponse juridique registrar mais accélère triage technique avant escalade CA.

Domaines multi-région avec cert geo edge peuvent diverger — échantillonnez depuis réseaux client réels ; DN01 montre présentation depuis notre chemin fetch documenté dans ticket.

Exportez PDF ou texte copié du Vérificateur de certificat SSL dans change advisory client — preuve wire datée sans promettre couverture CT mondiale.

Pourquoi DN01 Vérificateur de certificat SSL

  • Chaîne, SAN, émetteur et validité live via handshake TLS — plus rapide que SSL Labs complet.
  • Avec Vérificateur DNS, DIG, Vérificateur d'en-têtes HTTP et WHOIS pour migrations et incidents.
  • Huit interfaces localisées, sortie copiable, historique local, API — pas d'entrepôt CT.
  • Limites honnêtes : snapshot wire depuis notre chemin, pas cartes cert edge mondiales.

FAQ

FAQ du Vérificateur de certificat SSL

Expiration, émetteur, chaîne et couvertura d'hôte du certificat.

Que valide le vérificateur SSL ?

Il se connecte à l'hôte et remonte le sujet, l'émetteur, les dates de validité, la couverture SAN et les détails de chaîne. Si l'expiration est prioritaire, commencez par la vérification d'expiration SSL.

Pourquoi un certificat peut sembler valide mais échouer quand même ?

Causes fréquentes : intermédiaire manquant, nom d'hôte incorrect, racine expirée ou magasin de confiance client obsolète. Le guide de la chaîne de certificats explique les bases.

Dois-je vérifier le DNS avant le SSL ?

Si le mauvais serveur répond, l'analyse SSL peut être trompeuse. Vérifiez A/AAAA ou CNAME dans Vérificateur DNS avant d'approfondir le certificat.

Peut-on automatiser la surveillance des certificats ?

Oui. La page web sert aux contrôles ponctuels ; pour le suivi récurrent, utilisez la documentation API après avoir demander un jeton API.

Qu'est-ce qu'un certificat SAN ?

Les Subject Alternative Names listent chaque hostname couvert par un certificat — par ex. apex et www. Les erreurs de mismatch signifient souvent que le certificat ne couvre pas le nom exact demandé par le navigateur.

Combien de temps avant l'expiration faut-il renouveler ?

La plupart des opérateurs renouvellent à 30 jours de l'expiration ; l'automatisation Let's Encrypt renouvelle souvent plus tôt. Utilisez ce vérificateur chaque semaine sur les hôtes de production pendant les migrations.

L'outil teste-t-il la version TLS et les chiffrements ?

Il rapporte les détails TLS négociés quand disponibles. Pour des audits de chiffrement approfondis, des scanners spécialisés peuvent être nécessaires — DN01 se concentre sur la validité du certificat, la chaîne et l'adéquation du hostname au quotidien.

Pourquoi SSL échoue-t-il sur des adresses IP ?

Les CA publiques émettent rarement des certificats pour des IP brutes. Vérifiez que le hostname du certificat correspond au nom tapé par les utilisateurs — les chaînes CNAME peuvent masquer les écarts jusqu'à une visite directe de l'apex.

Puis-je vérifier les certificats des serveurs mail ?

Saisissez le hostname MX ou l'hôte du endpoint SMTP TLS. Le STARTTLS mail utilise les mêmes bases X.509 — expiration et couverture hostname — même si les navigateurs n'affichent jamais cette connexion.

Quel est l'ordre de la chaîne de certificats ?

Les serveurs doivent envoyer la feuille, les intermédiaires et éventuellement la racine. Des intermédiaires manquants provoquent des échecs aléatoires sur clients stricts même si Chrome semble correct. L'outil montre la chaîne renvoyée par l'hôte live.

Le vérificateur SSL est-il gratuit ?

Oui pour les recherches manuelles. La surveillance automatique d'expiration utilise la documentation API avec un jeton API.

Faut-il associer SSL aux en-têtes HTTP ?

Oui. HSTS et les en-têtes de redirection du Vérificateur d'en-têtes HTTP expliquent si les navigateurs atteindront votre nouveau certificat dès le premier saut.

Sélecteur d'outil

Continuer avec une autre vérification

Choisissez la prochaine étape de votre flux de travail domaine ou sécurité.

Catalogue complet d'outils →

Guides

Articles connexes

Guides pratiques pour les tâches courantes avec Vérificateur de certificat SSL — enregistrements DNS, dépannage et liens vers nos outils gratuits.

Retour à Vérificateur de certificat SSL