Redirect web station nginx http to https (vDSM7)?

[WST16]

Hi,

I gave up on making Apache run on my vDSM 7 (I’m more familiar with Apache’s htaccess), but whatever.
Anyone knows how to redirect 80 to 443 for web station websites?

Searching the internets, I found a few things that didn’t work.

 

[Hoorna]

See this post. The described approach works perfectly on my DiskStation with DSM 6.2.4.

 

[WST16]

Thank you for taking the time to reply. I believe that’s for Apache. I couldn’t convince vDSM 7’s Web Station to activate Apache. I’m trying to redirect Nginx for now.

 

[fredbert]

I think it's the HSTS option if available and then there's the DSM setting in Control Panel to direct HTTP to HTTPS.

 

[Hoorna]

@fredbert, It's not the HSTS option; that option only forces the browser to save the https setting for concerned URL on the moment the browser is connecting to that URL for the first time.

@WST16, the reversed proxies settings in DSM runs on Nginx (which is installed in DSM by default).

 

[WST16]

I think it's the HSTS option if available and then there's the DSM setting in Control Panel to direct HTTP to HTTPS.

Yes, none of this unfortunately and the DSM redirect is only for DSM desktop.

reversed proxies settings in DSM runs on Nginx (which is installed in DSM by default).

I’m not sure if RP can be utilized here. I’m using the domain name not a subdomain (e.g. example.com not subdomain.example.com).

I’ve raised a couple of tickets with Synology.

Thanks

 

[Hoorna]

I would say just try it. (I am using reversed proxies for subdomains an virtual hosts for wordpress domains.)

 

[WST16]

I know. I’m using a lot of RPs on a few DiskStations too. But this or replacing the destination with an IP address won’t work.

 

[fredbert]

I would say just try it. (I am using reversed proxies for subdomains an virtual hosts for wordpress domains.)

How are you configuring this so that http://wpsite1.mydomain.tld/ gets automatically redirected to https://wpsite1.mydomain.tld/?

Having configured reverse proxies in Control Panel I have found that if you are creating an HTTPS rule then it offers the HSTS option. Using curl to the proxied server name using HTTP will return a 302 error page saying the page has moved to an HTTPS address. Using a web browser to the HTTP address will load the HTTPS addressed content.

For virtual hosts in Web Server I've always used Apache so had the .htaccess trick to redirect HTTP to HTTPS. But in the setup you can also select HSTS which does the redirect (but I haven't tested what happens when only HTTPS and port number is configured, i.e. not the default selection of 80/443).

If the Reverse Proxy and Web Server response to enabled HSTS checkboxes is to respond with a redirection 302 page to any HTTP requests then that would stop insecure connections to the intended destination.

 

[fredbert]

I know. I’m using a lot of RPs on a few DiskStations too. But this or replacing the destination with an IP address won’t work.

View attachment 4624

That won't work. All it would do is to make the HTTPS web server provide content using HTTP to the requesting client.

 

[WST16]

Exactly. So I don’t know what’s on @Hoorna mind. Maybe I’m missing his point. How to use RP to receive traffic over 80 and return it to the client over 443?

 

[Hoorna]

Please read the link in my first post; here is the link again. On my DiskStation it is working without problems. If you have diffulties following the guide then I am of course willing to help.

 

[fredbert]

I think Rusty's description applies to Apache as the back-end web server, seeing it's about using .htaccess, and not Nginx. Though I'm wondering if you just place the .htaccess file in the root folder of each virtual host... do you need to do the triple config each time?

I'll have to create a Nginx based virtual host to see what it does, but don't have time right now.

 

[Hoorna]

True, in Web Station's Virtual host I defined the URL with Apache 2.4. But it's possible to define Nginx. I do not know if that works also (not tried).

 

[Hoorna]

@fredbert, it is enough to place the redirect code one time in a virtule host definiton. Subsequent it works then for all (sub-)domainnames. But, for each (sub)domaine name you have to make a reverse proxy rule (see the link) to redirect HTTP to HTTPS.

This evening I did a test. In my existing virtual host redirection definition I changed Apache 2.4 to Nginx. No problem whatsoever: everything keeps working as before.

 

[one-eyed-king]

know. I’m using a lot of RPs on a few DiskStations too. But this or replacing the destination with an IP address won’t work.

Please don't do that. As you depend on your application replacing the responses with an https protocol.
This leaves it to the target application to solve the issue accidently for you.

Personaly, I would add a manualy created conf file and put in the /etc/nginx/conf.d/ folder, make it listen to port 80 and redirect it to port 443. I wrote a tutorial a while ago that indicates where to place files with what sort of content.

/etc/nginx/conf.d/http.*.conf:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 301 https://$host$request_uri;
}

Note: default_server acts like a "catch all" entry and is not supposed to be replaced with a specific full quallified domain name, unless you want to create a file for each and every fqdn.

Make sure to stick to the naming convention and replace the * in the filename with something meaningfull like http_to_https_redirect (or whatever you like)

Then test the new config with sudo nginx -t and apply it with sudo nginx -s reload. Done.

 

[WST16]

Please don't do that.

Never did. It was an example.

Personaly, I would add a manualy created conf file and put in the /etc/nginx/conf.d/ folder, make it listen to port 80 and redirect it to port 443.

That’s what I’ve tried with server blocks but not in this particular location. It’s not as easy as Apache’s htacces. I’ll check this. I prefer to run Apache if it works though. Thanks.

-- post merged: 14. Oct 2021 --

Please read the link in my first post

It’s for Apache not nginx.

 

[WST16]

It seems that this whole thing is much ado about nothing.

Turned out that if you choose Apache it runs fine. However, when testing (e.g. with curl -i or using a testing site) it'll always show Nginx since it acts as a proxy. So all is good with this bit of information.

(don’t shoot me, they didn’t “streamline” this one too )

 

[Hoorna]

That's why I wrote: Just try it.

 

[WST16]

That's why I wrote: Just try it.

I understand your sentiment. But it'll drive me crazy when it works and curl -i shows Nginx (as it is now). I won't rest, I need to know why. Now that I know I'm at peace with the world

Thank you for reading my ramblings and trying to help