Cours Linux / Installer Nginx et publier une page en HTTP puis HTTPS

Linux

Date de création 2026-10-15 Dernière modification 2026-10-26

Publier une page avec Nginx demande plus que l’installation du paquet : le serveur doit lire le bon répertoire, écouter le bon port et rester joignable à travers le pare-feu, le DNS et, pour HTTPS, un certificat valide. Vérifiez d’abord une page HTTP localement, puis depuis un autre client ; n’ajoutez un domaine public et TLS qu’une fois ces deux contrôles réussis.

Ce guide vise une machine virtuelle Ubuntu 26.04 LTS ou Rocky Linux 9 avec sudo et une console de récupération. Les chemins d’inclusion Nginx, paquets et méthodes de certificat dépendent de la version et des dépôts utilisés ; lisez la configuration réellement installée avant de la modifier. Pour un échec réseau, suivez le diagnostic de connexion par étapes ; avant l’ouverture publique, appliquez les contrôles du cours de protection du serveur.

Préparer la VM, le nom de test et les ports

Disposez d’un compte sudo, d’une console de secours et, pour la phase HTTPS, d’un domaine que vous contrôlez réellement. linux-course.test sert uniquement au test local : le suffixe .test est réservé aux essais et ne doit pas être présenté comme un domaine public à certifier. Une VM derrière NAT peut demander un transfert de ports, et un fournisseur cloud peut imposer un filtre indépendant du pare-feu du système. Vérifiez avant installation si un autre service occupe 80 ou 443 :

cat /etc/os-release
sudo ss -lntp

Si un site existe déjà, inventoriez ses configurations et sauvegardez-les ; ne supprimez pas le serveur par défaut ni un autre bloc de site pour suivre ce cours. Notez aussi l’adresse de la VM et le mode réseau choisi. Le cours de préparation de la machine virtuelle aide à établir la console et le réseau de pratique.

Installer Nginx selon la distribution

Sur Ubuntu, utilisez le premier bloc ; sur Rocky Linux, le second. Examinez les paquets proposés et les politiques de dépôts avant de confirmer. Une erreur de démarrage peut indiquer que le port est déjà utilisé ou qu’une configuration préexistante ne passe pas la validation.

sudo apt update
sudo apt install nginx curl
sudo systemctl enable --now nginx

sudo dnf install nginx curl
sudo systemctl enable --now nginx

Vérifiez systemctl status nginx --no-pager et sudo nginx -t. enable prépare le démarrage automatique et --now démarre aussi le service immédiatement ; ces actions ne prouvent pas que votre futur site répondra correctement. La version du paquet est celle de votre dépôt, pas forcément la dernière version publiée par Nginx.

Créer une page de test et un bloc serveur distincts

