Chapitre 8.4 — TLS moderne & HSTS

⏱️ TL;DR — Avoir un certificat valide, c’est la base — pas la perfection. Ce chapitre durcit ta config TLS pour viser un A/A+ sur SSL Labs. Quatre gestes : (1) rediriger tout le HTTP vers HTTPS en 301 (Certbot le fait, ou un bloc Nginx manuel), pour que personne ne reste en clair ; (2) n’accepter que des protocoles modernes (TLS 1.2 et TLS 1.3, les vieux désactivés) ; (3) activer HSTS via l’en-tête Strict-Transport-Security, qui force le navigateur à n’utiliser que HTTPS pendant une durée donnée — puissant, mais à manier avec précaution ; (4) tester le résultat sur SSL Labs et corriger jusqu’au A. On survole aussi les autres en-têtes de sécurité (X-Content-Type-Options, X-Frame-Options, CSP — cités, à creuser ailleurs), les certificats wildcard (*.formacampus.fr, via DNS-01, quand tu as beaucoup de sous-domaines) et l’OCSP stapling. À la fin, FormaCampus est en HTTPS partout, moderne, noté A, renouvelé sans toi.

🎯 Objectifs

• Rediriger tout le trafic HTTP vers HTTPS proprement (code 301).
• Configurer les protocoles TLS modernes et désactiver les anciens.
• Comprendre, activer et sécuriser l’en-tête Strict-Transport-Security (HSTS).
• Connaître les autres en-têtes de sécurité à ajouter (et où les creuser).
• Tester ta configuration sur SSL Labs et viser un A/A+.
• Savoir quand un certificat wildcard (via DNS-01) se justifie.

Étape 1 — Rediriger tout le HTTP vers HTTPS

Un certificat installé ne sert à rien si les visiteurs continuent d’arriver en http://. Tant que le port 80 sert des pages en clair, un visiteur (ou un lien externe, ou un vieux favori) peut atterrir sur la version non chiffrée — et y rester. Il faut donc forcer tout le monde vers HTTPS.

La méthode : une redirection permanente (code HTTP 301) depuis HTTP vers HTTPS. Le 301 dit au navigateur (et aux moteurs de recherche) « cette ressource a définitivement déménagé vers l’adresse HTTPS » — le navigateur mémorise et ira directement en HTTPS les fois suivantes.

Si tu as répondu oui à la question de Certbot (« rediriger le trafic HTTP vers HTTPS ? »), c’est déjà fait : Certbot a ajouté le bloc de redirection tout seul. Sinon, ou si tu préfères le gérer à la main, voici le bloc Nginx :

# Bloc HTTP : ne fait que rediriger vers HTTPS
server {
    listen 80;
    server_name formacampus.fr www.formacampus.fr;
 
    # 301 = redirection permanente vers la meme URL en HTTPS
    return 301 https://$host$request_uri;
}

Décryptons : ce server écoute sur le port 80 (listen 80) pour les mêmes noms de domaine, et tout ce qu’il fait, c’est renvoyer un return 301 vers https://$host$request_uri — c’est-à-dire la même URL, mais en HTTPS. $host reprend le domaine demandé, $request_uri reprend le chemin et les paramètres. Aucun contenu n’est servi en clair : le port 80 ne fait plus que rediriger.

