TLS en 2026 : bonnes pratiques et configuration sécurisée

TLS porte la sécurité web moderne. Pourtant, les mauvaises configurations restent alarmantes : certificats expirés, cipher suites obsolètes, absence d'HSTS, OCSP stapling désactivé. Chaque jour, des milliers de sites exposent leurs utilisateurs à des risques inutiles.

Voici comment configurer TLS correctement en 2026, que vous gériez une PME ou une infrastructure d'entreprise à SLA élevé.

1. TLS 1.3 : les avancées clés et l'impact sur les performances
2. Cipher suites recommandées : sélection moderne et forward secrecy
3. Configuration Nginx : optimisation complète
4. Configuration Apache : les essentiels
5. HSTS et preloading : forcer HTTPS partout
6. OCSP Stapling : améliorer les performances de révocation
7. Certificats et Let's Encrypt : de l'ACME au wildcard
8. Audit de sécurité : testssl.sh et SSL Labs
9. Sources et perspectives

TLS 1.3 (RFC 8446, 2018) refond le protocole en profondeur. Les gains sont tangibles :

• Handshake réduit : 2 round-trips au lieu de 4, latence diminuée
• 0-RTT : reprise de session immédiate (attention aux replays)
• Backward compatibility brisée : les anciens serveurs TLS 1.0/1.1 sont exclus
• Cipher suites simplifiées : seules les variantes AEAD modernes subsistent
• Perfect Forward Secrecy obligatoire : suppression des RSA key transport

Si votre site accueille encore des utilisateurs sur IE 11 ou des navigateurs anciens, acceptez-le : la compatibilité TLS 1.2 est un prérequis minimum.

Recommandation pratique : TLS 1.3 et TLS 1.2 doivent coexister. TLS 1.1 et antérieurs sont à bannir sans regret.

Les cipher suites modernes partagent des caractéristiques communes :

Pour TLS 1.3, les suites suivantes sont sûres :

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

Pour TLS 1.2, respectez cet ordre de préférence :

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256

Jamais de suites sans forward secrecy (DHE-RSA-AES128-SHA, etc.).

Voici une configuration Nginx sécurisée et performante :

# /etc/nginx/conf.d/ssl.conf

ssl_protocols TLSv1.3 TLSv1.2;
ssl_ciphers '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';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets off;

# Certificat et clé
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# OCSP Stapling (voir section dédiée)
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

# Headers de sécurité
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header X-XSS-Protection "1; mode=block" always;

Points critiques :

• ssl_prefer_server_ciphers on : le serveur choisit la suite, pas le client
• ssl_session_tickets off : évite les risques de replay si le ticket key n'est pas régénéré
• Resolver externe pour OCSP stapling

Pour Apache 2.4+ avec mod_ssl :

# /etc/apache2/mods-enabled/ssl.conf

SSLProtocol TLSv1.3 TLSv1.2
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 on
SSLCompression off

SSLSessionCacheTimeout 1d
SSLSessionTickets off

# OCSP Stapling
SSLUseStapling On
SSLStaplingCache "shmcb:logs/stapling-cache(512000)"
SSLStaplingStandardCacheTTL 3600
SSLStaplingErrorCacheTTL 600

Appliquez ensuite via virtualhost :

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</VirtualHost>

HTTP Strict-Transport-Security (HSTS) force le navigateur à n'utiliser que HTTPS pour tous les accès futurs au domaine.

La directive :

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Pour participer au preload list (Mozilla, Google, Apple) :

1. Configurez HSTS avec preload
2. Visitez https://hstspreload.org/
3. Validez votre domaine (scan TXT DNS automatique)
4. Submittez

Une fois validé, le domaine est hardcodé dans tous les navigateurs. Aucune requête HTTP n'est possible. Vérifiez votre infrastructure avant !

OCSP (Online Certificate Status Protocol) permet de vérifier si un certificat n'a pas été révoqué. Le problème classique : chaque client contacte l'OCSP responder, latence multipliée.

OCSP Stapling : le serveur contacte l'OCSP responder et attache la réponse au handshake TLS. Gain : latence client éliminée, revocation info toujours à jour.

Nginx

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 1.1.1.1 1.0.0.1 valid=300s;
resolver_timeout 5s;

Vérifiez :

echo | openssl s_client -connect example.com:443 -servername example.com \
  -tlsextdebug 2>/dev/null | grep -A 3 "OCSP"

Résultat attendu : OCSP response: This is the OCSP response, stapled by the server.

Apache

SSLUseStapling On
SSLStaplingCache "shmcb:logs/stapling-cache(512000)"
SSLStaplingStandardCacheTTL 3600
SSLStaplingErrorCacheTTL 600

