Configurer le domaine

Relier <login>.42.fr à la VM puis tester HTTPS.

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

Étape 97 — Trouver l’adresse IP de la VM

Objectif. Tu identifieras la machine vers laquelle le domaine local doit pointer.

État du projet avant cette étape. NGINX écoute sur le port 443 de la VM, mais le nom <login>.42.fr n’est pas encore relié à cette adresse.

Comprendre le changement

L’adresse utile est celle de l’interface réseau de la VM joignable depuis le navigateur. Ce n’est ni 127.0.0.1 dans tous les cas, ni l’IP privée d’un container.

Faire une seule chose

Affiche les adresses de la VM et teste celle qui est joignable depuis la machine où tourne ton navigateur.

À EXÉCUTER DANS🖥️ Dans la VM · depuis n’importe quel dossier

ip -brief address
hostname -I

Ce que fait chaque partie

ip -brief address : liste interfaces, état et adresses.
hostname -I : résume les IP locales de la VM.

Résultat attendu

Une adresse non loopback est identifiée et joignable depuis le client.

Si cela échoue

127.0.0.1 dans la VM désigne la VM elle-même ; depuis le Mac, 127.0.0.1 désigne le Mac. Vérifiez le mode bridge/NAT.

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.

J’ai identifié l’adresse IP de la VM.Je ne confonds pas IP de la VM et IP d’un container.La machine du navigateur peut joindre cette adresse.Je sais que l’adresse peut changer selon la configuration réseau de la VM.

Question de soutenance — Que modifie /etc/hosts ?

La résolution de noms de la machine cliente uniquement, pas le DNS public.

Étape 98 — Associer le domaine à l’IP

Objectif. Tu feras résoudre <login>.42.fr localement sans serveur DNS.

État du projet avant cette étape. Tu connais l’adresse de la VM et la valeur DOMAIN_NAME de srcs/.env.

Comprendre le changement

/etc/hosts est un carnet d’adresses local consulté avant le DNS public. La ligne doit être ajoutée sur la machine qui exécute le navigateur ou curl.

Faire une seule chose

Ajoute une seule ligne IP DOMAINE dans /etc/hosts de la machine cliente, puis vérifie la résolution.

Fichiers ou emplacements concernés

/etc/hosts sur la machine cliente

À EXÉCUTER DANS🖥️ Sur la machine qui ouvre le navigateur · remplacez IP et login

Avant de copier : remplacez <IP_VM><login> par vos valeurs.

sudo sh -c 'printf "\n<IP_VM> <login>.42.fr\n" >> /etc/hosts'

Ce que fait chaque partie

sudo : /etc/hosts appartient à root.
printf >> : ajoute une ligne sans remplacer les entrées existantes.
Le premier champ est l’IP de la VM ; le second le domaine exact.

Résultat attendu

getent hosts <login>.42.fr ou dscacheutil sur macOS retourne l’IP choisie.

Si cela échoue

Une ancienne ligne pour le même domaine peut gagner. Nettoyez les doublons manuellement et videz le cache DNS si nécessaire.

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 ligne contient l’IP réelle de la VM et mon login exact.getent hosts ou ping résout le domaine vers cette IP.Je n’ai pas ajouté le domaine dans un container.Je peux expliquer pourquoi cette configuration reste locale à la machine.

Question de soutenance — Que modifie /etc/hosts ?

La résolution de noms de la machine cliente uniquement, pas le DNS public.

Étape 99 — Ouvrir le site avec son vrai nom

Objectif. Tu vérifieras le trajet complet depuis la machine cliente.

État du projet avant cette étape. Le domaine se résout maintenant vers la VM où Docker publie le port 443 de NGINX.

Comprendre le changement

curl -k ignore uniquement la confiance du certificat autosigné ; il n’ignore ni une panne réseau, ni un mauvais port, ni une erreur NGINX.

Faire une seule chose

Teste l’URL HTTPS avec curl puis dans le navigateur. Ouvre aussi /wp-admin.

