Apache HTTPS : activer TLS 1.3 et la Perfect Forward Secrecy

La Perfect Forward Secrecy, souvent abrégée en PFS, protège les anciennes connexions TLS même si la clé privée du serveur est compromise plus tard.

L’idée est simple : chaque session TLS négocie un secret éphémère. Ainsi, la clé privée du certificat ne suffit pas à déchiffrer rétroactivement tout le trafic enregistré.

Aujourd’hui, TLS 1.3 fournit la forward secrecy par conception, et TLS 1.2 reste acceptable si vous limitez les suites à des choix modernes comme ECDHE avec AES-GCM ou CHACHA20-POLY1305.

Ce qui a changé depuis les anciennes configurations SSL

Les anciens tutoriels Apache recommandaient souvent :

• de désactiver SSLv2 et SSLv3 ;
• de choisir une longue liste de suites de chiffrement ;
• de générer un paramètre Diffie-Hellman personnalisé ;
• d’utiliser SSLHonorCipherOrder on ;
• de tester avec SSL Labs.

Ces idées étaient bonnes à l’époque. Mais une configuration actuelle doit surtout :

• activer TLS 1.3 ;
• garder TLS 1.2 seulement avec des suites fortes ;
• désactiver TLS 1.0 et TLS 1.1 ;
• éviter les ciphers RSA sans forward secrecy ;
• activer OCSP Stapling si possible ;
• servir le site en HTTPS partout ;
• ajouter HSTS seulement quand tout le domaine est prêt ;
• vérifier la configuration après chaque modification.

Perfect Forward Secrecy : définition rapide

Sans forward secrecy, un attaquant qui enregistre aujourd’hui votre trafic HTTPS pourrait le déchiffrer plus tard s’il obtient la clé privée du serveur.

Avec forward secrecy, cette attaque devient beaucoup moins utile. Chaque session utilise un secret éphémère négocié pendant la connexion. La clé privée du certificat sert à authentifier le serveur, mais elle ne suffit plus à retrouver les clés de session passées.

En TLS 1.2, la PFS dépend surtout des suites ECDHE ou DHE. En TLS 1.3, les échanges éphémères sont intégrés au fonctionnement normal du protocole.

Avant de modifier Apache : vérifier les versions

Commencez par vérifier Apache, OpenSSL et les modules chargés.

apache2 -v
openssl version
apache2ctl -M | grep -E 'ssl|headers|socache'Langage du code : JavaScript (javascript)

Sur Debian ou Ubuntu, les modules utiles sont généralement :

sudo a2enmod ssl
sudo a2enmod headers
sudo a2enmod socache_shmcb

Puis rechargez Apache après validation de la configuration :

sudo apache2ctl configtest
sudo systemctl reload apache2

Ne redémarrez pas Apache à l’aveugle sur un serveur de production. Testez d’abord la syntaxe. C’est moins héroïque, mais nettement plus professionnel.

Configuration recommandée : profil Intermediate

Pour la majorité des sites publics, utilisez un profil de compatibilité moderne mais pas extrême. Le profil “Intermediate” de Mozilla est généralement le bon compromis.

Il permet de servir les navigateurs actuels, les mobiles récents, les robots légitimes et la plupart des clients encore raisonnables, sans garder TLS 1.0, TLS 1.1 ou des suites faibles.

Créez un fichier de configuration commun, par exemple :

sudo nano /etc/apache2/conf-available/ssl-hardening.conf

Ajoutez cette base :

SSLProtocol             -all +TLSv1.2 +TLSv1.3

SSLCipherSuite          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
SSLHonorCipherOrder     off

SSLSessionTickets       off

SSLUseStapling          on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off

SSLSessionCache         shmcb:/var/run/apache2/ssl_scache(512000)Langage du code : JavaScript (javascript)

Activez ensuite la configuration :

sudo a2enconf ssl-hardening
sudo apache2ctl configtest
sudo systemctl reload apache2

Cette configuration active TLS 1.2 et TLS 1.3, refuse les vieux protocoles et limite TLS 1.2 à des suites ECDHE modernes.

