Basic, Yet Many New Users Fight With Nginx WWW to No WWW & HTTP to HTTPS Rules on Cloud Server Instance Running Debian/Ubuntu GNU/Linux. They have rightly configured the infrastructure to run common web applications like WordPress on HP Cloud. Basically it is not exactly difficult for an old user but can give a pain to a new user who was using Apache2 for many years. We have full Nginx-PHP5 FPM configuration as well in this guide. These are cloud server specific and agonistic for future rapid change in server.
Nginx WWW to No WWW & HTTP to HTTPS
For practical example, think about the domain thecustomizewindows.com. If we had no HSTS, then the first condition for pointing the non-SSL domain http://thecustomizewindows.com from http://www.thecustomizewindows.com is :
Single Server, Non-SSL :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
server { server_name www.thecustomizewindows.com; rewrite ^(.*) http://thecustomizewindows.com$1 permanent; } server { listen 80 default; server_name thecustomizewindows.com; index index.php index.html; root /usr/share/nginx/html; location = /favicon.ico { log_not_found off; access_log off; # ... # rest config # ... } } |
rewrite is faster than return :
|
1 |
return 301 $scheme://thecustomizewindows.com$request_uri; |
The server block for 443 remaining commented out. Do not read rest of the guide, it is for more complicated situation. Know quite well, if you add the IP against the A Name for both non-WWW and WWW from DNS settings in HP Cloud, Rackspace, IBM etc. with higher TTL, the root server automatically redirects before reaching the request towards the server.
Single Server, SSL :
In this case, first we will redirect the www and then non-www towards the https site :
|
1 2 3 4 5 6 7 8 9 10 11 |
server { server_name www.thecustomizewindows.com; rewrite ^(.*) https://thecustomizewindows.com$1 permanent; } server { listen 80; server_name thecustomizewindows.com; rewrite ^(.*) https://thecustomizewindows.com$1 permanent; index index.php index.html; root /usr/share/nginx/html; } |
In this case, the HTTPS server block of the above will bear default in the listen part :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
server { listen 443 default; server_name thecustomizewindows.com; index index.php index.html; root /usr/share/nginx/html; location = /favicon.ico { log_not_found off; access_log off; # ... # rest config # ... } } |
www for HTTPS location will also need redirection, so the config for 443 port :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
server { listen 443; server_name www.thecustomizewindows.com; rewrite ^(.*) https://thecustomizewindows.com$1 permanent; index index.php index.html; root /usr/share/nginx/html; location = /favicon.ico { log_not_found off; access_log off; # ... # ssl configuration required for HSTS # ... } } server { listen 443 default; server_name thecustomizewindows.com; index index.php index.html; root /usr/share/nginx/html; location = /favicon.ico { log_not_found off; access_log off; # ... # rest config # ssl config # ... } } |
Ultimately we have 4 virtual hosts from permutation and combination :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
server { listen 80; server_name www.thecustomizewindows.com; rewrite ^(.*) https://thecustomizewindows.com$1 permanent; } server { listen 80; server_name thecustomizewindows.com; rewrite ^(.*) https://thecustomizewindows.com$1 permanent; } server { listen 443; server_name www.thecustomizewindows.com; rewrite ^(.*) https://thecustomizewindows.com$1 permanent; index index.php index.html; root /usr/share/nginx/html; location = /favicon.ico { log_not_found off; access_log off; # ... # ssl configuration required for HSTS # ... } } server { listen 443 default; server_name thecustomizewindows.com; index index.php index.html; root /usr/share/nginx/html; location = /favicon.ico { log_not_found off; access_log off; # ... # rest config # ssl configuration # ... } } |
It looks too crude, but it is great for the new users. All virtual hosts will redirect to :
|
1 2 3 4 |
http://www.thecustomizewindows.com -> https://thecustomizewindows.com http://thecustomizewindows.com -> https://thecustomizewindows.com https://www.thecustomizewindows.com -> https://thecustomizewindows.com https://thecustomizewindows.com -> 200 OK (root /usr/share/nginx/html) |
Now a more complicated situation like ours where www subdomain is on different server :
Multiple Server with separate WWW server, SSL :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
server { listen 80; server_name www.thecustomizewindows.com; rewrite ^(.*) http://thecustomizewindows.com$1 permanent; } server { listen 443; server_name www.thecustomizewindows.com; rewrite ^(.*) https://thecustomizewindows.com$1 permanent; index index.php index.html; root /usr/share/nginx/html; location = /favicon.ico { log_not_found off; access_log off; # ... # ssl configuration required for HSTS # ... } } |
---
Yes, our method is bad to look at for single server SSL, but it returns the 301 faster and easy to troubleshoot. You can do curl for each to see the header :
|
1 2 3 4 |
curl -I http://thecustomizewindows.com curl -I http://www.thecustomizewindows.com curl -I https://www.thecustomizewindows.com curl -I http://thecustomizewindows.com |
We are focussed on HSTS. Exactly like said for plain case; if you add the IP against the A Name for both non-WWW and WWW from DNS settings in HP Cloud, Rackspace, IBM etc. with higher TTL, the root server automatically redirects before reaching the request towards the server except that for HSTS. That is determined by preload time in HSTS. If you see our WordPress Nginx Configuration file on GitHub, you will see :
|
1 2 3 4 |
return 301 https://thecustomizewindows.com$request_uri; if ($http_x_forwarded_proto = "http") { rewrite ^/(.*)$ https://thecustomizewindows.com/$1 permanent; } |
it is for Rackspace load balancer. Our website had lot of older posts (near 4.5K written over 4 years) on non-SSL. Before we migrated to HP Cloud, we were on Rackspace. We kept it as fail-safe method. If data center needs movement, we can adjust easily. Now think about our complicated thecustomizewindows.net domain with HSTS configuration. All 4 are 301 :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
server { listen 80; server_name www.thecustomizewindows.net; rewrite ^(.*) https://thecustomizewindows.com$1 permanent; } server { listen 80; server_name thecustomizewindows.net; rewrite ^(.*) https://thecustomizewindows.com$1 permanent; } server { listen 443; server_name www.thecustomizewindows.net; rewrite ^(.*) https://thecustomizewindows.com$1 permanent; index index.php index.html; root /usr/share/nginx/html; location = /favicon.ico { log_not_found off; access_log off; # ... # ssl configuration required for HSTS # ... } } server { listen 443 default; server_name thecustomizewindows.net; rewrite ^(.*) https://thecustomizewindows.com$1 permanent; index index.php index.html; root /usr/share/nginx/html; location = /favicon.ico { log_not_found off; access_log off; # ... # rest config # ssl configuration # ... } } |
Always test with nginx -t command before running service nginx reload command. Never reboot the server instance without testing with nginx -t after change. When you’ll manage your own server, you’ll delicately manage, when others will manage; unfortunately you might not like all the things.
If all the virtual hosts have own server instances and IP (which is common in high traffic website), these type of configuration helps to easily change the rules by another person. We are not resolving www.thecustomizewindows.com and any thecustomizewindows.net on main server to avoid DDoS. Script Kiddies can run exploit on unmonitored locations and protocols. It is better to keep root /usr/share/nginx/another-location :
|
1 2 3 4 5 6 7 |
server { listen 80; server_name www.thecustomizewindows.net; rewrite ^(.*) https://thecustomizewindows.com$1 permanent; index index.php index.html; root /usr/share/nginx/another-location; } |
In case of suspected exploit, you can uncomment the rewrite ^(.*) https://thecustomizewindows.com$1 permanent; and enable log to catch the exploit. You’ll not find these things on StackOverflow. It is not possible to explain so much there. Now if you monitor the files with OSSEC like tools, it becomes very easy to catch the exploit before any thing happens by only one sysadmin. If somehow the hacker gets entry to location /usr/share/nginx/another-location on different server with fake files you can trap it and get the details on their machine. If the server is hacked, redirection is possible from DNS.
You can adapt to easier config, but these are safer for plan to use multiple web servers.
About Abhishek Ghosh
Here’s what we’ve got for you which might like :
Additionally, performing a search on this website can help you. Also, we have YouTube Videos.
Take The Conversation Further ...
We'd love to know your thoughts on this article.
Meet the Author over on Twitter to join the conversation right now!
If you want to Advertise on our Article or want a Sponsored Article, you are invited to Contact us.
Contact Us