Une configuration Nginx solide ne repose pas sur une longue liste de chiffrements, mais sur des choix cohérents entre protocoles, suites cryptographiques et certificat. Pour appliquer les recommandations de sécurité 2025 sans sacrifier la compatibilité des navigateurs récents, il faut notamment distinguer le rôle de ssl_ciphers de celui des paramètres propres à TLS 1.3.
L’article en bref
Une configuration TLS bien réglée réduit les risques sans transformer chaque mise à jour en casse-tête. Voici les choix essentiels pour sécuriser Nginx et vérifier le résultat.
- Protocoles actuels : Autoriser TLS 1.2 et TLS 1.3, sans versions obsolètes.
- Suites robustes : Privilégier ECDHE et le chiffrement AEAD moderne.
- Configuration cohérente : Distinguer les suites TLS 1.2 de celles de TLS 1.3.
- Contrôle final : Tester la configuration et inspecter les connexions établies.
Une politique claire apporte une sécurité vérifiable et des connexions fluides.
Configurer ssl_ciphers sur Nginx sans confondre les protocoles
La directive ssl_ciphers définit les suites cryptographiques proposées pour TLS 1.2 et les versions antérieures. Elle ne configure pas les suites TLS 1.3, négociées séparément par OpenSSL : modifier cette seule ligne ne suffit donc pas à contrôler tous les algorithmes de chiffrement utilisés par le serveur.
Pour un site public comme celui de l’entreprise fictive Atelier Lumen, un socle simple consiste à activer uniquement TLS 1.2 et TLS 1.3, puis à retenir des suites AEAD avec échange de clés ECDHE. Cette combinaison fournit notamment la Perfect Forward Secrecy : la compromission ultérieure de la clé privée du certificat ne permet pas, à elle seule, de déchiffrer les anciennes sessions enregistrées.
Pourquoi TLS 1.2 et TLS 1.3 forment un socle pertinent
TLS 1.0 et TLS 1.1 sont obsolètes et ne devraient plus être activés sur un service web courant. Conserver TLS 1.2 permet encore d’accueillir certains clients plus anciens, tandis que TLS 1.3 offre une négociation modernisée et réduit les étapes de connexion.
Le module HTTPS de Nginx, ngx_http_ssl_module, doit être disponible dans la compilation et requiert OpenSSL. Les paquets distribués l’intègrent généralement, mais il reste prudent de vérifier l’installation et les versions avant de reprendre une configuration : TLS 1.3 nécessite une bibliothèque OpenSSL compatible.
Pour Atelier Lumen, le choix est pragmatique : ne pas réactiver d’anciens protocoles pour corriger un client marginal, mais identifier ce client et mesurer le besoin. Une politique plus permissive élargit parfois la compatibilité au prix d’un niveau de protection inférieur.
La version TLS négociée et la suite retenue sont deux informations distinctes : les vérifier aide à repérer les écarts entre la configuration attendue et les connexions réelles.
Choisir des suites cryptographiques modernes pour ssl_ciphers
Pour TLS 1.2, la liste ci-dessous privilégie ECDHE, qui permet la confidentialité persistante, et des chiffrements AEAD comme AES-GCM ou ChaCha20-Poly1305. Elle exclut notamment les suites faibles fondées sur RC4, 3DES, les chiffrements d’exportation ou l’échange RSA statique.
| Famille | Usage recommandé | Pourquoi |
|---|---|---|
| ECDHE-ECDSA avec AES-GCM | TLS 1.2 | Échange éphémère et chiffrement authentifié, avec certificat ECDSA. |
| ECDHE-RSA avec AES-GCM | TLS 1.2 | Alternative moderne compatible avec un certificat RSA. |
| ECDHE avec ChaCha20-Poly1305 | TLS 1.2 | Chiffrement authentifié souvent efficace sur les appareils sans accélération AES. |
| TLS_AES_* et TLS_CHACHA20_* | TLS 1.3 | Suites définies et négociées séparément de ssl_ciphers. |
La chaîne ci-dessous est un exemple de base pour TLS 1.2. Elle couvre les certificats ECDSA et RSA courants ; elle doit être vérifiée avec la version d’OpenSSL livrée avec Nginx et les exigences des clients visés.
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
En règle générale, OpenSSL fournit les suites TLS 1.3 adaptées sans qu’il soit nécessaire de les préciser. Si une politique explicite est requise et que la version de Nginx ainsi que la bibliothèque OpenSSL le permettent, ssl_conf_command Ciphersuites peut servir à les définir séparément. Éviter de l’ajouter sans besoin : une surcharge inutile complique le diagnostic.
Exemple de configuration TLS sécurisée dans Nginx
Cette configuration rassemble les réglages essentiels pour un serveur HTTPS. Les chemins des certificats sont à adapter ; le fichier de certificat doit contenir le certificat du serveur suivi des certificats intermédiaires nécessaires.
worker_processes auto; listen 443 ssl; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; ssl_prefer_server_ciphers off; ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; ssl_session_cache shared:SSL:10m; ssl_session_timeout 1d; ssl_session_tickets off;
Le cache partagé évite de limiter la reprise de session à un seul processus worker. La désactivation des tickets constitue une option stricte ; pour une infrastructure répartie sur plusieurs serveurs, la reprise par tickets exige une gestion rigoureuse de clés partagées et renouvelées. Le paramètre ssl_prefer_server_ciphers n’apporte pas le même contrôle à TLS 1.3, où la négociation suit ses propres règles.
La directive historique ssl on est obsolète et a été supprimée des versions récentes de Nginx. Le chiffrement s’active sur le port avec listen 443 ssl : reprendre d’anciens extraits de configuration peut donc provoquer une erreur au rechargement.
Avant toute mise en production, vérifier les versions de Nginx et d’OpenSSL, puis tester la configuration avec nginx -t. Un changement TLS ne doit être rechargé qu’après validation, afin d’éviter qu’une erreur de syntaxe ne rende le service inaccessible.
Renforcer HTTPS avec OCSP, certificats et cache de session
Un certificat valide ne suffit pas si la chaîne intermédiaire est incomplète ou si son statut de révocation n’est pas correctement vérifié. L’agrafage OCSP permet à Nginx de joindre une réponse de statut au dialogue TLS, ce qui évite au navigateur de contacter lui-même l’autorité de certification à chaque connexion.
Un réglage courant s’appuie sur ssl_stapling on, ssl_stapling_verify on, un fichier de confiance adapté avec ssl_trusted_certificate et un résolveur DNS fonctionnel. Le nom d’hôte du serveur OCSP doit pouvoir être résolu ; sans cette dépendance réseau, l’agrafage ne fonctionnera pas comme prévu.
- Chaîne de certificats : placer le certificat du site avant les intermédiaires dans le fichier utilisé par ssl_certificate.
- Agrafage OCSP : activer la vérification et fournir les certificats de confiance nécessaires.
- Cache partagé : choisir une taille adaptée au trafic et garder un délai de session cohérent.
- HSTS : n’ajouter includeSubDomains que si chaque sous-domaine fonctionne déjà en HTTPS.
HSTS est une protection côté navigateur, pas une suite cryptographique. Une durée longue ou l’option preload peut être difficile à annuler ; Atelier Lumen ne les active donc qu’après avoir contrôlé les sous-domaines et la disponibilité permanente de HTTPS.
Quand activer l’authentification TLS mutuelle
Le TLS classique authentifie le serveur auprès du navigateur. Avec le mTLS, le serveur demande également un certificat au client ; cette mesure convient aux API internes, aux interfaces d’administration et aux échanges entre services dont les identités sont maîtrisées.
Dans Nginx, ssl_client_certificate désigne l’autorité qui signe les certificats clients et ssl_verify_client on rend leur présentation obligatoire. Pour autoriser la connexion générale tout en contrôlant certains chemins, le mode optional permet d’examiner la variable $ssl_client_verify dans la logique de traitement.
Ce mécanisme n’est pas nécessaire pour un site public classique. L’activer sans procédure de distribution et de renouvellement des certificats peut bloquer des utilisateurs légitimes ; sa valeur dépend du contrôle réel exercé sur les clients.
Vérifier les suites et les protocoles TLS de Nginx
Un fichier de configuration correct ne prouve pas que le serveur présente le comportement attendu. Tester depuis un poste externe permet de confirmer le protocole négocié, la suite choisie, la chaîne de certificats et la prise en charge d’OCSP.
Après nginx -t, un rechargement contrôlé avec systemctl reload nginx applique les modifications sans redémarrage brutal. Les commandes OpenSSL ci-dessous permettent de tester séparément TLS 1.2 et TLS 1.3, si la version locale du client les prend en charge.
openssl s_client -connect exemple.com:443 -tls1_2
openssl s_client -connect exemple.com:443 -tls1_3
Un audit externe comme SSL Labs ou testssl.sh complète ces contrôles en détectant les protocoles anciens et les suites inattendues. Une note élevée dépend toutefois de l’ensemble du déploiement, pas uniquement de ssl_ciphers : certificat, chaîne, redirections et politiques de sécurité comptent aussi.
Pour Atelier Lumen, le contrôle ne s’arrête pas au premier test réussi : il est répété après une mise à jour de Nginx, d’OpenSSL ou du certificat. C’est cette vérification régulière qui transforme une configuration ponctuelle en politique de sécurité durable.
Questions fréquentes sur Nginx ssl_ciphers
La directive ssl_ciphers configure-t-elle les suites TLS 1.3 ?
Non. ssl_ciphers concerne principalement TLS 1.2 et les versions antérieures. Les suites TLS 1.3 sont gérées séparément par OpenSSL et peuvent être configurées avec ssl_conf_command Ciphersuites si les versions utilisées le permettent.
Faut-il encore autoriser TLS 1.0 ou TLS 1.1 ?
Pour un site web courant, non. Ces protocoles sont obsolètes ; privilégiez TLS 1.2 et TLS 1.3, puis vérifiez les besoins réels des clients avant tout compromis de compatibilité.
Que signifie Perfect Forward Secrecy ?
Cette propriété limite l’impact d’une compromission ultérieure de la clé privée du certificat : les anciennes sessions utilisant un échange éphémère comme ECDHE ne deviennent pas automatiquement déchiffrables.
Comment vérifier les suites cryptographiques réellement utilisées ?
Testez le serveur avec openssl s_client en précisant TLS 1.2 puis TLS 1.3, et complétez avec un audit externe comme SSL Labs ou testssl.sh pour examiner protocoles, certificats et suites acceptées.
