Assembler les deux hôtes et HTTPS

Un hôte virtuel correct ne suffit pas si un nom de domaine est associé au mauvais fichier ou à la mauvaise racine. Vous allez contrôler ensemble les deux hôtes applicatifs, leurs fichiers de configuration et le passage de HTTP à HTTPS avant de mettre la configuration en service.

Le contrat du projet utilise site.example.test et api.example.test, avec les racines /var/www/application et /var/www/api. Les intitulés enovatic.be de cette étape désignent le scénario pédagogique ; ne remplacez pas les domaines du contrat par des noms différents dans les fichiers ou les tests.

1. Contrôler les fichiers des deux hôtes

La configuration doit rester séparée : site-http.conf porte les hôtes du site principal, site-https.conf ses paramètres TLS et site-secondaire.conf l’hôte secondaire. Vérifiez que les fichiers sont installés dans le répertoire de configuration des sites de votre distribution et que les noms, racines, chemins de certificat et journaux correspondent aux valeurs réellement préparées.

sudo ls -l /etc/apache2/sites-available/site-http.conf /etc/apache2/sites-available/site-https.conf /etc/apache2/sites-available/site-secondaire.conf
sudo grep -nE 'ServerName|ServerAlias|DocumentRoot|SSLCertificate(File|KeyFile)|ErrorLog|CustomLog|Redirect' /etc/apache2/sites-available/site-http.conf /etc/apache2/sites-available/site-https.conf /etc/apache2/sites-available/site-secondaire.conf

Les trois fichiers sont présents. Les directives affichées permettent de vérifier les noms, racines, certificats et journaux configurés. Adaptez le chemin /etc/apache2/sites-available si votre distribution utilise un autre emplacement.

L’hôte principal sert /var/www/application et l’hôte secondaire /var/www/api. L’hôte HTTP doit rediriger les deux noms vers HTTPS en conservant le chemin ; l’hôte HTTPS doit présenter le certificat préparé pour les noms qu’il reçoit. Ces contrôles reprennent les réglages de configuration et de certificat vus dans les leçons précédentes.

2. Activer les fichiers et valider avant rechargement

Activez les trois fichiers d’hôtes virtuels, puis contrôlez quels sites Apache prendra en compte. Cette étape prépare la configuration ; elle ne prouve pas encore que les requêtes arrivent au bon hôte.

sudo a2ensite site-http.conf site-https.conf site-secondaire.conf
sudo apachectl -S
sudo apachectl configtest

La commande apachectl -S récapitule les hôtes virtuels reconnus. Le test de configuration doit afficher « Syntax OK » ; en cas d’erreur, corrigez-la et relancez le test avant toute autre action.

N’exécutez le rechargement que si apachectl configtest réussit. Si le test échoue, ne rechargez pas Apache : le message indique généralement le fichier et la ligne à examiner. Une fois la configuration valide, le rechargement applique les fichiers activés sans interrompre normalement les connexions en cours.

sudo apachectl configtest && sudo systemctl reload apache2

Syntax OK, puis rechargement du service. Sur les systèmes où le service porte un autre nom, utilisez le nom relevé dans la leçon consacrée au service Apache.

3. Vérifier les réponses par nom d’hôte

Les tests doivent viser le serveur qui héberge Apache tout en envoyant le bon nom d’hôte. Remplacez IP_DU_SERVEUR par son adresse réelle. L’option --resolve force temporairement l’adresse utilisée par curl : elle permet de tester chaque nom sans dépendre d’une modification DNS locale.

curl -sSI --resolve site.example.test:80:IP_DU_SERVEUR http://site.example.test/
curl -sSI --resolve api.example.test:80:IP_DU_SERVEUR http://api.example.test/
curl -sSI --resolve site.example.test:443:IP_DU_SERVEUR https://site.example.test/
curl -sSI --resolve api.example.test:443:IP_DU_SERVEUR https://api.example.test/
curl -sSI --resolve site.example.test:80:IP_DU_SERVEUR http://site.example.test/accueil

Les deux requêtes HTTP doivent répondre par une redirection permanente vers le même nom en HTTPS, chemin conservé. Les requêtes HTTPS doivent atteindre le bon hôte et retourner une réponse réussie, par exemple HTTP/1.1 200 OK. /accueil doit être conservé lors de la redirection.

Avec -I, curl affiche les en-têtes de réponse, notamment le code HTTP et l’en-tête Location pour les redirections. Pour HTTPS, curl vérifie aussi le certificat présenté ; si cette vérification échoue, examinez le nom couvert et les chemins de certificat plutôt que de masquer l’erreur avec une option qui désactive la validation TLS.

À retenir

• Conservez un fichier de configuration distinct pour chaque hôte prévu par le contrat du projet.
• Vérifiez les correspondances entre noms, racines de documents et certificats avant l’activation.
• Testez la configuration et ne rechargez Apache qu’après un résultat « Syntax OK ».
• Vérifiez séparément HTTP et HTTPS pour chaque nom, puis contrôlez que /accueil conserve son chemin dans la redirection.

Dans la prochaine leçon, vous exécuterez une recette des URL et documenterez des cas de refus d’accès et d’erreur serveur.