Synology – Forcer les connexions HTTPS

Suivant le navigateur employé, il faut souvent indiquer : https:// avant l’URL du domaine ou sous-domaine. Nous pouvons éviter cela ! Il existe certainement plusieurs solutions, mais pour ma part, j’utilise un petit script à la racine du serveur Web sur mon NAS Synology. Explications…

synology forcer https

Synology et HTTPS

Ce tutoriel fait suite à notre précédent : Domaine, sous-domaine, Reverse-Proxy et HTTPS avec un NAS Synology. Si vous hébergez (mis en place) un site Web sur votre NAS Synology, vous avez très certainement installé Web Station (disponible depuis le Centre de Paquets). Ouvrez ce dernier et allez dans le menu Paramètres généraux (à gauche). En face de Serveur principal HTTP, sélectionnez Apache http Serveur 2.4. Sur la ligne du dessous PHP, sélectionnez Defautlt Profile ( PHP 7.0 ) (ndlr : cela fonctionne aussi avec les autres versions).

Cliquez maintenant sur le bouton Appliquer. Ensuite sur votre ordinateur, ouvrez un éditeur de texte et copier/coller les lignes suivantes :

RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Enregistrer ce script avec un nom comme par exemple conf.txt. Puis, retournez dans DSM sur votre NAS Synology. Ouvrez File Station et déposez votre fichier conf.txt à la racine du répertoire Web sur votre NAS. Maintenant, renommez le fichier en .htaccess. Oui, le fichier se nomme bien ainsi : rien avant le point et htaccess après. C’est très important. Le renommage du fichier ne peut s’effectuer que par File Station. Enfin, relancer le serveur Web. À noter, si votre serveur Web est déjà actif, cela ne change rien à son fonctionnement.

Comme vous pouvez le voir dans la capture d’écran, nous retrouvons bien le fichier .htaccess  parmi les deux pages qui me servent de test dans mon dossier Web. Vous pouvez maintenant vous connecter en oubliant le https:// dans votre navigateur. Les ports 80/443  doivent être redirigé vers le NAS et tout passera en sécurisé.

  1. A noter aussi que le fait d’activer HSTS dans les paramètres d’un Virtual Host forcera le navigateur à utiliser https (c’est l’utilité même du HSTS = indiquer au navigateur que le site en question ne sait dialoguer qu’en HTTPS).

    1. oui, mais en cas de problème de renouvellement de certificat, en activant hsts, on peut se retrouver bloqué dehors, raison pour laquelle je ne l’active pas

  2. C’est vraiment bizarre quand on fait une recherche sur les manières de configurer les .htaccess on ne retrouve pas toujours les mêmes manières de faire 🙂

    Pour ma part j’ai ça, en ajoutant également la redirection www :

    # Redirection vers HTTPS
    RewriteCond %{SERVER_PORT} ^80$ [OR]
    RewriteCond %{HTTPS} =off
    RewriteRule ^(.*)$ https://mondomaine.com/$1... [R=301,L]
    Header always set Strict-Transport-Security « max-age=31536000; includeSubDomains; preload »

    # Redirection du www vers non-www en HTTPS
    RewriteCond %{HTTP_HOST} ^www\.mondomaine\.com [NC]
    RewriteRule ^(.*)$ https://mondomaine.com/$1... [R=301,L]

  3. Bonjour,
    Merci Zypos pour tes articles. J’ai eu cette problématique et je vais mettre en place ta solution.
    Comme @obd, j’utilise également hsts dans virtual host pour la definition de mes sous domaines.

    1. Bien souvent, avec Apache, on a tendance par facilité (et par erreur, car cela entraîne une baisse de performance) à tout régler via des fichiers .htaccess, alors qu’une configuration globale du site est bien souvent préférable.

      C’est ce second comportement qu’on privilégie avec Nginx. Il y a donc entre les deux systèmes une différence notable dans la façon même d’envisager la configuration. Pas dans les capacités, car Apache aussi permet la configuration spécifique d’un site, mais dans les habitudes d’utilisation, l’absence de fichier htaccess chez Nginx nous obligeant à adopter un comportement plus adapté et propre.

      C’est donc pour nous amener à adopter ce comportement plus propre, et aussi pour des questions de performances, un des axes majeurs de Nginx, que ce dernier n’implémente pas d’équivalents aux fichiers .htaccess.

      Une décision certes discutable, mais pas sans intérêt.

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.