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

La configuration TLS/SSL d'un serveur web est l'un des éléments de sécurité les plus critiques et les plus souvent négligés. Une mauvaise configuration — protocoles obsolètes activés, suites cryptographiques faibles, certificats mal chaînés — peut exposer les communications de vos utilisateurs à des attaques de déchiffrement actives ou passives. Les conséquences vont de la compromission de sessions authentifiées à l'interception de données personnelles, en passant par la perte de référencement (Google pénalise les sites HTTP ou présentant des alertes de sécurité). Testssl.sh s'est imposé comme l'outil open source de référence pour auditer exhaustivement la sécurité TLS d'un serveur : il teste les protocoles supportés, les suites cryptographiques, la validité des certificats, la présence des en-têtes de sécurité et la vulnérabilité à une vingtaine d'attaques connues (BEAST, POODLE, DROWN, ROBOT, Heartbleed, et bien d'autres). Entièrement en ligne de commande, scriptable, intégrable dans vos pipelines CI/CD, testssl.sh offre une couverture de test comparable aux outils commerciaux. Ce guide vous présente son installation, sa syntaxe complète, l'interprétation des résultats et la correction des problèmes identifiés sur Apache, Nginx et IIS. Vous aurez en fin de lecture toutes les clés pour obtenir une note A+ sur SSLLabs et une configuration TLS conforme aux recommandations ANSSI et BSI.

Installer testssl.sh sur Linux, macOS et via Docker

Testssl.sh est un script Bash qui nécessite OpenSSL pour effectuer ses tests. L'installation est simple sur les systèmes Unix, et une image Docker est disponible pour les environnements Windows ou les pipelines CI/CD.

Installation sur Linux (Debian/Ubuntu) :

# Dépendances : bash, openssl, bind-utils (dig), nmap (optionnel)
sudo apt update && sudo apt install -y openssl dnsutils curl

# Cloner le dépôt officiel (version stable recommandée)
git clone --depth 1 https://github.com/drwetter/testssl.sh.git
cd testssl.sh
chmod +x testssl.sh

# Vérifier l'installation
./testssl.sh --version

Sur CentOS/RHEL/Rocky Linux :

sudo dnf install -y openssl bind-utils curl git
git clone --depth 1 https://github.com/drwetter/testssl.sh.git

Sur macOS (via Homebrew) :

brew install openssl@3 bash
git clone --depth 1 https://github.com/drwetter/testssl.sh.git
cd testssl.sh
# Spécifier bash de Homebrew si la version macOS est trop ancienne
/usr/local/bin/bash testssl.sh --version

Via Docker (recommandé pour CI/CD) :

# Utiliser l'image officielle
docker run --rm -ti drwetter/testssl.sh example.com:443

# Sauvegarder les résultats
docker run --rm -v $(pwd)/results:/results drwetter/testssl.sh --jsonfile /results/output.json example.com:443

Version d'OpenSSL requise : Testssl.sh fonctionne mieux avec OpenSSL 1.1.1 ou supérieur (1.1.1w ou OpenSSL 3.x recommandé). Vérifiez votre version avec openssl version. Une version trop ancienne peut empêcher le test de certaines suites cryptographiques modernes (TLS 1.3, CHACHA20).

Syntaxe de base et première utilisation

La syntaxe de testssl.sh est intuitive. La commande de base pour tester un serveur HTTPS est :

./testssl.sh https://votre-serveur.fr
# ou équivalent
./testssl.sh votre-serveur.fr:443

Testssl.sh effectue alors une batterie complète de tests et affiche les résultats en temps réel avec un code couleur : vert (OK), jaune (avertissement), rouge (problème), et bordeaux (critique).

Options de base :

# Test complet avec sortie JSON
./testssl.sh --json-pretty --jsonfile results.json votre-serveur.fr:443

# Test complet avec rapport HTML
./testssl.sh --htmlfile rapport.html votre-serveur.fr:443

# Test d'une IP spécifique avec SNI (Virtual Hosting)
./testssl.sh --ip 192.168.1.100 --sni votre-serveur.fr votre-serveur.fr:443

