Redirect HTTP to HTTPS with NGINX - nginx

I have a couple of applications that I maintain at my work and noticed that some employees are able to use the non-secure paths to those applications such as: example.com, www.example.com. Using either of those paths will direct them to the HTTP path instead of HTTPS, unless they specify HTTPS in the url. We currently use nginx as our gateway, but I did not do the initial configuration of our nginx gateway, so I don't really know what works and what doesn't.
Here is a snippet of our nginx.conf file
server{
listen 80 default_server;
listen [::]:80 default_server;
server_name localhost;
location / {
proxy_pass http://localhost:3000;
}
}
# Settings for a TLS enabled server.
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
server_name localhost;
ssl_certificate "/etc/nginx/ssl/domain-crt.txt";
ssl_certificate_key "/etc/nginx/ssl/domain-key.txt";
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
## More configuration below this...
}
I tried doing a return in the listen 80 section but this did not work:
server{
listen 80 default_server;
listen [::]:80 default_server;
server_name localhost;
return 301 https://$host$request_uri;
location / {
proxy_pass http://localhost:3000;
}
}
I reloaded nginx with the corrections and I was still able to connect to the http paths without it redirecting to https. I don't know if this has something to do with the server_name being localhost because I've only seen examples online where they are redirecting to the actual domain name, but this is how our applications are setup and I don't know if changing that will have effects on the connectivity of our applications. If anyone has any ideas or suggestions on how I could get a redirect to work properly, that would be great. Thanks!

You're missing the semicolon at the end, also you should get rid of the proxy_pass since that overrides the behavior.
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name localhost;
location / {
return 301 https://$host$request_uri;
}
}

Related

Nginx redirects subdomain foo to www.foo to www.www.foo etc

I just changed my config from a regular to a wildcard certificate. Now my nginx is misbehaving.
# redirect http to https
server {
listen 80 default_server;
listen [::]:80 default_server;
return 301 https://$host$request_uri;
}
# redirect naked to www
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name example.com;
include ssl.conf;
return 301 https://www.$host$request_uri;
}
# serve subdomain www
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name www.example.com;
include ssl.conf;
# ...
}
# serve subdomain mmm
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name mmm.example.com;
include ssl.conf;
# ...
}
# ...etc.
The above works, but fails for non-existent subdomains (instead of returning 404). So if I try notexist.example.com it will redirect me to www.notexist.example.com and give me a certificate warning. If I click ok, it will redirect to www.www.notexist.example.com, and then www.www.www.notexist.example.com, etc.
What am I doing wrong?
Since you want to catch all non-existent subdomains you need an extra server block at the end, marked as default - like listen 443 ssl default_server; The server_name for this block does not matter - as long as it does not match any of the other server blocks (so you can simply use server_name _;)
Any domain that is not already handled by another server block will be handled by the default one - you can either redirect to your canonical domain or just return 404.

Redirect http to https on Nginx not working

I have a server running on DigitalOcean and have a domain name I've purchased.
My server has nginx running on it and I'm trying to get my http requests to redirect to https but nothing I've tried is working.
I know it should be really simple and I've looked at dozens of example but for some reason mine still isn't working.
Right now this is what I have
server {
listen 80;
server_name www.example.com example.com;
listen [::]:80;
return 301 https://$host$request_uri;
}
server {
# SSL configuration
#
listen 443 ssl;
# listen [::]:443 ssl;
root /var/www/example.com;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html index.php;
server_name example.com www.example.com;
ssl_certificate_key /etc/nginx/keys/example.key;
ssl_certificate /etc/nginx/keys/example.com.chained.crt;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
}
Is there anything wrong with this or anything I should change?
My website works fine and has the lock icon in the browser indicating it is secure if I type in https://example.com or https://www.example.com
But if I just use example.com http://example.com or www.example.com it says the page can't be found.

How to fix http redirects with Nginx?

I have a webpage where http redirects are a bit broken.
The current behavior is this:
www.example.com, example.com, http://www.example.com, http://example.com, https://www.example.com all gets redirected to https://www.example.com
and
https://example.com gets an error saying refused to connect.
I want the behavior to be like this:
example.com, http://example.com, https://example.com redirects to https://example.com
www.example.com, http://www.example.com, https://www.example.com redirects to https://www.example.com
Here is my Nginx config file
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name example.com www.example.com;
return 301 https://$server_name$request_uri;
}
server {
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
include snippets/ssl-example.com.conf;
include snippets/ssl-params.conf;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name _;
location ~ /.well-known {
allow all;
}
location / {
try_files $uri $uri/ =404;
}
}
Reason is because I want these links to work
https://www.ssllabs.com/ssltest/analyze.html?d=example.com
https://www.ssllabs.com/ssltest/analyze.html?d=www.example.com
https://hstspreload.org/?domain=example.com
https://hstspreload.org/?domain=www.example.com
You have two independent issues:
Your requests all redirect to example.com, regardless of which specific domain is originally accessed.
This happens because the $server_name variable that you are using is effectively a static variable in a given server context, and has a very distant relationship to $http_host.
The correct way would be to use $host instead (which is basically $http_host with some edge-corner cleanups).
You're receiving connection issues when trying to contact https://example.com, but not https://www.example.com.
There is not enough information in your question to pinpoint the exact origin of this problem.
It can be a DNS issue (A/AAAA records of example.com set at an IP address where appropriate bindings to the https port aren't made).
It could be an issue with the mismatched certificate:
Does your certificate cover both example.com and www.example.com? If not, then you can't have both.
If you have separate certificates, you may also need to acquire separate IP addresses, or risk preventing a significant number of users from accessing your site due to lack of SNI.
As of note, it should also be pointed out that it is generally a sloppy practice to not have a unified notation on the way your site is accessed. Especially if SEO is of any concern to you, the best practice is to decide on whether you want to go with or without www, and stick to it.
You need something like this:
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
server_name www.example.com;
include snippets/ssl-example.com.conf;
include snippets/ssl-params.conf;
add_header Strict-Transport-Security "max-age=300; includeSubdomains; preload";
return 301 https://www.example.com$request_uri;
}
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
server_name example.com;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
include snippets/ssl-example.com.conf;
include snippets/ssl-params.conf;
add_header Strict-Transport-Security "max-age=300; includeSubdomains; preload";
location ~ /.well-known {
allow all;
}
location / {
try_files $uri $uri/ =404;
}
}
All your requests will be ultimately routed to https://example.com.
Your ssl certificate should also be valid for https://www.example.com which I note you have said it is.

