Vérificateur de certificat SSL
Vérifiez les détails du certificat SSL/TLS pour tout domaine.
Qu'est-ce qu'un vérificateur de certificat SSL ?
SSL (Secure Sockets Layer) et son successeur TLS (Transport Layer Security) chiffrent la connexion entre un navigateur web et un serveur, protégeant les données en transit contre l'interception et la falsification. Un certificat SSL atteste qu'un site web est bien celui qu'il prétend être. Cet outil vérifie si le certificat SSL d'un domaine est valide, correctement configuré et non expiré.
Lorsque vous visitez un site web en HTTPS, votre navigateur vérifie le certificat SSL avant d'établir la connexion chiffrée. Si le certificat est expiré, émis pour un autre domaine ou signé par une autorité non approuvée, le navigateur affiche un avertissement de sécurité. Cet outil effectue les mêmes vérifications et fournit des informations détaillées sur le certificat.
Pourquoi HTTPS et TLS sont essentiels
TLS (Transport Layer Security) offre trois garanties fondamentales pour chaque connexion HTTPS. Premièrement, le chiffrement : toutes les données échangées entre le navigateur et le serveur sont chiffrées, de sorte que quiconque intercepte le trafic — sur un réseau Wi-Fi de café, par exemple — ne voit que des octets brouillés. Deuxièmement, l'intégrité : TLS utilise des codes d'authentification de message (MAC) pour détecter toute altération en transit, garantissant que ni la requête ni la réponse n'a été modifiée. Troisièmement, l'authentification : le certificat permet au navigateur de vérifier qu'il communique bien avec le serveur réel et non avec un usurpateur effectuant une attaque de l'homme du milieu.
Au-delà de la sécurité, HTTPS est devenu un signal de classement pour Google Search et un prérequis pour les fonctionnalités modernes des navigateurs telles que les Service Workers, la géolocalisation et l'accès à la caméra. Des navigateurs comme Chrome et Firefox marquent les pages HTTP comme « Non sécurisé », ce qui érode la confiance des utilisateurs et augmente les taux de rebond. Les sites sans certificat valide peuvent également figurer sur les listes de blocage des services de renseignement sur les menaces utilisées par les pare-feu d'entreprise, coupant ainsi l'accès à des audiences entières.
Ce que le vérificateur rapporte en détail
Une vérification complète d'un certificat SSL/TLS va bien au-delà d'un simple succès/échec. Voici ce que chaque champ vous indique :
- Dates de validité et expiration — Le certificat contient un horodatage notBefore et notAfter. Le vérificateur confirme que la date actuelle se situe dans cette plage et indique le nombre de jours restant avant l'expiration. Toute valeur inférieure à 30 jours doit déclencher un renouvellement immédiat.
- Émetteur et autorité de certification (CA) — Le champ émetteur identifie la CA qui a signé le certificat : par exemple, « Let's Encrypt Authority X3 », « DigiCert TLS RSA SHA256 2020 CA1 » ou « Sectigo RSA Domain Validation CA ». Identifier l'émetteur vous permet de vérifier qu'un site utilise une CA de confiance et non une CA obscure ou privée.
- Sujet et noms alternatifs du sujet (SAN) — Le CN (Common Name) du sujet désignait historiquement le nom d'hôte pour lequel le certificat était émis. Les certificats modernes s'appuient sur les SAN, une liste de tous les domaines et sous-domaines que le certificat protège. Un seul certificat peut couvrir à la fois example.com et www.example.com, voire des dizaines de sous-domaines. Une discordance entre le nom d'hôte auquel vous vous connectez et la liste des SAN déclenche une erreur de non-concordance du nom.
- Chaîne de confiance — Les navigateurs font confiance à un petit ensemble de CA racines préinstallées dans le système d'exploitation. Votre certificat de serveur n'est presque jamais signé directement par une racine ; il est plutôt signé par une CA intermédiaire, elle-même signée par la racine. Le serveur doit envoyer la chaîne complète — certificat feuille plus tous les certificats intermédiaires — afin que les navigateurs puissent construire le chemin de confiance. Un intermédiaire manquant est l'une des causes les plus courantes d'erreurs de certificat sur les appareils mobiles.
- Type de clé et algorithme de signature — Le vérificateur affiche l'algorithme de clé publique (RSA 2048 bits ou RSA 4096 bits étant les plus courants ; ECDSA P-256 gagne en popularité pour ses performances) et l'algorithme de signature utilisé par la CA (SHA-256 avec RSA, par exemple). Les signatures SHA-1 sont dépréciées depuis 2017 et provoqueront des erreurs de navigateur ; SHA-256 est la norme actuelle.
Ce que cet outil vérifie
- Validité du certificat — si le certificat est actuellement valide et non expiré.
- Correspondance du domaine — vérifie si le certificat couvre bien le domaine que vous avez saisi.
- Chaîne de certification — si la chaîne de confiance, du certificat jusqu'à une autorité racine, est complète.
- Date d'expiration — combien de jours restent avant l'expiration du certificat.
- Informations sur l'émetteur — quelle autorité de certification a délivré le certificat.
Comment utiliser cet outil
Saisissez un nom de domaine (comme example.com) et l'outil se connecte au serveur, récupère le certificat SSL et en affiche les détails. Vous obtiendrez le sujet, l'émetteur, les dates de validité, le type de certificat (DV, OV, EV) ainsi que les éventuels problèmes de configuration. Servez-vous-en pour surveiller vos propres certificats ou vérifier qu'un site auquel vous comptez confier des données est bien sécurisé.
Types de certificats
Les certificats Domain Validation (DV) ne vérifient que la propriété du domaine et sont les plus répandus (utilisés notamment par Let's Encrypt). Les certificats Organization Validation (OV) vérifient l'organisation derrière le domaine. Les certificats Extended Validation (EV) imposent la vérification la plus poussée. Les trois types offrent le même niveau de chiffrement — la différence porte uniquement sur la vérification d'identité du titulaire.
Erreurs de certificat courantes et leur signification
Les piles TLS des navigateurs et des serveurs sont strictes. Les erreurs suivantes sont les plus fréquemment rencontrées :
- Certificat expiré (NET::ERR_CERT_DATE_INVALID) — La date actuelle dépasse l'horodatage notAfter. La connexion est bloquée par défaut dans tous les navigateurs principaux. Correction : renouvelez le certificat immédiatement. Si vous utilisez Let's Encrypt, exécutez certbot renew ou vérifiez pourquoi votre tâche cron ou votre minuterie systemd de renouvellement automatique a échoué.
- Non-concordance du nom d'hôte (NET::ERR_CERT_COMMON_NAME_INVALID) — Le domaine dans la barre d'adresse n'apparaît pas dans la liste SAN du certificat. Causes courantes : le certificat a été émis pour www.example.com mais le site est aussi servi depuis example.com (sans www), ou un ancien certificat a été laissé sur un serveur après un changement de domaine. Correction : réémettre le certificat en incluant tous les noms d'hôtes requis.
- Certificat auto-signé — Le certificat a été signé par la même clé qu'il protège, plutôt que par une CA de confiance. Les navigateurs n'ont aucun moyen de vérifier l'identité et affichent donc un avertissement « certificat non fiable ». Les certificats auto-signés sont acceptables sur les réseaux internes et les environnements de développement, mais ne doivent jamais être utilisés sur des sites de production accessibles au public.
- Racine non fiable — Le certificat a été émis par une CA qui ne figure pas dans le magasin de confiance du navigateur ou du système d'exploitation. Cela peut se produire avec des CA privées, certaines CA nationales retirées des magasins de confiance, ou lors de l'utilisation d'une CA nouvellement créée dont le certificat racine n'est pas encore largement distribué. Correction : basculez vers une CA publique reconnue.
- Chaîne de certificats incomplète — Le serveur n'envoie que le certificat feuille sans les certificats de CA intermédiaires requis. Le navigateur ne peut pas construire le chemin de confiance jusqu'à une CA racine. Les navigateurs de bureau récupèrent parfois l'intermédiaire manquant via AIA (Authority Information Access), mais les navigateurs mobiles et de nombreux clients API ne le font pas. Correction : configurez votre serveur web (nginx, Apache, Caddy) pour qu'il serve le bundle de chaîne complet.
Renouvellement des certificats et automatisation
Let's Encrypt, la CA gratuite, automatisée et ouverte gérée par l'Internet Security Research Group (ISRG), a transformé la gestion des certificats. Les certificats Let's Encrypt ont une durée de validité de 90 jours par conception — cette courte durée de vie limite les dommages en cas de compromission d'une clé privée et encourage l'automatisation. Le protocole ACME (Automated Certificate Management Environment, RFC 8555) permet à un client comme Certbot, acme.sh ou un répartiteur de charge cloud de prouver automatiquement le contrôle du domaine (via des défis HTTP-01 ou DNS-01) et d'obtenir un nouveau certificat sans intervention humaine. Lorsqu'il est correctement configuré, les clients ACME renouvellent les certificats environ 30 jours avant leur expiration, rendant le renouvellement manuel inutile.
Même avec l'automatisation, la surveillance reste essentielle. L'automatisation peut échouer silencieusement en raison de modifications du pare-feu, d'une mauvaise configuration DNS, d'un épuisement des limites de débit ou d'un compte de service expiré. La bonne pratique consiste à mettre en place un moniteur d'expiration externe — une tâche cron, un service tiers ou un outil de disponibilité — qui vous alerte lorsque la validité restante d'un certificat tombe en dessous de 21 jours. Détecter un renouvellement échoué alors qu'il vous reste encore trois semaines de marge est bien moins stressant que de découvrir un certificat expiré signalé par vos utilisateurs.
Erreurs courantes à éviter
- Se fier aux rappels de calendrier plutôt qu'à l'automatisation — Les renouvellements gérés manuellement échouent lorsque l'ingénieur responsable est en congé ou change d'emploi. Utilisez un client ACME avec une minuterie systemd ou une tâche cron, et vérifiez que la tâche s'exécute bien.
- Déployer une chaîne de certificats incomplète — Copier uniquement le certificat feuille sur le serveur en omettant les certificats intermédiaires provoque des erreurs sur les appareils mobiles et les clients non-navigateurs, même si Chrome de bureau semble fonctionner correctement (il récupère silencieusement l'intermédiaire manquant).
- Oublier les sous-domaines — Émettre un certificat pour example.com mais pas pour www.example.com, ou inversement, génère des erreurs de non-concordance du nom d'hôte. Utilisez un certificat wildcard (*.example.com) ou un certificat SAN listant tous les noms d'hôtes requis.
- Ignorer les avertissements d'expiration — De nombreux clients ACME envoient un e-mail d'avertissement lorsqu'un certificat est proche de son expiration et que le renouvellement automatique n'a pas été exécuté. Ces e-mails sont faciles à manquer dans une boîte de réception surchargée. Configurez un canal d'alerte dédié (Slack, PagerDuty ou similaire) pour les notifications d'expiration de certificat.
Questions fréquentes
Que se passe-t-il quand un certificat SSL expire ?
Les navigateurs affichent un avertissement de sécurité bien visible qui dissuade les visiteurs de poursuivre. La plupart des utilisateurs préfèrent partir plutôt que de contourner l'avertissement, ce qui entraîne une perte importante de trafic. Les moteurs de recherche peuvent également déclasser le site dans les résultats. Les outils modernes comme Let's Encrypt et Certbot automatisent le renouvellement afin d'éviter toute expiration accidentelle.
SSL et TLS, c'est la même chose ?
SSL est l'ancien protocole (dernière version : SSL 3.0 de 1996). TLS est le successeur moderne (actuel : TLS 1.3). Toutes les versions de SSL sont aujourd'hui considérées comme non sécurisées et obsolètes. Lorsqu'on dit SSL aujourd'hui, on désigne en général TLS. Les certificats restent couramment appelés certificats SSL même si c'est TLS qui assure le chiffrement réel.
Qu'est-ce qu'une chaîne de certificats et pourquoi est-elle importante ?
Une chaîne de certificats (ou chaîne de confiance) est la séquence de certificats allant du certificat feuille de votre serveur jusqu'à une CA racine de confiance. Les navigateurs ne font confiance qu'à un petit nombre de CA racines, mais ces racines signent des CA intermédiaires, qui à leur tour signent des certificats de serveur. Votre serveur web doit envoyer le certificat feuille ainsi que tous les certificats intermédiaires lors de la négociation TLS. Si un intermédiaire est manquant, les clients qui ne l'ont pas en cache ne pourront pas vérifier le certificat et afficheront une erreur — même si le certificat lui-même est parfaitement valide.
Quelle est la durée de validité des certificats SSL/TLS ?
Les certificats publics approuvés par les navigateurs ont une validité maximale de 398 jours (environ 13 mois), telle que l'impose le CA/Browser Forum depuis septembre 2020. Let's Encrypt émet des certificats valables 90 jours pour encourager l'automatisation. Les certificats de CA internes ou privées peuvent avoir des durées de validité plus longues, mais la bonne pratique est de les limiter à deux ans. Des certificats à durée de vie plus courte réduisent la fenêtre d'exposition en cas de compromission d'une clé privée.