À EXÉCUTER DANS🖥️ Sur la machine cliente · depuis n’importe quel dossier

Avant de copier : remplacez <login> par vos valeurs.

getent hosts <login>.42.fr
curl -kI https://<login>.42.fr

Ce que fait chaque partie

getent hosts : confirme IP et résolution sur Linux.
curl -I : demande uniquement les en-têtes HTTP.
-k : accepte temporairement le certificat auto-signé pour le test.

Résultat attendu

Le nom retourne l’IP de la VM et curl reçoit un statut HTTP, souvent 200 ou une redirection WordPress.

Si cela échoue

Could not resolve host = /etc/hosts ; connection refused = port/NGINX ; timeout = réseau VM/firewall ; erreur certificat sans -k = confiance locale.

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.

curl reçoit une réponse HTTP via HTTPS.Le navigateur affiche le site après acceptation de l’avertissement local./wp-admin ouvre la page de connexion.L’URL utilise mon vrai login et le schéma https.

Question de soutenance — Que modifie /etc/hosts ?

La résolution de noms de la machine cliente uniquement, pas le DNS public.

Étape 100 — Tester les protocoles et les ports

Objectif. Tu prouveras que l’entrée est exactement celle demandée.

État du projet avant cette étape. Le site est accessible. Il faut maintenant tester aussi ce qui doit être refusé.

Comprendre le changement

Un test positif confirme TLS 1.2 et 1.3. Des tests négatifs confirment que TLS 1.0, TLS 1.1 et HTTP sur 80 ne sont pas disponibles.

Faire une seule chose

Lance chaque test séparément et note succès ou échec attendu. Ne considère pas un échec prévu comme une panne.

À EXÉCUTER DANS🖥️ Sur la machine cliente · depuis n’importe quel dossier

Avant de copier : remplacez <login> par vos valeurs.

openssl s_client -connect <login>.42.fr:443 -servername <login>.42.fr -tls1_2 </dev/null
openssl s_client -connect <login>.42.fr:443 -servername <login>.42.fr -tls1_3 </dev/null

Ce que fait chaque partie

s_client : ouvre une connexion TLS de diagnostic.
-connect : hôte et port.
-servername : envoie le nom SNI.
-tls1_2 / -tls1_3 : force la version testée.
</dev/null : ferme l’entrée après la négociation.

Résultat attendu

Chaque commande négocie la version forcée et affiche un cipher ; l’auto-signature peut produire verify error sans invalider la négociation.

Si cela échoue

no protocols available peut venir d’un client OpenSSL trop ancien ; handshake failure côté une seule version signale ssl_protocols ou support de build.

À EXÉCUTER DANS🖥️ OpenSSL/curl sur le client · Compose dans la VM

Avant de copier : remplacez <login> par vos valeurs.

openssl s_client -connect <login>.42.fr:443 -tls1 </dev/null
curl --connect-timeout 3 -I http://<login>.42.fr
docker compose -f srcs/docker-compose.yml ps

Ce que fait chaque partie

-tls1 : tente l’ancien TLS 1.0.
http:// : tente le port 80 par défaut.
--connect-timeout 3 : borne le test négatif.
compose ps : confirme les mappings réels.

Résultat attendu

TLS 1.0 échoue, curl HTTP ne se connecte pas et ps n’affiche que 443.

Si cela échoue

Si HTTP répond ou redirige, retirez listen 80 et tout mapping 80. Si TLS 1.0 négocie, corrigez ssl_protocols et recréez NGINX.

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.

La négociation TLS 1.2 réussit.La négociation TLS 1.3 réussit.TLS 1.0 et TLS 1.1 échouent.Le port 80 refuse la connexion ou ne répond pas.docker compose ps ne montre aucun port publié autre que 443.

Question de soutenance — Que modifie /etc/hosts ?

La résolution de noms de la machine cliente uniquement, pas le DNS public.