Pourquoi SSLHonorCipherOrder est à off ?

Dans les anciennes configurations, on utilisait souvent :

SSLHonorCipherOrder on

Cela forçait l’ordre de préférence du serveur pour les suites TLS 1.2. Aujourd’hui, avec une liste de suites toutes solides, il est souvent préférable de laisser le client choisir la suite la plus performante pour son matériel.

Le point important n’est plus de micro-ordonner vingt suites. Le point important est de ne proposer que de bonnes suites.

Et les suites TLS 1.3 ?

Les suites TLS 1.3 ne se configurent pas comme les suites TLS 1.2. Avec Apache et OpenSSL modernes, les choix par défaut sont déjà bons dans la plupart des cas.

Les suites TLS 1.3 courantes sont :

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256

Pour un serveur web généraliste, ne cherchez pas à surconfigurer TLS 1.3 sans raison. Gardez la configuration simple et vérifiez le résultat avec SSL Labs et openssl s_client.

Configuration stricte : profil Modern

Si vous contrôlez tous les clients, vous pouvez utiliser une configuration TLS 1.3 uniquement.

Exemple :

SSLProtocol             -all +TLSv1.3
SSLSessionTickets       off

SSLUseStapling          on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off

SSLSessionCache         shmcb:/var/run/apache2/ssl_scache(512000)Langage du code : JavaScript (javascript)

Ce profil est propre, mais plus strict. Il peut exclure de vieux clients, certains robots, des systèmes embarqués, d’anciens Android, de vieux Java, ou des outils métiers oubliés dans un placard serveur.

Pour un blog public ou un site WordPress classique, je choisirais plutôt le profil Intermediate. Pour une API interne ou un service contrôlé, TLS 1.3 uniquement peut être excellent.

Configurer le VirtualHost HTTPS

Votre VirtualHost doit déclarer le certificat, la clé privée, le nom de domaine et les règles HTTPS.

Exemple avec Let’s Encrypt :

<VirtualHost *:443>
	ServerName example.com
	ServerAlias www.example.com

	DocumentRoot /var/www/example.com/public

	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"

	<Directory /var/www/example.com/public>
		Options -Indexes +FollowSymLinks
		AllowOverride All
		Require all granted
	</Directory>

	ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
	CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
</VirtualHost>Langage du code : PHP (php)

Adaptez les chemins à votre serveur. Si vous utilisez Certbot, les chemins Let’s Encrypt ci-dessus sont classiques.

Rediriger HTTP vers HTTPS

Gardez un VirtualHost HTTP minimal qui redirige vers HTTPS.

<VirtualHost *:80>
	ServerName example.com
	ServerAlias www.example.com

	Redirect permanent / https://example.com/
</VirtualHost>Langage du code : HTML, XML (xml)

Si votre site canonique est www, redirigez vers https://www.example.com/. L’important est de choisir une version canonique et de s’y tenir.

HSTS : puissant, mais à activer avec méthode

HSTS indique au navigateur de toujours utiliser HTTPS pour votre domaine pendant une durée donnée.

Exemple raisonnable une fois le site validé :

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"Langage du code : JavaScript (javascript)

N’ajoutez pas preload trop vite. Et n’ajoutez pas includeSubDomains si tous vos sous-domaines ne sont pas prêts en HTTPS.

Je recommande cette progression :

1. Activer HTTPS correctement sur le domaine principal.
2. Vérifier les redirections et le certificat.
3. Activer HSTS avec une durée courte, par exemple max-age=300.
4. Surveiller les erreurs.
5. Passer à max-age=86400.
6. Enfin, monter à 31536000 si tout est propre.
7. Ajouter includeSubDomains seulement si tous les sous-domaines sont couverts.

HSTS est très utile. Mais mal activé, il peut vous enfermer dehors avec une belle serrure toute neuve.

OCSP Stapling

OCSP Stapling permet au serveur Apache de fournir au client une preuve récente de validité du certificat, au lieu de laisser chaque navigateur interroger directement l’autorité de certification.

Activez-le dans la configuration globale SSL :

SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLSessionCache shmcb:/var/run/apache2/ssl_scache(512000)Langage du code : JavaScript (javascript)

Vérifiez ensuite qu’Apache peut écrire le cache et joindre les répondeurs OCSP. Sur certains serveurs très filtrés, un pare-feu sortant trop strict peut casser le stapling.

Faut-il encore générer un fichier dhparam.pem ?

Les anciens guides recommandaient souvent :

openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096

C’était surtout utile pour les suites DHE classiques. Avec TLS 1.3 et des suites TLS 1.2 basées sur ECDHE, ce n’est généralement plus indispensable pour un site web Apache moderne.

Si votre configuration ne propose plus de suites DHE, un fichier dhparam.pem n’apporte pas grand-chose. Évitez d’ajouter des reliques cryptographiques “au cas où”. La sécurité aime la clarté.

Tester avec OpenSSL

Testez TLS 1.3 :

openssl s_client -connect example.com:443 -servername example.com -tls1_3Langage du code : CSS (css)

Testez TLS 1.2 :

openssl s_client -connect example.com:443 -servername example.com -tls1_2Langage du code : CSS (css)

Testez que TLS 1.0 est refusé :

openssl s_client -connect example.com:443 -servername example.com -tls1Langage du code : CSS (css)

Testez que TLS 1.1 est refusé :

openssl s_client -connect example.com:443 -servername example.com -tls1_1Langage du code : CSS (css)

Les tests TLS 1.0 et TLS 1.1 doivent échouer. Les tests TLS 1.2 et TLS 1.3 doivent réussir si vous utilisez le profil Intermediate.

Tester avec SSL Labs

Après chaque changement, testez le domaine avec SSL Labs.

Vérifiez notamment :

• le certificat et sa chaîne ;
• les protocoles activés ;
• les suites TLS 1.2 ;
• la présence de forward secrecy ;
• OCSP Stapling ;
• HSTS ;
• les vieux clients encore compatibles ;
• les alertes ROBOT, BEAST, POODLE, CRIME ou autres tests historiques.

Un score A ou A+ est généralement atteignable avec une configuration propre. Mais ne poursuivez pas le A+ comme un trophée décoratif. La compatibilité, le renouvellement des certificats et la maintenance comptent autant.

Cas WordPress : attention aux mixed content

Une configuration TLS parfaite ne sert pas à grand-chose si WordPress charge encore des images, scripts ou feuilles de style en HTTP.

Vérifiez l’URL du site :

wp option get home
wp option get siteurlLangage du code : JavaScript (javascript)

Si nécessaire, corrigez :

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'Langage du code : JavaScript (javascript)

Pour rechercher les anciennes URLs HTTP dans la base :

wp search-replace 'http://example.com' 'https://example.com' --dry-runLangage du code : JavaScript (javascript)

Puis, après vérification :

wp search-replace 'http://example.com' 'https://example.com'Langage du code : JavaScript (javascript)

Faites une sauvegarde avant un remplacement réel. Le cadenas vert ne vaut pas une base cassée.

Si Apache est derrière Cloudflare

Si votre site passe par Cloudflare, vous avez deux couches TLS :

• visiteur → Cloudflare ;
• Cloudflare → serveur Apache d’origine.

Dans ce cas, sécurisez les deux.

• Utilisez le mode Full strict côté Cloudflare.
• Gardez un certificat valide sur l’origine.
• Activez TLS 1.2 et TLS 1.3 sur Apache.
• Ne baissez pas la sécurité de l’origine sous prétexte que Cloudflare est devant.
• Testez aussi l’origine directement si elle reste accessible.

Cloudflare peut masquer une partie du diagnostic public. SSL Labs testera surtout le bord Cloudflare si le domaine est proxifié. Pour tester Apache lui-même, utilisez une entrée DNS non proxifiée, une IP directe avec SNI, ou un environnement de test.

Dépannage : SSLProtocol ne semble pas appliqué

Si SSL Labs indique encore TLS 1.0 ou TLS 1.1, vérifiez ces points :