⚠️ Piège — Rediriger HTTP→HTTPS n’autorise pas à fermer le port 80. Il reste nécessaire pour deux raisons : la redirection elle-même a besoin que le port 80 réponde (sinon un visiteur en http:// obtient un timeout, pas une redirection), et le renouvellement Let’s Encrypt (challenge HTTP-01, chapitre 8.3) passe par le port 80. Ouvert et redirigé, jamais fermé.

Étape 2 — N’accepter que des protocoles modernes

Tous les protocoles TLS ne se valent pas. Les vieilles versions (SSL 3, TLS 1.0, TLS 1.1) ont des failles connues et n’ont plus lieu d’être. On ne veut accepter que TLS 1.2 et TLS 1.3.

Bonne nouvelle : Certbot, en configurant Nginx, applique déjà des réglages TLS raisonnables et modernes via un fichier d’options qu’il inclut dans ta config (quelque chose comme options-ssl-nginx.conf). Dans la plupart des cas, tu n’as rien à changer — les protocoles obsolètes sont déjà écartés. Si tu dois l’expliciter, la directive Nginx est :

# N'autoriser que les versions modernes de TLS
ssl_protocols TLSv1.2 TLSv1.3;

ssl_protocols TLSv1.2 TLSv1.3; dit à Nginx : n’accepte que ces deux versions, refuse tout le reste. Un vieux client qui ne parle que TLS 1.0 sera refusé — c’est voulu, ces clients sont rarissimes et non sécurisés.

💡 Réflexe — Ne recopie pas des blocs de réglages TLS trouvés sur de vieux tutoriels (listes de « cipher suites » interminables, options exotiques). Ils vieillissent mal et peuvent affaiblir ta config au lieu de la durcir. Fais confiance aux réglages par défaut de Certbot (tenus à jour) ou, si tu veux personnaliser, pars du générateur de configuration Mozilla SSL (profil « intermediate »), qui reflète l’état de l’art.

📚 La doc — Pour une config TLS moderne et à jour, la référence est le Mozilla SSL Configuration Generator : tu choisis Nginx, ta version, un profil de compatibilité, et il te donne les directives exactes. Couplé à la doc Nginx sur le module ssl, tu as tout ce qu’il faut sans rien inventer.

Étape 3 — HSTS : forcer HTTPS pour de bon

La redirection 301 a une faille subtile : la toute première requête d’un visiteur peut encore partir en HTTP (avant d’être redirigée). Sur cette première requête en clair, un attaquant en position d’homme du milieu pourrait intercepter. HSTS ferme cette fenêtre.

HSTS (HTTP Strict Transport Security) est un en-tête HTTP que ton serveur renvoie : Strict-Transport-Security. Il dit au navigateur : « pour ce domaine, pendant les X prochaines secondes, n’utilise jamais HTTP — passe directement en HTTPS, même si l’utilisateur tape http:// ou clique sur un vieux lien ». Le navigateur mémorise cette instruction et applique HTTPS avant même d’envoyer la moindre requête. Plus de première requête en clair.

Voici l’en-tête, ajouté dans le bloc server HTTPS de Nginx :

# HSTS : force HTTPS pendant 6 mois, sous-domaines inclus
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains" always;

Décomposons la valeur de l’en-tête :

• max-age=15768000 : la durée en secondes pendant laquelle le navigateur doit forcer HTTPS (ici environ 6 mois). Tant que ce délai court, il n’essaiera jamais le HTTP pour ce domaine.
• includeSubDomains : applique la règle aussi à tous les sous-domaines. À n’activer que si tous tes sous-domaines sont bien en HTTPS.
• always (paramètre Nginx) : envoie l’en-tête sur toutes les réponses, y compris les pages d’erreur.

🔒 Sécurité — HSTS est puissant mais engageant. Une fois qu’un navigateur a mémorisé ton max-age, il refusera catégoriquement le HTTP pour ton domaine pendant toute la durée — impossible pour l’utilisateur de « passer outre ». Si un jour ton HTTPS casse (cert expiré, erreur de config) et que HSTS est actif, les visiteurs ne pourront plus accéder au site du tout, même en acceptant le risque. C’est le but (empêcher le contournement), mais ça veut dire : n’active HSTS que quand ton HTTPS est solide et le renouvellement testé.

💡 Réflexe — Introduis HSTS progressivement. Commence avec un max-age court (par exemple quelques minutes), vérifie que tout va bien, puis augmente graduellement jusqu’à plusieurs mois. Un max-age long posé trop tôt, alors que ton HTTPS n’est pas fiable, peut verrouiller tes visiteurs hors du site. On monte la durée une fois qu’on est confiant.

La liste de préchargement (preload) — avec des pincettes

Il existe un cran au-dessus : la directive preload et l’inscription de ton domaine sur la liste de préchargement HSTS, une liste intégrée en dur dans les navigateurs. Un domaine sur cette liste est forcé en HTTPS dès la première visite, sans même avoir besoin d’un premier contact.

Mais attention : le preload est un engagement quasi irréversible. En retirer un domaine est lent et compliqué (il faut attendre la diffusion d’une nouvelle version des navigateurs). Ne l’active que si tu es absolument certain de rester en HTTPS indéfiniment, sur le domaine et tous ses sous-domaines. Pour la plupart des projets, HSTS sans preload suffit largement.

⚠️ Piège — Ajouter preload et soumettre son domaine « pour faire propre » sans mesurer l’engagement. Si tu dois ensuite servir un sous-domaine en HTTP (un legacy, un outil interne), tu es bloqué pour des mois. Le preload n’est pas une case à cocher de plus : c’est une décision d’architecture. Dans le doute, ne l’active pas.

Étape 4 — Les autres en-têtes de sécurité (survol)

TLS protège le transport. D’autres en-têtes HTTP durcissent le comportement du navigateur face à ta page. On les cite ici — leur maîtrise complète dépasse ce cours d’infra et relève de la sécurité applicative (le cours Accessibilité & sécurité web et la doc MDN les détaillent) :

On les ajoute avec add_header dans Nginx, exactement comme HSTS. Le plus délicat est la CSP (Content-Security-Policy) : mal réglée, elle casse ton site (scripts bloqués) ; bien réglée, c’est une défense majeure contre les injections. On te renvoie à une ressource dédiée pour la construire pas à pas — ne la copie pas au hasard.

📚 La doc — La référence vivante pour tous ces en-têtes, c’est MDN Web Docs (chaque en-tête a sa page avec exemples et pièges). Pour auditer ce que ton site renvoie déjà, des scanners en ligne comme Mozilla Observatory ou Security Headers te notent et listent ce qui manque. Utile pour prioriser.

Étape 5 — Tester sur SSL Labs

Comment savoir si ta config TLS est bonne ? On la mesure. L’outil de référence, gratuit, est le SSL Labs Server Test (de Qualys) : tu saisis ton domaine, il analyse en profondeur ta configuration TLS (protocoles acceptés, force du certificat, chaîne complète, vulnérabilités connues, HSTS…) et te donne une note de F à A+.

L’objectif : viser A ou A+. Avec un certificat Let’s Encrypt correctement installé, les protocoles modernes par défaut de Certbot, la redirection HTTP→HTTPS et HSTS activé, tu obtiens un A sans effort particulier ; le A+ demande généralement d’avoir HSTS bien configuré. Si tu obtiens moins, le rapport te dit exactement quoi corriger (protocole obsolète encore actif, chaîne incomplète, etc.).

🐚 Au terminal — Un aperçu rapide en ligne de commande, en complément de SSL Labs :

# affiche le certificat presente et les infos de connexion TLS
curl -vI https://formacampus.fr
 
# inspecte le certificat et la chaine servie
echo | openssl s_client -connect formacampus.fr:443 -servername formacampus.fr

curl -vI montre l’en-tête et confirme le handshake TLS ; openssl s_client affiche le certificat réellement servi et sa chaîne — pratique pour vérifier que la chaîne est complète (le piège du chapitre 8.1). Mais pour une note complète et fiable, SSL Labs reste la référence.

🧭 Sur FormaCampus — Config type de l’équipe : certificats Let’s Encrypt sur formacampus.fr, www et api ; redirection 301 HTTP→HTTPS sur les trois ; ssl_protocols TLSv1.2 TLSv1.3 (réglages Certbot) ; HSTS activé — d’abord avec un max-age court pendant une semaine de vérification, puis porté à 6 mois avec includeSubDomains une fois l’équipe confiante (mais sans preload, pour garder la liberté d’un sous-domaine interne futur). Passage sur SSL Labs : note A. C’est coché sur la checklist de mise en prod. La CSP et les autres en-têtes applicatifs sont notés comme chantier côté équipe front, à traiter séparément.

Aller plus loin : wildcard et OCSP stapling (survol)

Certificats wildcard

Un certificat wildcard couvre tous les sous-domaines d’un coup : *.formacampus.fr vaut pour www., api., blog., et n’importe quel futur sous-domaine, sans réémettre. Utile quand tu as beaucoup de sous-domaines, ou un nombre variable/imprévisible (par exemple un sous-domaine par client : client1.formacampus.fr, client2.formacampus.fr…).

Le prix à payer : Let’s Encrypt exige le challenge DNS-01 pour émettre un wildcard (impossible via HTTP-01). Il faut donc créer un enregistrement TXT dans ta zone DNS pour prouver le contrôle du domaine — et, pour que le renouvellement reste automatique, il faut que Certbot puisse créer ce TXT tout seul via l’API de ton hébergeur DNS (avec le greffon DNS correspondant). Plus de mise en place que HTTP-01, mais indispensable dès que les sous-domaines se multiplient.

Règle simple : quelques sous-domaines connus → liste-les en -d (HTTP-01), c’est plus simple. Beaucoup de sous-domaines ou création dynamique → wildcard via DNS-01.

OCSP stapling

Quand un navigateur reçoit ton certificat, il peut vouloir vérifier qu’il n’a pas été révoqué. L’OCSP stapling est une optimisation : ton serveur va chercher lui-même cette preuve de non-révocation auprès de la CA et l’agrafe (staple) à la réponse TLS. Le navigateur n’a alors plus à contacter la CA de son côté → connexion plus rapide et meilleure confidentialité (la CA ne voit pas qui visite ton site). Nginx l’active avec quelques directives ; les configs modernes (Mozilla, Certbot) le prévoient souvent. On le cite ici — c’est un bonus de performance/vie privée, pas un prérequis de sécurité. La doc Nginx et le générateur Mozilla montrent comment l’activer.

On boucle la partie

Récapitulons ce que tu sais faire, du chapitre 8.1 à ici : tu comprends ce que TLS chiffre, prouve et garantit ; tu obtiens un certificat gratuit chez Let’s Encrypt en une commande ; tu le fais renouveler tout seul et tu l’as testé ; et tu durcis ta config jusqu’au A sur SSL Labs. formacampus.fr répond désormais en HTTPS, partout, avec un cadenas fiable qui se renouvelle sans toi. Le dernier maillon web de la façade est en place.

La façade Nginx + HTTPS est complète. La Partie 9 — Déployer Node / Next.js attaque maintenant ce qui vit derrière ce proxy : faire tourner ton application comme un vrai service de production, qui redémarre au boot et après un crash.

✏️ Exercices

Exercice 1 — Écris la redirection. Écris le bloc server Nginx qui écoute sur le port 80 pour formacampus.fr et www.formacampus.fr et redirige tout le trafic en HTTPS de façon permanente. Explique pourquoi on n’en profite pas pour fermer le port 80.

server {
    listen 80;
    server_name formacampus.fr www.formacampus.fr;
    return 301 https://$host$request_uri;
}

Exercice 2 — HSTS avec prudence. Un collègue veut activer HSTS avec max-age=63072000 (2 ans) et preload dès le premier jour de la mise en HTTPS. Quels risques cours-tu, et que recommandes-tu ?

Exercice 3 — Wildcard ou liste explicite ? FormaCampus veut désormais offrir un sous-domaine par client (client1.formacampus.fr, client2.formacampus.fr…), créés dynamiquement à chaque inscription. Quel type de certificat, quel challenge, et pourquoi ?

🧠 Quiz de révision

Fin de la Partie 8. Ta façade web est complète : Nginx en HTTPS, certificat gratuit, renouvelé et durci. On passe à ce qui tourne derrière : Partie 9 — Déployer Node / Next.js.