http to https redirect

http to https redirect

Currently reading
http to https redirect

7,554
2,270
www.blackvoid.club
NAS
DS718+, DS918+, 2x RS3614RPxs+
Router
  1. RT1900ac
  2. RT2600ac
  3. MR2200ac
Operating system
  1. macOS
Mobile operating system
  1. iOS
Rusty submitted a new resource:

http to https redirect - A short tutorial on http to https redirect

This will be a quick tutorial on http to https redirect for all of you using Synology reverse proxy (usually in a combination with Docker containers) or in general any means to host any content on your NAS.
Why is http to https needed? Well for one it will force any attempts to access your content on a non secure protocol as well as allow any visitors of your sites to simply be redirected to the correct URL no matter how they type it in the address bar.
Let’s give a quick example before the...

Read more about this resource...
 
Nice write up / tutorial, clearly explained.
Step 08 “Set Destination protocol to HTTP” but the screenshot shows https could this be a typo?

And I was wondering why the redirect to a Docker container if you already have installed the webstation package? When using the webstation package all these steps aren’t necessary...Except step 4. I think 🤔
 
this be a typo
It is, need to insert a new screen.

When using the webstation package all these steps aren’t necessary
If your web site is a docker container running via reverse proxy on https, it will not respond to http and redirect automatically.
 
Interresting.

Currently this is how I do http to HTTPS redirect, amongst some other things as wel. This PHP script runs with WebStation, but I just kept the nginx backend and never bothered to install Apache. This works fine:

Code:
<?php
$domain = $_SERVER['HTTP_HOST'];
$ip = $_SERVER['REMOTE_ADDR'];

if (strpos($domain,'dsm2.mydomain.net') !== false) {
    // redirect to the DSM interface (SSL) of NAS2.mydomain.net
    header('location: https://dsm2.mydomain.net');
    exit();
}
elseif (strpos($domain,'nas2.mydomain.net') !== false) {
    // redirect to the DSM interface (SSL) of NAS2.mydomain.net
    header('location: https://nas2.mydomain.net:5001');
    exit();
}
elseif (strpos($domain,'synovpn.mydomain.net') !== false) {
    // redirect to the SRM interface (SSL) of router1.mydomain.net
    header('location: https://synovpn.mydomain.net');
    exit();
}
elseif (strpos($domain,'nas1.mydomain.net') !== false) {
    // redirect to the DSM interface (SSL) of NAS2.mydomain.net
    header('location: https://nas1.mydomain.net:5001');
    exit();
}
elseif (strpos($domain,'nas.mydomain.net') !== false) {
    // redirect to the DSM interface (SSL) of NAS2.mydomain.net
    header('location: https://nas1.mydomain.net:5001');
    exit();
}
elseif (strpos($domain,'srm1.mydomain.net') !== false) {
    // redirect to the SRM interface (SSL) of router1.mydomain.net
    header('location: https://srm1.mydomain.net');
    exit();
}
elseif (strpos($domain,'srm2.mydomain.net') !== false) {
    // redirect to the SRM interface (SSL) of router1.mydomain.net
    header('location: https://srm2.mydomain.net');
    exit();
}
elseif (strpos($domain,'photo.mydomain.net') !== false) {
    // redirect to the SRM interface (SSL) of router1.mydomain.net
    header('location: https://nas2.mydomain.net/photo');
    exit();
}
elseif (strpos($domain,'webmail.mydomain.net') !== false) {
    // redirect to the SRM interface (SSL) of router1.mydomain.net
    header('location: https://mail.mydomain.net');
    exit();
}
elseif (strpos($domain,'files.mydomain.net') !== false) {
    // redirect to the SRM interface (SSL) of router1.mydomain.net
    header('location: https://file1.mydomain.net');
    exit();
}
elseif (strpos($domain,'drive.mydomain.net') !== false) {
    // redirect to the SRM interface (SSL) of router1.mydomain.net
    header('location: https://drive1.mydomain.net');
    exit();
}
else {
    // redirect to the DSM interface (SSL) of NAS1.mydomain.net
    header('location: https://dsm1.mydomain.net');
}

?>

Yes I know, I should re-write this in a SWITCH statement. I have a new script already ready for testing. :)
 
It is, need to insert a new screen.


If your web site is a docker container running via reverse proxy on https, it will not respond to http and redirect automatically.

I actually meant why use a docker container for websites if you can use the Synology Webstation for that too. What are the advantages over Webstation?
 
Reason is that I prefer using Docker as a platform for any 3rd party non Syno app. Reason is that I can then move them as a whole to any other docker host, backup and maintain them more easily and over all I have no fear of any platform not running in case that Synology decides to make some small or major changes to any part of the DSM or it’s apps (like WebStation for example). Not saying it will happen but with docker it’s a piece of mind, that’s all.
 