• la directive est-elle dans la bonne configuration Apache ?
• le site utilise-t-il le bon VirtualHost ?
• existe-t-il plusieurs fichiers qui redéfinissent SSLProtocol ?
• avez-vous rechargé Apache après modification ?
• testez-vous Cloudflare au lieu de l’origine ?
• un autre service écoute-t-il sur le port 443 ?
• la configuration est-elle incluse par a2enconf ou Include ?

Listez les VirtualHosts chargés :

apache2ctl -S

Inspectez les fichiers SSL actifs :

grep -R "SSLProtocol\|SSLCipherSuite\|SSLHonorCipherOrder" /etc/apache2/ -nLangage du code : JavaScript (javascript)

Cette commande révèle souvent une vieille directive oubliée dans un fichier de site ou un include global.

Dépannage : Apache ne redémarre plus

Commencez par le test de configuration :

sudo apache2ctl configtest

Puis regardez les logs :

sudo journalctl -u apache2 --since "10 minutes ago"
sudo tail -100 /var/log/apache2/error.logLangage du code : JavaScript (javascript)

Erreurs fréquentes :

• module ssl non activé ;
• module headers non activé ;
• module socache_shmcb non activé ;
• chemin de certificat incorrect ;
• clé privée absente ou illisible ;
• directive non supportée par votre version d’Apache ;
• copie d’une configuration Nginx dans Apache, grand classique du vendredi soir.

Checklist de durcissement TLS Apache

• Apache et OpenSSL à jour.
• mod_ssl activé.
• TLS 1.3 activé.
• TLS 1.2 gardé seulement avec des suites modernes.
• TLS 1.0 et TLS 1.1 désactivés.
• Suites TLS 1.2 en ECDHE + AEAD.
• Certificat valide et chaîne complète.
• OCSP Stapling activé si possible.
• HTTP redirigé vers HTTPS.
• HSTS activé progressivement.
• Mixed content corrigé côté application.
• Test SSL Labs après déploiement.
• Renouvellement automatique des certificats testé.

Configuration complète type

Voici une configuration synthétique pour un serveur Apache moderne avec compatibilité raisonnable.

# /etc/apache2/conf-available/ssl-hardening.conf

SSLProtocol             -all +TLSv1.2 +TLSv1.3

SSLCipherSuite          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
SSLHonorCipherOrder     off

SSLSessionTickets       off

SSLUseStapling          on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off

SSLSessionCache         shmcb:/var/run/apache2/ssl_scache(512000)Langage du code : PHP (php)

Et un VirtualHost HTTPS minimal :

<VirtualHost *:443>
	ServerName example.com
	ServerAlias www.example.com

	DocumentRoot /var/www/example.com/public

	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"

	<Directory /var/www/example.com/public>
		Options -Indexes +FollowSymLinks
		AllowOverride All
		Require all granted
	</Directory>

	ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
	CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
</VirtualHost>Langage du code : PHP (php)

Activez et testez :

sudo a2enmod ssl headers socache_shmcb
sudo a2enconf ssl-hardening
sudo apache2ctl configtest
sudo systemctl reload apache2

Conclusion

La Perfect Forward Secrecy n’est plus une option exotique à bricoler avec une liste interminable de suites SSL. C’est désormais une attente normale pour un serveur HTTPS sérieux.

Sur Apache, la bonne approche consiste à activer TLS 1.3, garder TLS 1.2 avec des suites ECDHE modernes si vous avez besoin de compatibilité, désactiver les anciens protocoles, ajouter OCSP Stapling, puis tester le domaine avec SSL Labs.

Ne cherchez pas à collectionner les directives cryptographiques. Cherchez une configuration courte, maintenue, testée et compréhensible. En sécurité serveur, le folklore vieillit vite. TLS aussi.

Sources et documentation

• Mozilla SSL Configuration Generator
• Apache HTTP Server : SSL/TLS Strong Encryption How-To
• Qualys SSL Labs : SSL Server Test
• SkyMinds : sécurisation de la couche TCP/IP sur un serveur dédié
• SkyMinds : sécuriser un certificat SSL avec DANE/TLSA et DNSSEC

Report a typo