# Test d'un serveur derrière un proxy
./testssl.sh --proxy socks5://127.0.0.1:1080 votre-serveur.fr:443

# Mode verbeux (affiche les certificats, les handshakes détaillés)
./testssl.sh -v votre-serveur.fr:443

Tester uniquement certains aspects (pour des audits ciblés) :

# Uniquement les protocoles
./testssl.sh -p votre-serveur.fr:443

# Uniquement les cipher suites
./testssl.sh -E votre-serveur.fr:443

# Uniquement les vulnérabilités connues
./testssl.sh -U votre-serveur.fr:443

# Uniquement les en-têtes HTTP security headers
./testssl.sh -h votre-serveur.fr:443

Analyser les protocoles supportés

Le premier test effectué par testssl.sh concerne les protocoles SSL/TLS supportés par le serveur. C'est l'élément le plus fondamental de la sécurité TLS.

Protocoles à bannir absolument :

• SSLv2 : obsolète depuis 1996, vulnérable à de nombreuses attaques, doit être désactivé. Si votre serveur supporte encore SSLv2 en 2026, c'est une urgence absolue.
• SSLv3 : obsolète depuis 2015 (RFC 7568), vulnérable à POODLE. À désactiver immédiatement.
• TLS 1.0 : déprécié par le PCI DSS depuis 2018, par RFC 8996 en 2021. Vulnérable à BEAST (côté client) et POODLE-TLS. À désactiver sauf contrainte forte de compatibilité legacy.
• TLS 1.1 : déprécié par RFC 8996 en 2021. Les navigateurs modernes (Chrome 98+, Firefox 97+) ont cessé de le supporter. À désactiver.

Protocoles recommandés :

• TLS 1.2 : standard actuel, sécurisé avec les bonnes suites cryptographiques. Doit rester activé pour la compatibilité avec les clients un peu anciens.
• TLS 1.3 : le protocole le plus moderne (RFC 8446, 2018). Supprime les vecteurs d'attaque hérités, améliore les performances (0-RTT optionnel), n'utilise que des algorithmes modernes. À activer impérativement.

Interprétation des résultats testssl.sh pour les protocoles :

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      not offered (OK)
 TLS 1.1    not offered (OK)
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK)

Ce résultat est idéal. Si TLS 1.0 ou TLS 1.1 apparaît en vert "offered", corrigez immédiatement la configuration.

Auditer les suites cryptographiques (cipher suites)

Les suites cryptographiques définissent les algorithmes utilisés pour l'échange de clés, l'authentification, le chiffrement symétrique et l'intégrité des données. Leur sélection est cruciale pour la sécurité et la performance.

Testssl.sh liste toutes les suites supportées avec un code couleur : vert (recommandée), jaune (acceptable), rouge (faible), bordeaux (à proscrire).

Suites à proscrire :

• Suites NULL ou aNULL : pas de chiffrement ou pas d'authentification.
• Suites EXPORT : clés délibérément affaiblies (legacy US export restrictions).
• Suites RC4 : chiffrement stream obsolète, vulnérable à des attaques statistiques.
• Suites DES/3DES : vulnérables à SWEET32 (birthday attack sur les blocs 64 bits).
• Suites MD5 : fonction de hachage brisée.
• Suites sans Perfect Forward Secrecy (PFS) : échanges RSA statiques (non-DHE, non-ECDHE). Si la clé privée est compromise a posteriori, tout le trafic passé peut être déchiffré.

Recommandations ANSSI (Guide TLS 2024) :

• Pour TLS 1.3 : toutes les suites sont considérées sûres (TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256).
• Pour TLS 1.2 : privilégier ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256.

Tester les cipher suites avec testssl.sh :

# Lister toutes les cipher suites supportées
./testssl.sh -e votre-serveur.fr:443

# Identifier les suites faibles uniquement
./testssl.sh -E votre-serveur.fr:443 | grep -E "WEAK|DES|RC4|EXPORT|NULL"

Vérifier le certificat TLS