Reason is that I prefer using Docker as a platform for any 3rd party non Syno app. Reason is that I can then move them as a whole to any other docker host, backup and maintain them more easily and over all I have no fear of any platform not running in case that Synology decides to make some small or major changes to any part of the DSM or it’s apps (like WebStation for example). Not saying it will happen but with docker it’s a piece of mind, that’s all.

What I also think of a big advantage is that you have the option of give it entirely it's own LAN IP address.
 
Any dumbed down guide on that?

@Telos gave me a youtube video of how to setup AdGuard Home via Docker. In this instruction, this guy did a neat trick of giving that container it's own IP address. I would assume that this method is apply-able for other docker images as well, although I haven't had the opportunity to test it yet. See here, and in the video look from 3:50 minutes.
 
@Telos gave me a youtube video of how to setup AdGuard Home via Docker. In this instruction, this guy did a neat trick of giving that container it's own IP address. I would assume that this method is apply-able for other docker images as well, although I haven't had the opportunity to test it yet. See here, and in the video look from 3:50 minutes.

Since I have installed my AdGuardHome and gave it its own IP on my LAN, I tend to do that on most of the containers I host.
This is how I created my macvlan and how I have each container join the created network with its own defined IP :

macvlan creation with a reserved IP for your syno :
Code:
docker network create -d macvlan --subnet=192.168.1.0/24 --ip-range=192.168.1.240/28 --gateway=<your_gateway_IP> --aux-address="<a_name_for_your_syno>=<your_syno_ip>" -o parent=eth0 <your_selected_vlan_name>
in this exemple, I have set a macvlan with IPs from 192.168.1.241 to 192.168.1.254

have a container join the vlan on the specific IP :
Code:
docker network connect --ip <disered_IP_in_the_range> <macvlan_name> <container_name>

Maybe this can be helpful for some of you.
 
Since I have installed my AdGuardHome and gave it its own IP on my LAN, I tend to do that on most of the containers I host.
Only issue I have right now with this kind of config is that the host is not able to ping the container IP for a reason I did not identify yet... but since most of the services do not need to be accessed by the NAS itself, it's not a big deal.
The only impact of this as far as I could see is that I can't set its own IP to my BWRS container and use the NAS reverse proxy (nginx) to point to the container's IP on my LAN.
 
Just one question. In point 4 "create on local pc a .httaccess file". But this file stays then on the local pc? And if so what if you have more then 1 pc?

Rusty said:
Once you have created this file and added the content, save it and copy/move it to the redirectedHTTPS folder that you created early.
 
One other way to achieve this is setting the redirection in a nginx configuration file.
I have done that for one app I host but I think this can be done for all apps/sites you host.

the redirect.conf for one specific site/app would look something like below and placed in /etc/nginx/sites-enabled :

Code:
server {
    listen 80;
    listen [::]:80;
    server_name <your ap/site fqdn>;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name <your ap/site fqdn>;

    ssl_certificate <path_to_fullchain.pem>;
    ssl_certificate_key <path_to_privkey.pem>;

    location / {
        proxy_connect_timeout 60;
        proxy_read_timeout 60;
        proxy_send_timeout 60;
        proxy_intercept_errors off;
        proxy_http_version 1.1;
        proxy_set_header        Host            $http_host;
        proxy_set_header        X-Real-IP            $remote_addr;
        proxy_set_header        X-Forwarded-For            $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forwarded-Proto            $scheme;
        proxy_pass https://127.0.0.1:<app/site port>;
    }

    error_page 403 404 500 502 503 504 @error_page;

    location @error_page {
        root /usr/syno/share/nginx;
        rewrite (.*) /error.html break;
        allow all;
    }
}

After putting the file in the right place you need to reload nginx :
- ssh to your nas
- sudo su -
- nginx -s reload

Then test the redirection.
if it doesn't work as intended you can juste delete the file or try to modify it and reload nginx
 
Where to find the "ssl_certificate" and "ssl_certificate_key"?

for my case, since it's the only cert I have on my syno it resides in "/usr/syno/etc/certificate/system/default/fullchain.pem" and "/usr/syno/etc/certificate/system/default/privkey.pem"

And "server_name <your ap/site fqdn>" is then for example "wordpress/blog.domain.com"?

In that case it should look something like :
server_name blog.domain.com;
 
One side note for my example,
The errors are redirected to the synology standard errors so if your site or app has its own error pages then you can remove that part :
Code:
    error_page 403 404 500 502 503 504 @error_page;

    location @error_page {
        root /usr/syno/share/nginx;
        rewrite (.*) /error.html break;
        allow all;
    }
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

WST16 submitted a new resource: Hardening Your HTTP Security Headers - Security headers Read more about...
Replies
0
Views
1,859

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top