Rediriger le trafic HTTP vers HTTPS

Si votre site répond en HTTP, les échanges avec le navigateur ne sont pas protégés par TLS. Vous allez faire rediriger les deux noms du projet vers leur version HTTPS et vérifier que le chemin demandé reste présent dans la nouvelle adresse.

Les leçons précédentes ont préparé les hôtes virtuels, activé mod_rewrite et présenté l’obtention d’un certificat. Dans le projet fil rouge, les noms site.example.test et api.example.test sont réservés : ils ne peuvent pas recevoir de certificat public. Les chemins de certificats ci-dessous correspondent à une installation réelle de Certbot ; utilisez des noms publics contrôlés sur le serveur de production.

Déclarer la redirection HTTP

Dans apache/site-http.conf, l’hôte principal reçoit les requêtes sur le port 80 et les redirige vers le même chemin sur HTTPS. Redirect permanent renvoie une réponse de redirection permanente ; le navigateur voit l’URL HTTPS et effectue une nouvelle requête. La règle existante sur /accueil reste dans le bloc HTTPS, où elle pourra servir index.html après la redirection.

<VirtualHost *:80>
    ServerName site.example.test
    DocumentRoot /var/www/application

    Redirect permanent / https://site.example.test/
</VirtualHost>

Activer HTTPS pour l’hôte principal

Un hôte HTTPS écoute sur le port 443. SSLEngine on active TLS pour ce bloc ; les deux directives de certificat indiquent à Apache le certificat et sa clé privée. Ici, le certificat est supposé couvrir les deux noms, comme le certificat multidomaine préparé à la leçon précédente. Gardez la règle /accueil dans le bloc du site principal : elle réécrit en interne le chemin après l’arrivée en HTTPS, sans modifier l’adresse affichée.

<VirtualHost *:443>
    ServerName site.example.test
    DocumentRoot /var/www/application

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/site.example.test/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/site.example.test/privkey.pem

    RewriteEngine On
    RewriteRule ^/accueil/?$ /index.html [END]
</VirtualHost>

Rediriger le second hôte

Le second hôte conserve sa racine de documents dans apache/site-secondaire.conf. Ajoutez-y son hôte HTTP et son hôte HTTPS : le premier redirige vers https://api.example.test, tandis que le second sert ses fichiers avec le même certificat. La barre oblique finale de la cible de Redirect permet à Apache de conserver le suffixe de chemin demandé, par exemple /documentation.

<VirtualHost *:80>
    ServerName api.example.test
    DocumentRoot /var/www/api

    Redirect permanent / https://api.example.test/
</VirtualHost>

<VirtualHost *:443>
    ServerName api.example.test
    DocumentRoot /var/www/api

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/site.example.test/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/site.example.test/privkey.pem
</VirtualHost>

Tester avant de recharger

Sur Debian ou Ubuntu, activez les fichiers concernés s’ils ne le sont pas déjà, puis testez la configuration avant tout rechargement. Si le test échoue, corrigez le fichier indiqué et recommencez le test ; ne rechargez pas Apache tant qu’il ne réussit pas. Les commandes d’activation de site ci-dessous sont à exécuter uniquement pour les fichiers qui ne sont pas déjà activés.

sudo a2ensite site-http.conf site-https.conf site-secondaire.conf
sudo apachectl configtest
# Continuer uniquement si la sortie indique : Syntax OK
sudo systemctl reload apache2

Syntax OK

Vérifiez les redirections avec des requêtes HEAD. Sur un serveur réel, les noms doivent résoudre vers ce serveur et le certificat doit être valide ; remplacez-les par les noms publics du certificat. Avec les noms réservés en .test, une résolution locale et un certificat de test sont nécessaires pour valider HTTPS. N’utilisez -k que pour un contrôle temporaire de la réponse TLS, pas pour conclure que le certificat est valide.

curl -I http://site.example.test/accueil
curl -I http://api.example.test/documentation
curl -I https://site.example.test/accueil
curl -I https://api.example.test/documentation

Les deux premières requêtes renvoient une redirection permanente vers HTTPS, avec leur chemin conservé. Les deux dernières renvoient une réponse HTTPS du serveur ; le résultat exact dépend du contenu installé et de la configuration locale.

À retenir

• Configurez un hôte sur le port 80 pour rediriger chaque nom vers son URL HTTPS.
• Configurez un hôte sur le port 443 avec TLS et les chemins du certificat et de sa clé.
• Vérifiez que le certificat couvre les noms utilisés et que les noms publics pointent vers le serveur.
• Lancez apachectl configtest et ne rechargez Apache qu’après un résultat Syntax OK.
• Contrôlez les deux redirections et les réponses HTTPS avec curl.

Dans la prochaine leçon, vous utiliserez les journaux pour diagnostiquer les erreurs 403 et 500.