Nginx redirecting to the wrong site; poorly formed server_name directive

The Problem
When you type example.com into the address bar of a browser WITHOUT entering the scheme, i.e. http:// or https://, Nginx redirects the user to https://api.example.com instead of https://example.com as intended. I'm pretty sure there's something wrong with my Nginx config, but I'm not sure what.
Details
I'm hosting two websites on the same server, with the same IP. The relevant bits from the DNS zone file looks something like (domain and IP anonymized here):
example.com. 1800 IN A xxx.xxx.xxx.xxx
www.example.com. 1800 IN CNAME example.com.
api.example.com. 1800 IN CNAME example.com.
I have two SSL certs installed (provided by letsencrypt), one for each site, and both sites are configured to redirect to HTTPS. I have two vhost config files, one for each site, as follows:
/etc/nginx/sites-available/api
/etc/nginx/sites-available/default
Both are symlinked into /etc/nginx/sites-enabled/. The relevant bits from the two config files are as follows:
# /etc/nginx/sites-available/api
server {
listen 80;
listen [::]:80 ipv6only=on;
server_name api.example.com;
return 301 https://api.example.com$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
include snippets/api-ssl-params.conf; # ssl config info
server_name api.example.com;
# ... the rest of the site config ...
}
and:
# /etc/nginx/sites-available/default
server {
listen 80;
listen [::]:80;
server_name www.example.com;
return 301 https://example.com$request_uri;
}
server {
listen 443 ssl http2 default_server;
listen [::]:443 default_server ipv6only=on;
include snippets/ssl-params.conf; # ssl config info
server_name example.com;
# ... the rest of the site config ...
}
I don't understand why just entering example.com into the address bar would redirect to https://api.example.com because:
just plain example.com doesn't appear in the api config file anywhere
example.com shouldn't match the server_name directive api.example.com
the server blocks in default are marked as default_server so shouldn't that take precedence when an ambiguous domain name was typed in?
Thanks!!!
Duh. Figured it out in the process of writing the question. The problem is that just plain example.com doesn't appear in the server_name directive for either of the sites listening on port 80. Since that causes ambiguity, nginx picks the first site in alphabetic order.
I updated the config file for the default site as follows:
# /etc/nginx/sites-available/default
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com; # <-- CHANGED THIS LINE
return 301 https://example.com$request_uri;
}
server {
listen 443 ssl http2 default_server;
listen [::]:443 default_server ipv6only=on;
include snippets/ssl-params.conf; # ssl config info
server_name example.com;
# ... the rest of the site config ...
}
And all was right with the universe.

NginX http redirection to https returns unreadable respone

I want to redirect all http requests to https with NginX, but I have some difficulties with it.
Here is my vhost file :
server {
gzip off;
listen 80;
listen [::]:80;
server_name mydomain.fr www.mydomain.fr sub.otherdom.fr otherdom.fr;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
root /usr/share/nginx/html;
index index.html index.htm;
ssl on;
server_name mydomain.fr www.mydomain.fr sub.otherdom.fr otherdom.fr;
ssl_certificate /root/tmp/live-ecdsa/mydomain.fr/0001_chain.pem;
ssl_certificate_key /root/tmp/live-ecdsa/mydomain.fr/privkey-p384.pem;
access_log /var/log/nginx/default.access.log;
charset utf-8;
location / {
try_files $uri $uri/ /index.html;
}
}
Trying to access these domain over plain http with different browsers results in the following :
Chrome/Firefox : downloading a file filled with bytes data
Edge : displays a blank page with €ÿÿÿÿ
A curl -I mydomain.fr outputs ▒▒
Accessing these domains directly over https works.
I have already tried with both return 301 https://$host$request_uri; and return 301 https://$server_name$request_uri;
I suspect it has something to do with the fairly large number of server names you are declaring in the one server name field inside a pretty locally scoped context. Although, if I'm honest thats a fairly unfounded assertion based on habits I've become user to.
I'd suggest a few things, although generally most of this wont fix your problem, it might make it easier to work out whats happening:
split your config into purposed files. Ie. Create a ssl.conf in another folder which contains all youe cert settings, cipher suites etc. Then add an include /path/to/ssl.conf in your config.
dont use $host, this variable can be set by the use so probably a less than great idea
Assuming you have all the other relevant ssl/tls settings referenced from somewhere else then the below should roughly work.
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name mydomain.fr;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
root /usr/share/nginx/html;
$server_name mydomain.fr
location / {
try_files $uri $uri/ /index.html;
}
}
Well, although user6788523 response helped me with the debugging, the fault was on my side.
I had several other vhost files with the http2 directive associated with the http port 80 (listen [::]:80 http2;). Removing the http2 directive resolved the problem.
This setting must be used only with ssl enabled server block

Resources