Testssl.sh effectue une vérification complète du certificat présenté par le serveur. Un certificat mal configuré peut provoquer des erreurs chez les utilisateurs ou permettre des attaques man-in-the-middle.

Points vérifiés automatiquement :

• Expiration : testssl.sh avertit si le certificat expire dans moins de 60 jours.
• Chaîne de certification : vérifie que les certificats intermédiaires sont bien fournis par le serveur (un certificat "feuille" seul sans les intermédiaires provoque des erreurs sur certains clients).
• Subject Alternative Names (SAN) : vérifie que le nom de domaine testé correspond à un SAN déclaré dans le certificat (les certificats wildcard et multi-domaines sont vérifiés).
• Transparence des certificats (Certificate Transparency) : vérifie la présence de SCT (Signed Certificate Timestamps) prouvant que le certificat est enregistré dans des logs publics CT. Obligatoire pour Chrome depuis 2018.
• Révocation : vérifie via OCSP (Online Certificate Status Protocol) si le certificat n'a pas été révoqué.
• OCSP Stapling : vérifie si le serveur fournit lui-même la réponse OCSP (améliore les performances et la confidentialité).

Exemple de sortie pour un certificat :

 Certificate Validity (UTC)  2024-01-15 00:00 --> 2025-01-14 23:59 (expires in 211 days)
 # CN matches supplied URI  votre-serveur.fr (OK)
 Certificate Revocation     OCSP stapling: offered (OK)
 Certificate Transparency   yes (certificate extension)
 Chain of trust             Ok (passed)

Détecter les vulnérabilités TLS connues

C'est l'une des fonctionnalités les plus puissantes de testssl.sh : il teste automatiquement la présence d'une vingtaine de vulnérabilités TLS connues.

BEAST (Browser Exploit Against SSL/TLS) : Attaque contre TLS 1.0 avec CBC. Désactiver TLS 1.0 élimine ce risque côté serveur.

CRIME et BREACH : Attaques exploitant la compression TLS (CRIME) et la compression HTTP (BREACH) pour déduire les cookies de session. Désactivez la compression TLS et évitez de comprimer les réponses HTTP contenant des secrets.

POODLE (Padding Oracle On Downgraded Legacy Encryption) : Attaque contre SSLv3 et certaines implémentations CBC de TLS. Désactivez SSLv3 et utilisez le TLS Fallback SCSV (RFC 7507).

DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) : Si votre serveur partage sa clé privée RSA avec un service supportant SSLv2, DROWN permet de déchiffrer le trafic TLS. Désactivez SSLv2 sur tous les services utilisant la même clé.

Heartbleed (CVE-2014-0160) : Vulnérabilité dans l'extension Heartbeat d'OpenSSL permettant de lire la mémoire du serveur. Normalement corrigé depuis 2014, mais encore présent sur des serveurs non mis à jour.

