Durcissement TLS Apache en 2026 — ciphers, OCSP stapling et la pipeline de renouvellement de cert

Chaque install Apache que nous auditons a une config TLS que quelqu'un a copié-collé d'un guide Mozilla en 2019. Les suites de chiffrement sont trop longues. Les protocoles autorisent encore TLS 1.0 sur une ligne SSLProtocol all -SSLv3 que personne n'a mise à jour. OCSP stapling est éteint parce qu'il a échoué une fois pendant un changement de firewall et n'a jamais été réactivé. Le renouvellement de cert est un cron Certbot que personne ne monitore avant qu'il ne s'arrête.

Voici la config TLS que nous livrons sur chaque hôte Apache managé en 2026.

Le bloc SSL du vhost

SSLProtocol             -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder     off
SSLSessionTickets       off
SSLUseStapling          on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLCipherSuite TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
 
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

TLS 1.3 n'a pas besoin de SSLCipherSuite — ses suites sont négociées indépendamment. La ligne SSLHonorCipherOrder off est correcte en 2026 : les clients modernes choisissent mieux le cipher que votre config.

L'article complet couvre :

• Pourquoi les session tickets sont désactivés (la forward secrecy n'est pas réelle si vous réutilisez une clé de ticket pendant des semaines)
• OCSP stapling — comment l'empêcher d'échouer silencieusement
• Le hook certbot + apache-reload qui survit aux runs certbot renew
• Monitoring des certs : alerter à 30/14/7 jours restants, pas à l'expiration
• Le job ssllabs-scan que nous exécutons hebdomadairement sur la flotte
• HSTS preload — la décision irréversible et comment l'étaler

Nous livrons cette configuration sur chaque install Apache managée.