Configurer TLS

Progression d’apprentissage0 / 404

0 / 16 validations dans ce chapitre

Réinitialiser la progression

Configurer certificat, port 443 et protocoles autorisés.

Dans ce chapitre : 4 étapes et 16 preuves de validation.

Étape 82 — Comprendre ce que TLS protège

Objectif. Tu distingueras le port, le protocole et le certificat.

État du projet avant cette étape. L’image NGINX existe, mais sa configuration est vide et aucun service NGINX n’est encore dans Compose.

Comprendre le changement

Le port 443 est l’adresse d’entrée. TLS chiffre la connexion. Le certificat permet au serveur de présenter une identité. Ce sont trois notions différentes.

Exigence du sujet · p. 7

NGINX doit accepter uniquement TLS 1.2 ou TLS 1.3 sur le port 443.

Faire une seule chose

Avant de configurer NGINX, reformule le trajet : le navigateur ouvre 443, négocie TLS, puis envoie une requête HTTP à l’intérieur du tunnel chiffré.

Prouver que c’est correct

Preuves de validation 0 / 3

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

Je distingue HTTPS, TLS, certificat et port 443.Je sais qu’un certificat autosigné chiffre malgré l’avertissement du navigateur.Je peux expliquer pourquoi TLS 1.0 et TLS 1.1 doivent échouer.

Question de soutenance — Un certificat autosigné chiffre-t-il ?

Oui. Il chiffre la connexion, mais le navigateur ne lui fait pas confiance automatiquement.

Étape 83 — Écrire la configuration HTTPS

Objectif. Tu configureras le seul point d’entrée de la stack.

État du projet avant cette étape. Le certificat sera généré par l’entrypoint. NGINX doit maintenant savoir où l’écouter et quoi servir.

Comprendre le changement

Le bloc server écoute 443 avec TLS, utilise le certificat, sert /var/www/html et transmet les fichiers PHP à wordpress:9000 par FastCGI.

Exigence du sujet · p. 7

NGINX seul expose 443 ; seuls TLS 1.2 et 1.3 sont autorisés ; WordPress est joint par le réseau Docker.

Faire une seule chose

Écris nginx.conf. Lis chaque directive et relie-la au trajet réseau avant de continuer.

Fichiers ou emplacements concernés

• srcs/requirements/nginx/conf/nginx.conf

À ÉCRIRE DANS📄 srcs/requirements/nginx/conf/default.conf

Copier

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name _;

    ssl_certificate     /etc/nginx/tls/inception.crt;
    ssl_certificate_key /etc/nginx/tls/inception.key;
    ssl_protocols TLSv1.2 TLSv1.3;

    root /var/www/html;
    index index.php index.html;
    client_max_body_size 32m;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass wordpress:9000;
    }
}

Ce que fait chaque partie

1. listen 443 ssl : aucune écoute HTTP 80.
2. ssl_protocols : autorise seulement 1.2 et 1.3.
3. root : fichiers WordPress montés dans NGINX.
4. try_files : route les URLs WordPress vers index.php.
5. fastcgi_pass wordpress:9000 : joint PHP-FPM par DNS Compose.

Résultat attendu

nginx -t valide le fichier et HTTPS sert WordPress.

Si cela échoue

502 indique souvent PHP-FPM/réseau ; 404 PHP indique un volume non partagé ou SCRIPT_FILENAME erroné.

Prouver que c’est correct

Preuves de validation 0 / 5

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

listen contient 443 ssl et aucun listen 80.ssl_protocols contient seulement TLSv1.2 TLSv1.3.root pointe vers /var/www/html.fastcgi_pass pointe vers wordpress:9000 et non localhost.Aucune IP de container n’est écrite en dur.

Question de soutenance — Un certificat autosigné chiffre-t-il ?

Oui. Il chiffre la connexion, mais le navigateur ne lui fait pas confiance automatiquement.

Étape 84 — Terminer le démarrage de NGINX

Objectif. Tu feras de NGINX le vrai processus principal du container.

État du projet avant cette étape. Le script sait créer le certificat et la configuration est prête.

Comprendre le changement

nginx -t refuse de démarrer si la syntaxe est invalide. exec nginx -g ‘daemon off;’ remplace le script par NGINX au premier plan : NGINX devient PID 1.

Interdit par le sujet · p. 7

Les containers ne doivent pas être maintenus artificiellement avec tail -f, sleep infinity, une boucle ou un shell nu.

Faire une seule chose

Ajoute le test de configuration puis la commande exec à la fin de entrypoint.sh.

Fichiers ou emplacements concernés

• srcs/requirements/nginx/tools/entrypoint.sh

À EXÉCUTER DANS📄 Dernières lignes de srcs/requirements/nginx/tools/entrypoint.sh

Copier

nginx -t
exec nginx -g 'daemon off;'

Ce que fait chaque partie

1. nginx -t : refuse de démarrer avec une configuration invalide.
2. exec : remplace le shell.
3. daemon off : conserve NGINX au premier plan.

Résultat attendu

docker top nginx montre nginx master en PID principal, puis ses workers.

Si cela échoue

Si nginx -t échoue, corrigez le fichier ou les chemins TLS ; n’ajoutez pas une commande factice.

Prouver que c’est correct

Preuves de validation 0 / 4

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

Le script exécute nginx -t avant le lancement.La dernière ligne utilise exec.NGINX reste au premier plan avec daemon off.Aucun processus factice ne maintient le container vivant.

Question de soutenance — Un certificat autosigné chiffre-t-il ?

Oui. Il chiffre la connexion, mais le navigateur ne lui fait pas confiance automatiquement.

Étape 85 — Reconstruire l’image complète

Objectif. Tu vérifieras ensemble certificat, configuration et vrai processus.

État du projet avant cette étape. Les trois fichiers NGINX ont maintenant leur contenu final.

Comprendre le changement

Une reconstruction est obligatoire : une image déjà créée ne récupère pas automatiquement les modifications faites dans le Dockerfile ou les fichiers copiés.

Exigence du sujet · pp. 6–9

L’image finale doit démarrer NGINX comme service réel.

Faire une seule chose

Reconstruis l’image puis lance-la temporairement avec le volume WordPress et le réseau déjà créés. Arrête ce test après avoir lu les logs.

À EXÉCUTER DANSDans la VM · racine du repository

Copier

docker build -t inception-nginx srcs/requirements/nginx
docker run --rm --name nginx-test --network inception -p 443:443 -v wordpress_data:/var/www/html -e DOMAIN_NAME=${LOGIN}.42.fr inception-nginx

Ce que fait chaque partie

1. build incorpore les derniers fichiers.
2. --rm supprime ce container de test à son arrêt.
3. --network inception lui permet de résoudre wordpress.
4. -p 443:443 publie temporairement HTTPS.
5. -v lui donne la même copie des fichiers WordPress.

Résultat attendu

nginx -t annonce une syntaxe correcte puis le processus reste au premier plan.

Si cela échoue

Si wordpress est introuvable, vérifie que la stack des deux premiers services tourne sur le réseau inception. Quitte avec Ctrl+C.

Prouver que c’est correct

Preuves de validation 0 / 4

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

La reconstruction termine sans erreur.Le test de configuration NGINX réussit.Le container reste actif grâce à NGINX lui-même.J’ai arrêté et supprimé le container de test avant la suite.

Question de soutenance — Un certificat autosigné chiffre-t-il ?

Oui. Il chiffre la connexion, mais le navigateur ne lui fait pas confiance automatiquement.