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.
Related
I have two sites-enabled for nginx.
I have the default server:
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
try_files $uri $uri/ =404;
}
}
and I have a FQDN with a redirect for https:
server {
listen SERVER-IP:80 ;
listen [::]:80;
server_name FQDN;
location / {
return 301 https://$host$request_uri;
}
}
My issue is that if I try to access my server using a different domain name or using the IP address, using http on port 80, I will always be redirected to https on port 443. I cannot seem to get the default server to respond at all.
I even created another server block that begins:
server {
listen 80;
listen [::]:80;
server_name OTHER-FQDN;
And even when I try to load http://OTHER-FQDN I get redirected to https port 443 with a certificate of FQDN.
Why?
Or better: how can I gain insight into which server block is being used for which request? Clearly only the block with FQDN is ever accessed even though I have another OTHER-FQDN that matches or a default_server that should match.
I am frustrated because the inner working of nginx in this case seem so opaque to me and counter to exectation.
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;
}
}
Is it possible to make a generic HTTP -> HTTPS and WWW -> non-WWW redirect in Nginx which impact all domains. Or do I need to set it up for every single domain?
I've made the HTTP->HTTPS as follows:
server {
listen 80 default_server;
server_name _;
return 301 https://$host$request_uri;
}
You should use two server blocks for this:
server { # redirect http/https www.example.com to https://example.com
listen 80;
listen 443 ssl;
server_name www.example.com;
ssl_certificate <path_to_ssl_cert_for_domain_www.example.com>;
ssl_certificate_key <path_to_key_for_ssl_cert_above>;
# other ssl parameters here if needed
return 301 https://example.com$request_uri;
}
server { # redirect http://example.com to https://example.com
listen 80;
server_name example.com;
return 301 https://example.com$request_uri;
}
server { # main site config
listen 443 ssl;
server_name example.com;
# rest of your configuration here
...
}
Usually paid SSL certificates already includes both domain name with www prefix and without it. If you're using Lets Encrypt service, you can generate certificate for both example.com and www.example.com by yourself.
I have a nginx 1.14.0 on Ubuntu 18.04.3. I have some trouble with a punycode domain, it works only with subdomains, e.g. www.xn--bratwrste-u9a.de but not with the domain only e.g xn--bratwrste-u9a.de
Other domains e.g. example.com are working as expected.
My default server config:
server {
listen 1.2.3.4:443 ssl http2 default_server;
listen 5.6.7.8:443 ssl http2 default_server;
ssl_certificate /ssl/sslcert.pem;
ssl_certificate_key /ssl/privkey.pem;
server_name _;
root /var/www/foo;
index index.html index.php;
}
And here the virtual server config:
server {
listen 5.6.7.8:443 ssl http2;
server_name .xn--bratwrste-u9a.de;
ssl_certificate /ssl/sslcert.pem;
ssl_certificate_key /ssl/privkey.pem;
root /var/www/bar;
index index.html index.php;
}
The log looks good:
"GET /foo.bar HTTP/2.0" 200 247 "https://xn--bratwrste-u9a.de/"
Also there is no error in the error.log
The documentation of nginx gave me no answser to my question and also listing the servername individually makes no different.
Thanks for any suggestion.
EDIT:
A workaround:
Add rewrite rule to the default server:
if ($host = xn--bratwrste-u9a.de) {
rewrite (.*) https://www.xn--bratwrste-u9a.de$1;
}
Strange that this works, but the server_name not...
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