Les chemins ci-dessous sont réservés à cette VM d’exercice : /var/www/linux-course-fr et /etc/nginx/conf.d/linux-course-fr.conf. Vérifiez qu’aucun n’existe déjà, ni comme lien symbolique. L’exemple suppose que le nginx.conf installé inclut les fichiers /etc/nginx/conf.d/*.conf dans son contexte http ; si ce n’est pas le cas, adaptez l’emplacement à la vraie structure d’inclusion. Évitez tout écrasement d’un site existant.

root=/var/www/linux-course-fr
site=/etc/nginx/conf.d/linux-course-fr.conf
if sudo test -e "$root" || sudo test -L "$root" ||
   sudo test -e "$site" || sudo test -L "$site"; then
  printf 'Chemin déjà utilisé : choisir un autre nom\n' >&2
else
  sudo install -d -m 755 "$root" || exit 1
  printf '%s\n' '<!doctype html><html lang="fr"><meta charset="utf-8"><title>Cours Linux</title><h1>Le serveur du cours fonctionne</h1></html>' |
    sudo tee "$root/index.html" > /dev/null || exit 1
  sudo chmod 644 "$root/index.html" || exit 1
  sudo tee "$site" > /dev/null <<'EOF' || exit 1
server {
    listen 80;
    server_name linux-course.test;
    root /var/www/linux-course-fr;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}
EOF
  sudo nginx -t
fi

Le <h1> du bloc est le titre de la page HTML d’essai servie par Nginx, pas un titre dans cet article WordPress. Le document est en français et sa déclaration lang="fr" correspond au texte. Le guide officiel Nginx explique le répertoire root, les blocs server et le rechargement. Ce test suppose un utilisateur Nginx autorisé à traverser les répertoires et à lire le fichier ; vérifiez ces droits si vous obtenez HTTP 403.

Si sudo nginx -t échoue, corrigez la ligne signalée avant le rechargement. Si le bloc s’est arrêté au milieu, inspectez les deux chemins créés et réparez uniquement cet exercice ; ne relancez pas le bloc en forçant un écrasement. Sur une VM d’exercice sans écrivain concurrent, le contrôle préalable évite de remplacer des fichiers existants. Il ne constitue pas une protection contre des modifications simultanées de ces chemins.

Tester HTTP sur la boucle locale avant d’ouvrir le réseau

Ne rechargez Nginx qu’après un test de configuration réussi. L’option curl --resolve associe le nom de test à 127.0.0.1 pour cette requête uniquement : elle ne change ni le DNS du système ni les réglages du navigateur.

sudo nginx -t
sudo systemctl reload nginx
curl -i --resolve linux-course.test:80:127.0.0.1 http://linux-course.test/

Attendez une réponse HTTP 200 et le texte « Le serveur du cours fonctionne ». Si vous recevez la page Nginx par défaut, vérifiez le nom d’hôte de la requête, server_name et les blocs réellement chargés : Nginx sélectionne notamment le serveur selon l’adresse, le port et l’en-tête Host, comme le décrit sa documentation sur le traitement des requêtes. Un HTTP 403 oriente vers les droits ou SELinux ; un HTTP 404 vers le chemin, le fichier ou le bloc sélectionné.

Vérifier SELinux, le pare-feu et la réponse distante

Sur Rocky Linux avec SELinux actif, lisez le contexte de /var/www/linux-course-fr et les refus d’accès avant toute correction. Pour ce chemin sous le répertoire web ordinaire, restorecon peut restaurer le contexte prévu par la politique ; un chemin personnalisé hors de l’arborescence web peut demander une règle de contexte persistante adaptée. N’arrêtez pas SELinux et n’attribuez pas 777 à tous les fichiers pour faire disparaître un 403.

Après succès local, autorisez HTTP 80/tcp dans le pare-feu de l’hôte et, s’il existe, dans celui du fournisseur. Pour un futur HTTPS, prévoyez aussi 443/tcp, mais gardez l’accès SSH validé. Sur Rocky Linux, ciblez la zone firewalld de l’interface réellement utilisée et distinguez règle temporaire et permanente ; sur Ubuntu, vérifiez la politique UFW et la portée des sources. Le cours lié plus haut fournit ces contrôles et le retour arrière.

Depuis un autre ordinateur, essayez curl -H 'Host: linux-course.test' http://ADRESSE_REELLE/ en remplaçant le nom de l’adresse. Si localhost répond mais pas le client, examinez l’adresse d’écoute, la route, NAT et les filtres ; le même contenu inaccessible à distance ne prouve pas un défaut de la page HTML. Si un code HTTP revient, le réseau a au moins atteint un serveur : examinez le bloc sélectionné, les fichiers et, pour une application derrière Nginx, son propre état. Ne transmettez ni mot de passe ni jeton pendant ce test HTTP non chiffré.

Passer à un vrai domaine et à HTTPS

La phase suivante exige un domaine public que vous administrez, un serveur joignable selon la méthode de validation choisie et une politique de sauvegarde des configurations. linux-course.test ne remplit pas ces conditions. Suivez l’ordre ci-dessous, en examinant les changements proposés par l’outil de certificat :

Pointez les enregistrements DNS A et, seulement si IPv6 fonctionne, AAAA du vrai domaine vers les adresses publiques prévues. Vérifiez depuis un réseau externe la résolution et l’accès HTTP.
Remplacez server_name par ce domaine dans le bloc de l’exercice ; exécutez sudo nginx -t, rechargez Nginx et vérifiez la réponse HTTP par le nom public.
Choisissez la méthode d’installation de Certbot pour votre distribution et Nginx dans les instructions officielles Certbot. Confirmez que le greffon Nginx requis est installé dans le même environnement que Certbot.
Après avoir sauvegardé le bloc de site, exécutez sudo certbot --nginx -d DOMAINE_REEL en remplaçant l’espace réservé. Certbot peut modifier la configuration Nginx ; lisez son résultat et contrôlez la configuration finale.
Vérifiez depuis l’extérieur le certificat, le nom, la chaîne, l’expiration, la réponse HTTPS et la redirection voulue. Exécutez sudo certbot renew --dry-run pour tester le mécanisme de renouvellement, puis vérifiez la planification automatique réellement installée.

La validation HTTP-01 de Let’s Encrypt demande l’accès public au port 80 ; si ce chemin n’est pas possible, envisagez une méthode DNS-01 adaptée à votre DNS plutôt que de déclarer le certificat obtenu. Les types de validation officiels décrivent cette différence. Un test local HTTP réussi ne vaut ni preuve de propriété du domaine ni preuve de déploiement HTTPS. La documentation de Certbot détaille les greffons, la modification du serveur et le renouvellement.

Lire un échec et retirer uniquement l’exercice

Relevez l’heure du test et l’URL exacte, puis examinez l’état de l’unité, les messages du démarrage courant et la validation de configuration. Consultez également le fichier error_log réellement configuré pour le site ; n’en supposez pas le chemin.

systemctl status nginx --no-pager
journalctl -b -u nginx -n 50 --no-pager
sudo nginx -t

Pour revenir en arrière, sauvegardez puis retirez seulement linux-course-fr.conf si vous l’avez créé, validez avec nginx -t et rechargez. Examinez avant suppression si le répertoire HTML, les règles de pare-feu, les entrées DNS ou un certificat sont encore utilisés. Ne retirez ni un autre site, ni un certificat partagé, ni la règle SSH. Si la production est en jeu, restaurez la configuration sauvegardée et vérifiez une réponse depuis le même client qu’avant le changement.

Linux