Le vérificateur SSL ci-dessus effectue un diagnostic complet sur tout certificat SSL/TLS accessible au public et génère un rapport détaillé couvrant la note de sécurité, la chaîne de certificats, les suites de chiffrement, les analyses de vulnérabilités et la compatibilité avec les navigateurs. Les sections ci-dessous expliquent comment lire chaque partie du rapport.
Comprendre votre note de sécurité SSL
Chaque analyse effectuée par le vérificateur SSL produit une note alphabétique allant de A+ à F, accompagnée d’un score numérique sur 100.
- Une note A ou A+ signifie que le certificat est correctement installé, utilise une cryptographie moderne et que le serveur dispose des bonnes fonctionnalités de sécurité activées.
- Les certificats de grade B sont fonctionnels mais révèlent des possibilités de renforcement.
- Les notes C et inférieures indiquent généralement une version TLS obsolète, une fonctionnalité de sécurité manquante ou un certificat sur le point d’expirer.
Le score est pondéré selon cinq catégories :
- Certificat (validité et algorithme)
- Confiance (autorité de certification reconnue et intégrité de la chaîne)
- Protocole (versions TLS prises en charge, protocoles obsolètes désactivés)
- Fonctionnalités (HSTS, OCSP Stapling, Perfect Forward Secrecy, CAA)
- Validité (temps restant avant expiration)
La plupart des baisses de note proviennent de la catégorie Fonctionnalités. Le certificat fonctionne, la chaîne est correcte, le protocole est à jour, mais HSTS n’est pas configuré ou un enregistrement CAA n’est pas publié. Ce sont des corrections côté serveur et côté DNS, et non des problèmes de certificat.
Lire les détails de votre certificat
Le vérificateur SSL décompose chaque certificat de la chaîne champ par champ.
Common Name — le domaine principal pour lequel le certificat est émis. Il doit correspondre à l’URL vérifiée, sinon le navigateur rejette la connexion.
Issued By — l’intermédiaire émetteur ainsi que l’autorité de certification parente. Les noms reconnus tels que Sectigo, DigiCert, GeoTrust ou Google Trust Services sont automatiquement approuvés. Les émetteurs peu connus ou tout certificat « auto-signé » déclencheront un avertissement.
Valid From / Valid To — la fenêtre de validité du certificat. Valid From est plus important qu’on ne le pense : si l’horloge d’un serveur est incorrecte ou qu’un certificat est installé trop tôt, les navigateurs le rejettent comme n’étant pas encore valide.
Signature Algorithm — les certificats modernes utilisent SHA-256, SHA-384 ou ecdsa-with-SHA256. SHA-1 a été déprécié il y a plusieurs années et tout certificat l’utilisant encore doit être réémis.
Public Key — RSA 2048 bits ou supérieur est la norme. ECC 256 bits est l’alternative moderne et produit des certificats plus petits et plus rapides.
SAN (Subject Alternative Name) — noms d’hôtes supplémentaires couverts par le certificat. Les wildcards tels que *.example.com couvrent tous les sous-domaines de premier niveau. Les certificats multi-domaines listent ici chaque nom d’hôte protégé. Pour les certificats DV, OV ou EV, la liste SAN définit exactement les domaines pour lesquels le certificat sera validé.
Les fonctionnalités de sécurité des certificats SSL expliquées
Au-delà du certificat lui-même, le vérificateur SSL rend compte d’un ensemble de six fonctionnalités de sécurité.
OCSP Stapling — le serveur récupère à l’avance son propre statut de révocation auprès de la CA et l’inclut dans la négociation TLS sur le port 443. « Not Supported » ajoute de la latence à chaque connexion. Il s’agit généralement d’une modification de configuration en une seule ligne dans Apache, Nginx ou IIS.
Perfect Forward Secrecy (PFS) — chaque session utilise une clé unique, de sorte qu’une future compromission de clé privée ne peut pas déchiffrer le trafic passé. « Not Supported » signifie que les sessions enregistrées pourraient être déchiffrées rétroactivement. Activez cette fonctionnalité en privilégiant les suites de chiffrement ECDHE.
Certificate Transparency (CT) — les certificats émis sont enregistrés dans des journaux CT publics, permettant aux propriétaires de domaines de détecter les émissions incorrectes. « Not Supported » sur un certificat public est inhabituel.
HSTS (HTTP Strict Transport Security) — un en-tête de réponse serveur indiquant aux navigateurs de refuser les connexions HTTP en clair. Sans HSTS, un attaquant peut déclasser un visiteur de HTTPS et intercepter le trafic. Ajoutez un en-tête Strict-Transport-Security dans la configuration du serveur web.
Certificate Revocation Status — le vérificateur interroge OCSP et CRL pour confirmer que le certificat n’a pas été révoqué. « Good » = actif. « Revoked » = les navigateurs le rejetteront, réémettez-le immédiatement. « Unknown » sur CRL est courant et ne pose pas de problème si OCSP retourne Good.
DNS CAA Record — un enregistrement DNS listant les autorités de certification autorisées à émettre des certificats pour le domaine. Sans cet enregistrement, n’importe quelle CA pourrait techniquement émettre un certificat. Ajoutez un enregistrement CAA chez votre fournisseur DNS en y listant vos CA.
Résultats de l’analyse des vulnérabilités TLS
Cinq vulnérabilités TLS nommées sont analysées. La plupart des serveurs ont été corrigés il y a des années, de sorte que le vérificateur SSL confirme généralement l’absence de problème.
Heartbleed (CVE-2014-0160) — un bug de lecture mémoire dans OpenSSL qui exposait les clés privées. « Safe » signifie que le serveur utilise une version corrigée d’OpenSSL.
POODLE (CVE-2014-3566) — une attaque par oracle de rembourrage contre SSLv3. « Safe » signifie que SSLv3 est désactivé.
BEAST (CVE-2011-3389) — une faille de chiffrement par blocs en mode CBC dans TLS 1.0. « Safe » signifie que TLS 1.0 est désactivé ou que le serveur utilise des suites de chiffrement non vulnérables.
ROBOT (CVE-2017-13099) — Return Of Bleichenbacher’s Oracle Threat. Une faille de rembourrage RSA réapparue dans de nombreuses implémentations de fournisseurs. « Safe » signifie que le serveur n’expose pas d’échange de clés vulnérable.
Ticketbleed (CVE-2016-9244) — divulgation de mémoire spécifique aux équipements F5 BIG-IP via les tickets de session TLS. « Safe » signifie qu’aucun équipement F5 non corrigé n’est présent.
Suites de chiffrement et prise en charge des protocoles
Le vérificateur SSL regroupe les suites de chiffrement prises en charge sous TLS 1.3, TLS 1.2 et Faibles.
- TLS 1.3 dispose d’une liste restreinte de suites conçues pour être robustes.
- La qualité des suites de chiffrement TLS 1.2 varie, c’est pourquoi chaque suite est énumérée individuellement.
- La colonne Faibles signale les protocoles ou chiffrements obsolètes qui doivent être désactivés : SSLv3, TLS 1.0, TLS 1.1, RC4, 3DES, ainsi que tout chiffrement NULL ou EXPORT.
Les noms des suites de chiffrement suivent une structure prévisible. Dans TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 :
- ECDHE est l’échange de clés (assurant le Perfect Forward Secrecy)
- ECDSA est l’algorithme de signature
- AES_256_GCM est le chiffrement symétrique
- SHA384 est la fonction de hachage
AES 128 bits et 256 bits sont tous deux sécurisés.
Validation de la chaîne de certificats
Le rapport affiche la chaîne de certificats complète en trois niveaux :
- Certificat serveur
- Certificat intermédiaire
- Certificat racine
Chaque niveau est signé par celui qui le précède, et la chaîne doit se terminer par une racine déjà approuvée par le navigateur.
« Chain Complete » signifie que les navigateurs peuvent remonter du serveur à la racine sans problème.
« Incomplete » signifie qu’un ou plusieurs certificats intermédiaires sont absents de ce que le serveur envoie, de sorte que les navigateurs ne peuvent pas relier le certificat à une racine de confiance et les visiteurs voient un avertissement de sécurité.
Les chaînes incomplètes constituent l’un des problèmes d’installation SSL les plus courants, et le vérificateur SSL les signale en haut du rapport. La solution consiste presque toujours à réinstaller en utilisant le bundle de chaîne complète fourni par la CA. Les procédures varient selon le serveur : Apache utilise une directive de fichier de chaîne tandis que Nginx attend un fichier fullchain.pem. IIS gère la reconstruction de la chaîne via l’assistant d’importation de certificat.
Vérifier l’expiration des certificats SSL
Le vérificateur SSL affiche l’expiration à deux endroits : le résumé en haut indique les jours restants et la date Valid To, et chaque certificat de la chaîne affiche sa propre fenêtre de validité.
Conformément au Ballot SC-081v3 du CA/Browser Forum, les durées de vie des certificats SSL/TLS publics sont progressivement réduites. À compter du 15 mars 2026, la validité maximale est passée de 398 jours à 200 jours. Elle tombera à 100 jours à partir du 15 mars 2027, puis à 47 jours à partir du 15 mars 2029.
Avec un certificat de 200 jours, des vérifications mensuelles accompagnées d’un rappel à 30 jours suffisent. Lorsque les certificats de 47 jours seront en vigueur, le renouvellement manuel deviendra impraticable. La solution standard est l’automatisation basée sur ACME, qui permet au serveur de demander et de renouveler les certificats sans intervention manuelle.
Compatibilité avec les navigateurs – quand cela compte
Le vérificateur SSL teste le certificat sur 13 combinaisons de navigateurs et d’appareils. Les navigateurs modernes (Chrome 80+, Firefox 80+, Safari 14+, Edge 80+, Opera 70+, Safari iOS 15+, Android 10+) doivent toujours afficher Supported pour un certificat actuel.
Les anciennes plateformes mobiles comme Android 5-7 et iOS 12 affichent souvent une prise en charge partielle. L’importance de ce constat dépend du public visé. Les anciens navigateurs de bureau comme Internet Explorer 10 et 11 échouent presque toujours avec les certificats modernes car ils ne prennent pas en charge TLS 1.2 par défaut. Un score de 9/13 avec tous les navigateurs modernes en vert est normal en 2026.
Quand effectuer une vérification SSL
Une seule vérification après l’installation ne suffit pas. Utilisez le vérificateur SSL :
- Après l’installation d’un nouveau certificat
- 30 jours avant l’expiration sur un cycle de 200 jours
- Après chaque renouvellement ou réémission
- Après une migration de serveur ou un changement d’IP
- Après avoir changé d’autorité de certification
- Après être passé à une configuration wildcard ou multi-domaine
- Après avoir activé HSTS, OCSP Stapling ou toute modification de la configuration TLS
Questions fréquemment posées
Mensuel est une base raisonnable. Avec les certificats de 200 jours maintenant au maximum, définissez une alerte stricte pour effectuer une vérification complète 30 jours avant l’expiration. Effectuez une vérification supplémentaire après les renouvellements, car les erreurs de chaîne de certificats sont le problème post-renouvellement le plus courant.
Copier le lien
Visez une note A ou A+. Une note B fonctionne dans tous les navigateurs, mais l’écart pointe généralement vers des problèmes corrigeables. La plupart des baisses de notation remontent à deux éléments que le SSL checker signale dans le panneau des fonctionnalités de sécurité : un en-tête HSTS manquant ou un enregistrement CAA non configuré. Aucun des deux ne nécessite de modifier le certificat.
Copier le lien
Votre serveur n’envoie pas tous les certificats intermédiaires dont les navigateurs ont besoin. La solution rapide : Apache utilise SSLCertificateChainFile ou un bundle combiné, Nginx attend un fichier fullchain.pem, et IIS reconstruit la chaîne via l’assistant d’importation de certificat.
Copier le lien
Non, les vérificateurs publics ne peuvent pas accéder aux hôtes internes derrière les pare-feu. À partir d’une machine sur le même réseau, exécutez openssl s_client -connect host:443 -servername host pour obtenir un résultat équivalent. L’outil en ligne de commande OpenSSL est fourni avec la plupart des distributions Linux et est disponible pour Windows.
Copier le lien
Oui. Il lit n’importe quel certificat que le serveur présente, de Sectigo, DigiCert, GeoTrust, RapidSSL, Thawte, GoGetSSL, Let’s Encrypt, Google Trust Services, et autres. Le catalogue de certificats SSL de SSL Dragon couvre six de ces CA côte à côte.
Copier le lien
HSTS est un en-tête de réponse du serveur, pas une partie du certificat. Le certificat peut être parfaitement valide tandis que HSTS reste non configuré. Ajoutez-le dans la configuration du serveur web : Apache utilise Header always set Strict-Transport-Security, Nginx utilise add_header Strict-Transport-Security.
Copier le lien
