Testssl.sh peut-il scanner des serveurs accessibles uniquement depuis un réseau privé ?

Oui, c'est précisément l'un des avantages majeurs de testssl.sh par rapport à SSL Labs. Depuis un poste dans le même réseau que le serveur cible, vous pouvez scanner n'importe quelle IP privée ou nom DNS interne. C'est indispensable pour les applications métier hébergées en interne, les équipements réseau avec interface HTTPS (switch, firewall, NAS), ou les environnements de staging isolés. Aucune configuration particulière n'est requise — utilisez directement l'IP ou le FQDN interne avec le num

Testssl.sh est-il légal à utiliser sur des serveurs tiers ?

Testssl.sh envoie des requêtes TLS réelles au serveur cible — techniquement similaires à une connexion HTTPS normale mais plus nombreuses. L'utiliser sur vos propres serveurs est bien sûr légal. Sur des serveurs tiers, appliquez les mêmes règles qu'un scan de ports : sans autorisation explicite du propriétaire, c'est juridiquement risqué en France (article 323-1 du Code pénal sur l'accès non autorisé à un système informatique). Pour les pentests autorisés, testssl.sh est un outil standard — ment

Quelle différence entre testssl.sh et sslscan ou sslyze ?

Les trois outils remplissent le même rôle mais avec des différences. sslscan (C) est le plus rapide pour un résultat basique, mais moins complet sur les vulnérabilités. sslyze (Python) est très bien intégré dans des scripts Python et produit un output JSON propre, idéal pour des traitements programmatiques. testssl.sh est le plus complet en termes de tests de vulnérabilités et de couverture des ciphers, avec la meilleure lisibilité humaine. Pour un audit complet ou une conformité PCI-DSS, testss

Comment interpréter le grade dans le rapport testssl.sh ?

Contrairement à SSL Labs qui attribue une note A/B/C/D/F, testssl.sh n'attribue pas de grade global. Il colore chaque résultat en vert (OK/bon), jaune (avertissement/informationnel), orange (problème modéré) et rouge (vulnérable/critique). La sévérité globale d'un audit se lit via l'option --severity : si aucun résultat HIGH ou CRITICAL n'est rouge après un --severity HIGH , votre configuration est dans la norme. Pour obtenir une note chiffrée comparable à SSL Labs, combinez testssl.sh avec un s

Testssl.sh détecte-t-il les problèmes de certificat Let's Encrypt expiré ?

Oui. La section \"Certificate\" du rapport affiche la date d'expiration du certificat, le nombre de jours restants, et lève une alerte si le certificat est expiré ou expire dans moins de 30 jours. Pour un monitoring continu de l'expiration des certificats de votre parc, scriptez testssl.sh avec --protocols (test rapide) sur une liste de serveurs et parsez le JSON pour extraire les dates d'expiration. Déclenchez une alerte PagerDuty/Opsgenie si un certificat expire dans moins de 14 jours.

Testssl.sh : auditer la configuration TLS/SSL de vos serveurs web

14 juin 2026

Mis à jour le 11 septembre 2026

13 min de lecture

14 mots

424 vues

Guide complet testssl.sh pour auditer TLS/SSL : installation, protocoles obsolètes, vulnérabilités (Heartbleed, POODLE, ROBOT), intégration CI/CD et comparaison SSL Labs.

TL;DR — En résumé

Testssl.sh s'impose comme la référence open source pour auditer localement la configuration TLS/SSL d'un serveur, sans transmettre de données à un tiers contrairement à SSL Labs. L'outil détecte plus de 20 vulnérabilités historiques (Heartbleed, POODLE, ROBOT, BEAST, DROWN, CRIME) ainsi que les protocoles obsolètes SSLv2/v3 et TLS 1.0/1.1, encore actifs sur nombre de serveurs de production malgré leur abandon par les navigateurs modernes. Il vérifie également la chaîne de certificats, les suites cryptographiques et les en-têtes HSTS, avec alerte automatique en cas d'expiration proche. Son intégration en pipeline CI/CD permet un contrôle continu, essentiel pour répondre aux exigences NIS2 et PCI-DSS v4 qui imposent désormais TLS 1.2 minimum. Sans notation chiffrée native, il peut être couplé à un script de scoring personnalisé pour se rapprocher du format SSL Labs.

Audit TLS $(date +%d/%m/%Y)

" > "${REPORT_DIR}/summary.html" echo "

Serveurs avec vulnérabilités : $FAILURES

#SOC et Detection

Partager cet article

Twitter LinkedIn

À propos de l'auteur

Ayi NEDJIMI

Auditeur Senior Cybersécurité & Consultant IA

Expert Judiciaire — Cour d'Appel de Paris
Habilitation Confidentiel Défense

ayi@ayinedjimi-consultants.fr

25+

ans d'expérience

700+

articles publiés

100+

missions réalisées

Ayi NEDJIMI est un vétéran de la cybersécurité avec plus de 25 ans d'expérience sur des missions critiques. Ancien développeur Microsoft à Redmond sur le module GINA (Windows NT4) et co-auteur de la version française du guide de sécurité Windows NT4 pour la NSA.

À la tête d'Ayi NEDJIMI Consultants, il réalise des audits Lead Auditor ISO 42001 et ISO 27001, des pentests d'infrastructures critiques, du forensics et des missions de conformité NIS2 / AI Act.

Conférencier international (Europe & US), il a formé plus de 10 000 professionnels.

Domaines d'expertise

ISO 42001 Lead Auditor ISO 27001 · NIS2 Pentest & Forensics IA / LLM / RAG Cloud & Active Directory

Voir le profil complet Demander un devis

Ressources & Outils de l'auteur

GitHub

Code & projets open source

ORCID

Identifiant chercheur

Hugging Face

Modèles IA & datasets

CertifExpress

Préparez vos certifications IT

WindowsBooster

Optimisation Windows 11

Commentaires

Aucun commentaire pour le moment. Soyez le premier à commenter !

Laisser un commentaire

Testssl.sh : auditer la configuration TLS/SSL de vos serveurs web

Audit TLS $(date +%d/%m/%Y)

À propos de l'auteur

Ayi NEDJIMI

Ressources & Outils de l'auteur

Articles connexes

Tracking d'un APT avec Copilot Security et Microsoft MDTI : chasse aux menaces persistantes

Prompts généraux Copilot Security : administration, formation et productivité SOC

Prompts Copilot Security pour Microsoft MDTI : Threat Intelligence opérationnelle

Un projet cybersécurité ? Parlons-en.

Commentaires