En bref : une configuration TLS solide pour un serveur web ne propose que TLS 1.2 et TLS 1.3, utilise des suites de chiffrement avec confidentialité persistante (forward secrecy) et chiffrement authentifié (AES-GCM, ChaCha20-Poly1305), ainsi qu'un certificat avec une clé ECDSA ou RSA suffisamment longue, qui se renouvelle automatiquement. La directive TR-02102-2 du BSI (Office fédéral allemand de la sécurité des technologies de l'information) et les recommandations TLS côté serveur de TLSRef servent de repères. Vérifiez le résultat depuis l'extérieur et n'oubliez pas les connexions que PHP établit lui-même.
Pourquoi les anciens réglages TLS survivent si longtemps
Le cadenas est là dans le navigateur, donc le chiffrement est considéré comme réglé. C'est ce que pensent de nombreux exploitants, et c'est pourquoi la configuration TLS reste souvent inchangée pendant des années. Elle date alors de la mise en place du serveur, d'un modèle copié ou des valeurs par défaut d'un panneau.
Le problème : les recommandations évoluent. Des versions de protocole sont remplacées, des procédés sont jugés faibles, de nouveaux procédés d'échange de clés apparaissent. Le BSI a publié la TR-02102 pour la dernière fois dans la version 2026-01 du 27 janvier 2026, et y mentionne déjà des procédés hybrides post-quantiques pour TLS 1.3. Quiconque n'a pas examiné ses réglages depuis des années n'est très probablement plus à jour.
Si vous vérifiez de toute façon vos serveurs après PHP2Shell, vous pouvez examiner la configuration TLS dans la foulée. Elle ne corrige pas la faille PHP, mais fait partie de tout durcissement sérieux.
Sur quoi s'appuie une bonne configuration TLS de serveur web
Deux sources sont particulièrement utiles aux exploitants en Europe. La BSI TR-02102 évalue les procédés cryptographiques ; la partie 2 traite de TLS. Elle s'adresse surtout aux développeurs et aux concepteurs, et constitue souvent la référence pour les administrations et les secteurs réglementés. Les recommandations TLS côté serveur, autrefois maintenues dans le wiki Mozilla, sont aujourd'hui poursuivies sous TLSRef et fournissent des profils concrets, à copier.
Dans la version 6.0, TLSRef distingue deux profils :
| Caractéristique | Intermediate (pour la plupart des sites) | Modern |
|---|---|---|
| Protocoles | TLS 1.2 et TLS 1.3 | TLS 1.3 uniquement |
| Suites de chiffrement TLS 1.2 | ECDHE avec AES-GCM ou ChaCha20-Poly1305 | aucune |
| Groupes d'échange de clés | X25519MLKEM768, X25519, prime256v1, secp384r1 | comme Intermediate |
| Certificat | ECDSA P-256 recommandé ou RSA 2048 bits | ECDSA P-256 |
| Durée de validité du certificat | 90 jours recommandés, 366 jours au maximum | 90 jours |
| HSTS max-age | deux ans | deux ans |
Pour les sites publics, Intermediate est le point de départ habituel. Ce profil exclut les appareils très anciens, mais couvre les navigateurs et systèmes d'exploitation actuels. Le groupe hybride X25519MLKEM768 suppose une bibliothèque TLS récente. Vérifiez que votre version d'OpenSSL le connaît avant de l'indiquer.
Nginx et Apache : un point de départ sûr
Les exemples suivants mettent en œuvre le profil Intermediate. Les chemins sont des valeurs d'exemple ; la liste des suites de chiffrement vaut pour TLS 1.2, TLS 1.3 apportant ses propres procédés par défaut, sûrs.
server {
listen 443 ssl;
server_name www.example.de;
ssl_certificate /etc/ssl/example/fullchain.pem;
ssl_certificate_key /etc/ssl/example/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
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;
ssl_prefer_server_ciphers off;
}
server {
listen 80;
server_name www.example.de;
return 301 https://$host$request_uri;
}
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
Le second bloc server redirige durablement les appels non chiffrés vers HTTPS. La redirection devrait pointer directement vers l'adresse définitive et ne pas passer par plusieurs étapes intermédiaires. Vérifiez ensuite aussi les ressources intégrées : les images, scripts ou polices encore chargés en HTTP déclenchent des avertissements dans le navigateur ou sont bloqués.
Le réglage selon lequel le client choisit l'ordre correspond à la recommandation de TLSRef : tous les procédés proposés sont considérés comme sûrs, et les appareils sans accélération AES peuvent ainsi préférer ChaCha20. Après chaque modification, testez la configuration (nginx -t ou apachectl configtest) et rechargez le service. L'en-tête HSTS adapté et d'autres consignes pour le navigateur sont décrits dans le guide En-têtes de sécurité pour les sites web.
Des panneaux comme Plesk ou cPanel écrasent souvent les modifications que vous apportez aux fichiers générés. Définissez-y les consignes TLS via les réglages ou les modèles prévus par le panneau.
Certificats : clé, chaîne, renouvellement
Une grande partie des problèmes TLS rencontrés en pratique n'a rien à voir avec les suites de chiffrement, mais avec les certificats. Les erreurs typiques sont une chaîne incomplète où le certificat intermédiaire manque, des certificats expirés sur des domaines secondaires et des clés privées aux droits de fichier trop larges.
Trois règles aident :
- Renouveler automatiquement et surveiller le renouvellement. Les durées de validité courtes, telles que les recommande TLSRef, ne sont praticables qu'avec l'automatisation.
- Protéger les clés privées : lisibles uniquement par root et par le processus du serveur web, jamais dans le webroot, jamais dans un dépôt.
- Recenser tous les noms : domaine principal, www, sous-domaines de la boutique, du staging, de l'interface web de messagerie et des panneaux.
Si vous utilisez des certificats à plusieurs endroits, par exemple sur le CDN, le répartiteur de charge et le serveur d'origine, tenez un aperçu : quel certificat est installé où, qui le renouvelle et quand il expire. Sans cet aperçu, un certificat expiré n'est souvent remarqué que lorsque des clients se manifestent.
Comment vérifier votre configuration depuis l'extérieur
Les commandes suivantes sont de simples vérifications et ne modifient rien. Remplacez le nom d'hôte par le vôtre :
# TLS 1.3 et TLS 1.2 doivent fonctionner
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_3 </dev/null
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_2 </dev/null
# TLS 1.1 doit échouer
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# Durée de validité et titulaire du certificat présenté
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
Un échec au test TLS 1.1 peut aussi s'expliquer par le fait que votre version locale d'OpenSSL ne propose plus du tout l'ancien protocole. Pour un rapport complet sur tous les procédés proposés, un scanner TLS spécialisé convient. Vérifiez alors chaque sous-domaine séparément, car ils tournent souvent avec leurs propres réglages.
L'oubli : TLS là où PHP est lui-même le client
Les applications PHP établissent elles-mêmes de nombreuses connexions : vers des prestataires de paiement, des transporteurs, des interfaces, des serveurs de messagerie et des bases de données. Ici, l'erreur la plus fréquente n'est pas un réglage faible, mais une vérification du certificat désactivée, souvent comme solution rapide à un problème rencontré pendant le développement.
<?php
// Sûr : le certificat et le nom d'hôte sont vérifiés (conserver le comportement par défaut)
$ch = curl_init('https://api.partner.example/v1/status');
curl_setopt_array($ch, [
CURLOPT_RETURNTRANSFER => true,
CURLOPT_SSL_VERIFYPEER => true,
CURLOPT_SSL_VERIFYHOST => 2,
CURLOPT_TIMEOUT => 10,
]);
$antwort = curl_exec($ch);
Recherchez dans le code CURLOPT_SSL_VERIFYPEER avec false et verify_peer dans les contextes de flux. Chaque occurrence annule en pratique la protection de TLS pour cette connexion. Lorsque des services se trouvent derrière un CDN, le tronçon entre le CDN et le serveur d'origine devrait lui aussi utiliser un certificat valide et vérifié. Vous trouverez d'autres réglages de serveur web pour les installations PHP dans Configurer Nginx pour PHP en toute sécurité, et des repères pour l'ensemble du durcissement dans Benchmarks CIS et modules du BSI.
Comment PHP SOS aide-t-il concrètement ?
- Nous recensons tous les noms d'hôte et services avec TLS, y compris les panneaux, le staging et les interfaces web de messagerie.
- Nous comparons les réglages avec la TR-02102 et le profil TLSRef approprié, et documentons les écarts voulus.
- Nous faisons passer les certificats au renouvellement automatique avec surveillance.
- Nous recherchons dans le code de l'application les vérifications de certificat désactivées et montrons la correction.
TLS est un élément de notre durcissement de serveur pour serveurs web PHP ; le lien avec la situation actuelle est expliqué dans Qu'est-ce que PHP2Shell ?.
Questions fréquentes
Dois-je encore proposer TLS 1.0 et TLS 1.1 ?
En règle générale, non. Les recommandations actuelles, comme le profil Intermediate de TLSRef, fixent TLS 1.2 comme limite inférieure. Si vous avez besoin de protocoles plus anciens pour des appareils hérités, décidez-le en connaissance de cause, documentez-le et limitez-le à un service distinct.
Un certificat gratuit est-il moins sûr qu'un certificat payant ?
Pour le chiffrement, cela ne fait aucune différence. Ce qui compte, c'est le type et la longueur de la clé, une chaîne de certificats complète et un renouvellement automatique fiable. Les différences portent sur l'étendue de la vérification, la durée de validité et le service du fournisseur.
HTTPS entre le visiteur et le CDN suffit-il ?
Non. La connexion entre le CDN et le serveur d'origine devrait elle aussi être chiffrée et vérifier le certificat de l'origine. Sinon, les données circulent sur le second tronçon sans chiffrement ou sans vérification.
Quel est le rapport entre TLS et PHP2Shell ?
Aucun, directement. TLS protège les données pendant le transport, alors que PHP2Shell concerne l'interpréteur PHP sur le serveur. Une connexion chiffrée transporte tout aussi fidèlement les requêtes d'attaque ; la mise à jour de PHP reste donc obligatoire, indépendamment de cela.