Let's Encrypt (fondation ISRG, lancé 2015) a démocratisé HTTPS. En 2026, c'est le standard de facto pour les petites et moyennes infrastructures.

Acme et Certbot

# Installation sur Ubuntu/Debian
apt-get install certbot python3-certbot-nginx python3-certbot-apache

# Certificat avec Nginx
certbot certonly --nginx -d example.com -d www.example.com

# Certificat wildcard (validation DNS)
certbot certonly --manual --preferred-challenges dns -d "*.example.com" -d example.com

# Renouvellement automatique (cron)
certbot renew --quiet --no-eff-email

ECC vs RSA

Recommandation : ECC pour les nouveaux sites, RSA si compatibilité avec clients legacy nécessaire.

Certificate Transparency

Chaque certificat émis par une CA doit être enregistré dans des logs CT publiques (Google, Digicert, etc.). Cela prévient les certificats malveillants et dupliqués.

Let's Encrypt remplit automatiquement. Vérifiez :

curl -s https://crt.sh/?q=example.com | jq '.[]|select(.issuer_ca_id==16418)'

CAA (Certification Authority Authorization)

Enregistrement DNS qui autorise explicitement quelles CAs peuvent émettre des certificats pour votre domaine :

example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:security@example.com"

Recommandé : très puissant contre les certificats malveillants.

Expect-CT (déprécié en 2026)

Expect-CT était un mécanisme pour forcer les logs CT. Déprécié par les navigateurs (Chrome 2025+). À retirer des configurations.

Certificate Pinning

Technique avancée : épingler la clé publique du certificat dans le navigateur (Public-Key-Pins header). À éviter : risque de lockout, abandon progressif des navigateurs.

testssl.sh

Outil CLI open-source pour auditer les configurations TLS :

# Installation
git clone https://github.com/drwetter/testssl.sh.git
cd testssl.sh

# Scan complet
./testssl.sh --full https://example.com

# Scan rapide avec détails
./testssl.sh -U https://example.com

Résultats clés à vérifier :

• Protocols : TLS 1.3 + TLS 1.2 actifs
• Cipher suites : tous AEAD, forward secrecy obligatoire
• Handshake : Performance < 100ms
• HSTS : present, max-age >= 31536000, preload

SSL Labs (Qualys)

Scan web fourni par Qualys (gratuit, publique) : https://www.ssllabs.com/ssltest/

Objectif : note A ou A+.

Checklist A+ :

• Protocol : TLS 1.3 + TLS 1.2
• Key exchange : 2048+ bits RSA ou ECC
• Cipher strength : 128+ bits minimum
• HSTS : present, preload OK
• OCSP Stapling : actif
• Root certificate : public/connu

Pour aller plus loin :

• ACME avec DNS-01 et Cloudflare : automation de renouvellement wildcard sans exposition HTTP
• Certbot en cron : renouvellement quotidien, webhook de reload applicatif
• mTLS sur Nginx/Apache : authentification client par certificat
• HTTP/3 et QUIC : remplaçant de TCP, réduction latence 0-RTT native
• Audit SSH : clés hostées en infrastructure, sécurisation par certificat

• RFC 8446 - TLS 1.3 Specification (IETF, 2018) https://tools.ietf.org/html/rfc8446
• Let's Encrypt Documentation https://letsencrypt.org/docs/
• Nginx SSL Configuration https://nginx.org/en/docs/http/ngx_http_ssl_module.html
• Mozilla SSL Configuration Generator https://ssl-config.mozilla.org/
• testssl.sh GitHub https://github.com/drwetter/testssl.sh
• SSL Labs Best Practices https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices
• HSTSPRELOAD.ORG https://hstspreload.org/
• OWASP - HTTPS https://owasp.org/www-community/attacks/Manipulator-in-the-middle_attack
• Certificate Transparency Logs https://crt.sh/
• RFC 6844 - CAA https://tools.ietf.org/html/rfc6844

TLS en 2026 doit être TLS 1.3 par défaut, avec TLS 1.2 comme fallback. Les cipher suites doivent être AEAD-only, le forward secrecy obligatoire, et les headers de sécurité (HSTS, CAA, CSP) configurés.

Les outils testssl.sh et Qualys SSL Labs vous permettront de valider votre infrastructure rapidement. Let's Encrypt élimine la barrière coût des certificats. Pas d'excuses pour une mauvaise configuration.

Vérifiez. Testez. Actualisez.

Surveiller les expirations de certificats et garder cette config TLS à jour dans la durée réclame une présence ; à défaut, cette veille s'externalise.