ROBOT (Return Of Bleichenbacher's Oracle Threat) : Attaque permettant de déchiffrer le trafic RSA ou de forger des signatures RSA. Désactiver les suites RSA_PKCS1 élimine ce risque.

LOGJAM : Attaque contre l'échange de clés Diffie-Hellman 512 bits (DHE_EXPORT). Utiliser des paramètres DH d'au moins 2048 bits ou préférer ECDHE.

Exemple de sortie vulnérabilités :

 Heartbleed (CVE-2014-0160)    not vulnerable (OK)
 CCS (CVE-2014-0224)           not vulnerable (OK)
 ROBOT                         not vulnerable (OK)
 BEAST (CVE-2011-3389)         not vulnerable (OK) -- only BEAST testing TLS 1
 POODLE, SSL (CVE-2014-3566)   not vulnerable (OK)
 DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable (OK)
 LOGJAM (CVE-2015-4000)        not vulnerable (OK), DH 2048 bits
 SWEET32 (CVE-2016-2183, CVE-2016-6329) not vulnerable (OK)

Tester HSTS, HPKP et OCSP Stapling

Au-delà des protocoles et chiffrements, testssl.sh vérifie les mécanismes de sécurité HTTP qui renforcent la protection TLS.

HSTS (HTTP Strict Transport Security) : L'en-tête Strict-Transport-Security indique au navigateur de ne jamais se connecter en HTTP à ce domaine pendant la durée spécifiée (max-age). Testssl.sh vérifie la présence de l'en-tête, la valeur de max-age (recommandé : 31536000 = 1 an minimum) et les directives includeSubDomains et preload.

# Configuration HSTS recommandée (Nginx)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

HPKP (HTTP Public Key Pinning) : Déprécié et déconseillé depuis 2018 (risque de "suicide HPKP"), testssl.sh le signale comme informatif si présent. Ne pas implémenter HPKP en 2026.

OCSP Stapling : Permet au serveur de fournir lui-même la réponse OCSP (preuve que le certificat n'est pas révoqué) lors du handshake TLS, sans que le client n'ait à contacter l'autorité de certification. Améliore les performances et protège la vie privée (le client ne contacte plus l'AC pour chaque connexion).

# Configuration OCSP Stapling (Nginx)
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

Mode batch — auditer plusieurs serveurs automatiquement

Pour les organisations avec plusieurs serveurs à auditer, testssl.sh propose un mode batch qui permet de tester une liste de cibles et d'agréger les résultats.

Créer un fichier de cibles :

cat > /tmp/servers.txt << 'EOF'
www.entreprise.fr:443
mail.entreprise.fr:443
api.entreprise.fr:8443
vpn.entreprise.fr:443
EOF

Lancer le batch :

./testssl.sh --file /tmp/servers.txt --jsonfile /tmp/batch-results.json --severity HIGH

L'option --severity filtre les résultats pour n'afficher (et n'inclure dans le JSON) que les problèmes de sévérité HIGH ou CRITICAL. Utile pour des rapports executifs.

Parallélisation des tests :

# Tester plusieurs serveurs en parallèle (4 processus simultanés)
./testssl.sh --parallel --file /tmp/servers.txt --csv --csvfile /tmp/batch.csv

Analyse des résultats JSON :

# Extraire uniquement les problèmes critiques avec jq
cat /tmp/batch-results.json | jq '.[] | select(.severity == "CRITICAL" or .severity == "HIGH") | {host: .ip, id: .id, finding: .finding}'

Intégrer testssl.sh dans un pipeline CI/CD

Testssl.sh peut être intégré dans vos pipelines CI/CD pour détecter automatiquement les régressions de configuration TLS lors des déploiements.

Exemple GitLab CI (.gitlab-ci.yml) :

tls-audit:
  stage: security
  image: drwetter/testssl.sh:latest
  script:
    - testssl.sh --severity HIGH --jsonfile /tmp/tls-results.json $DEPLOY_URL
    - |
      CRITICAL=$(cat /tmp/tls-results.json | python3 -c "
      import json,sys
      data=json.load(sys.stdin)
      critical=[x for x in data if x.get('severity') in ['CRITICAL','HIGH']]
      print(len(critical))
      ")
      if [ "$CRITICAL" -gt "0" ]; then
        echo "ÉCHEC : $CRITICAL problèmes critiques TLS détectés"
        exit 1
      fi
  artifacts:
    paths: [/tmp/tls-results.json]
    when: always

Exemple cron de surveillance hebdomadaire :

# /etc/cron.weekly/tls-audit
#!/bin/bash
RESULTS=/var/log/tls-audit-$(date +%Y%m%d).json
/opt/testssl.sh/testssl.sh --severity MEDIUM --jsonfile $RESULTS --file /etc/tls-audit-servers.txt
# Envoyer par email si problèmes détectés
ISSUES=$(cat $RESULTS | python3 -c "import json,sys; d=json.load(sys.stdin); print(len([x for x in d if x.get('severity') in ['HIGH','CRITICAL']]))")
if [ "$ISSUES" -gt "0" ]; then
    mail -s "ALERTE TLS : $ISSUES problèmes détectés" [email protected] < $RESULTS
fi

Corriger les problèmes identifiés par testssl.sh

Une fois l'audit effectué, voici les corrections les plus courantes pour les serveurs web.

Configuration sécurisée Nginx (TLS 1.2 + TLS 1.3 uniquement, cipher suites modernes) :

server {
    listen 443 ssl;

    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    # Protocoles : TLS 1.2 et 1.3 uniquement
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cipher suites sécurisées (PFS obligatoire)
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off; # TLS 1.3 gère lui-même

    # Paramètres DH 2048 bits minimum
    ssl_dhparam /etc/nginx/dhparam.pem;  # Généré avec : openssl dhparam -out dhparam.pem 2048

    # HSTS
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /path/to/chain.pem;
}

Configuration sécurisée Apache :

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile /path/to/cert.pem
    SSLCertificateKeyFile /path/to/privkey.pem
    SSLCertificateChainFile /path/to/chain.pem

    SSLProtocol -all +TLSv1.2 +TLSv1.3
    SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
    SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
    SSLHonorCipherOrder off

    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

    SSLUseStapling on
    SSLStaplingCache "shmcb:/var/run/ocsp(128000)"
</VirtualHost>

Interpréter les résultats et prioriser les corrections

Face à un rapport testssl.sh contenant plusieurs dizaines de lignes, il est essentiel de savoir prioriser les corrections en fonction de leur impact réel sur la sécurité.

Ordre de priorité des corrections :

1. CRITIQUE (bordeaux/rouge) — corriger immédiatement : Heartbleed, DROWN, POODLE SSLv3, SSLv2 activé, certificat expiré ou révoqué. Ces vulnérabilités sont activement exploitables.
2. HAUTE (orange) — corriger sous 7 jours : TLS 1.0/1.1 activés, suites RC4 ou DES présentes, absence de HSTS, certificats auto-signés, ROBOT.
3. MOYENNE (jaune) — corriger dans le prochain cycle de maintenance : Absence d'OCSP Stapling, paramètres DH inférieurs à 2048 bits, absence de Certificate Transparency, BEAST potentiel.
4. INFORMATIF (bleu/blanc) — amélioration optionnelle : Support TLS 1.3 absent (le serveur fonctionne mais n'est pas optimal), absence de la directive preload HSTS.

Cas particulier des environnements avec contraintes de compatibilité : Certains environnements industriels, systèmes embarqués ou applications legacy ne supportent que TLS 1.0 ou des suites cryptographiques obsolètes. Dans ce cas, isolez ces flux dans des segments réseau dédiés, documentez les exceptions dans votre politique de sécurité, et planifiez la migration. Ne maintenez jamais TLS 1.0 activé sur un serveur public sans mesures compensatoires.

Générer un rapport de remédiation automatique :

# Exporter uniquement les problèmes HIGH et CRITICAL en CSV
./testssl.sh --severity HIGH --csvfile /tmp/remediation.csv votre-serveur.fr:443

# Générer un rapport HTML pour le RSSI
./testssl.sh --htmlfile /tmp/rapport-tls.html votre-serveur.fr:443

Valider les corrections après déploiement : Après avoir modifié la configuration TLS et rechargé le serveur (nginx -s reload ou systemctl reload apache2), relancez testssl.sh pour valider que les problèmes ont bien été résolus. C'est un cycle itératif : auditer → corriger → valider → répéter.

Automatiser la détection de régression dans un pipeline GitHub Actions :

name: TLS Security Audit
on:
  schedule:
    - cron: '0 6 * * 1'  # Chaque lundi à 6h
  push:
    branches: [main]

jobs:
  tls-audit:
    runs-on: ubuntu-latest
    steps:
      - name: Clone testssl.sh
        run: git clone --depth 1 https://github.com/drwetter/testssl.sh.git
      - name: Run TLS audit
        run: |
          cd testssl.sh
          ./testssl.sh --severity HIGH --jsonfile /tmp/results.json ${{ secrets.PROD_URL }}
      - name: Check for failures
        run: |
          ISSUES=$(cat /tmp/results.json | python3 -c "
          import json,sys
          d=json.load(sys.stdin)
          print(len([x for x in d if x.get('severity') in ['HIGH','CRITICAL']]))
          ")
          echo "Problèmes HIGH/CRITICAL : $ISSUES"
          [ "$ISSUES" -eq "0" ] || exit 1

Pour des audits réguliers de votre infrastructure, notre équipe propose des audits de sécurité complets incluant l'analyse TLS. Consultez également notre guide sur la sécurité des applications web et notre article sur la mise en place d'un WAF. La supervision de la conformité TLS fait partie de nos services SOC managés.

Ressources officielles : le site officiel testssl.sh et le dépôt GitHub de testssl.sh avec la documentation complète et les notes de version.

Questions fréquentes sur l'audit TLS avec testssl.sh

Testssl.sh peut-il tester des serveurs sur des ports non standard (autre que 443) ?

Oui, testssl.sh supporte tous les ports TCP. Spécifiez simplement le port dans la cible : ./testssl.sh votre-serveur.fr:8443 pour HTTPS alternatif, ./testssl.sh votre-serveur.fr:25 pour SMTP avec STARTTLS, ./testssl.sh votre-serveur.fr:993 pour IMAPS. Testssl.sh détecte automatiquement le protocole de la couche applicative (HTTP, SMTP, IMAP, POP3, LDAP, FTP, XMPP) et adapte ses tests en conséquence via l'option --starttls.

Quelle est la différence entre testssl.sh et SSLLabs (ssllabs.com) ?

SSLLabs est un service en ligne de Qualys qui génère un rapport TLS complet avec une note de A+ à F. Testssl.sh est son équivalent local, open source et scriptable. Les différences principales : testssl.sh peut tester des serveurs internes non accessibles depuis Internet, il peut être automatisé dans des pipelines CI/CD, et il ne transmet pas les informations de votre serveur à un tiers. Pour les serveurs exposés sur Internet, SSLLabs complète bien testssl.sh grâce à son interface visuelle et sa reconnaissance mondiale. Pour les audits internes et l'automatisation, testssl.sh est irremplaçable.

Testssl.sh peut-il générer des faux positifs ?

Oui, dans certains cas. Par exemple, la détection de BEAST peut être signalée comme "potentiellement vulnérable" sur TLS 1.2 avec CBC si le navigateur client n'implémente pas les contre-mesures (1/n-1 record splitting). En pratique, tous les navigateurs modernes implémentent ces contre-mesures, rendant cette vulnérabilité théorique côté serveur. De même, certaines détections de suites cryptographiques "faibles" peuvent être des faux positifs si la suite n'est en réalité jamais négociée avec les clients modernes. Croisez toujours les résultats avec la documentation officielle et votre contexte opérationnel.

Comment tester TLS sur un serveur Windows IIS avec testssl.sh ?

Testssl.sh tourne sur Linux/macOS mais peut tester n'importe quel serveur TLS, y compris IIS sur Windows. Exécutez testssl.sh depuis un poste Linux ou un conteneur Docker, en pointant vers l'adresse IP ou le FQDN du serveur IIS. Pour corriger les problèmes identifiés sur IIS, utilisez IIS Crypto (outil GUI de Nartac Software) ou PowerShell : Disable-TlsCipherSuite -Name "TLS_RSA_WITH_3DES_EDE_CBC_SHA". Les paramètres TLS d'IIS sont configurés dans le registre Windows sous HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL.

Comment interpréter le score "overall rating" de testssl.sh ?

Testssl.sh n'attribue pas de note globale unique comme SSLLabs, mais fournit un code couleur par catégorie. Pour obtenir une évaluation globale, utilisez l'option --rating (expérimentale dans les versions récentes) qui tente de reproduire la méthodologie de notation SSL Labs. Alternatively, exportez les résultats en JSON et analysez la distribution des sévérités : une configuration idéale ne doit présenter aucun élément en rouge (HIGH) ou bordeaux (CRITICAL), et un minimum d'éléments en orange (MEDIUM).