I have an nginx configuration with multiple virtual hosts and subdomains. Each subdomain needs to have a different SSL certificate bound. Here is the configuration for my first subdomain:
server {
listen 443;
server_name a.website.com;
ssl on;
ssl_certificate /etc/nginx/ssl/a/a.crt;
ssl_certificate_key /etc/nginx/ssl/a/a.rsa;
.....
The configuration for my second:
server {
listen 443;
listen 3443;
server_name b.website.com;
ssl on;
ssl_certificate /etc/nginx/ssl/b/b.crt;
ssl_certificate_key /etc/nginx/ssl/b/b.key;
....
The problem is if I go to b.website.com, the SSL certificate for both a.website.com and b.website.com are returned when I expect only b.website.com to be bound. I validated this using ssllabs.
Any advice?
I didn't notice that in ssllabs the second certificate was only returned if SNI wasn't enabled which makes sense because both certs are on the same IP. Apparently the integration we're working with doesn't support SNI (crazy I know) so I guess I have to spin up another server.
Related
Sorry for the limited understanding of Nginx and SSL. I have a React and Django app deployed on a server running on Nginx.
The React app is accessible using "example.org"(name is faked for demo purpose) and for the Django app, I have configured it to be accessible with port 3000 ie "example.org:3000".
The domain has SSL certificates installed and certificates are seen in "example.org" but while accessing "example.org:3000", the certificates are not available to this port.
I have been trying to allow ssl certificates to the port as well but couldnt succeed. I changed nginx conf file with listen 3000 ssl without success.
Please help, is there a way or should we need to modify the ssl certificates?
Nginx config at the moment is:
server {
listen 80 default_server;
server_name example.org;
return 301 https://example.org;
}
server {
listen 443 ssl;
server_name example.org;
ssl_certificate /etc/nginx/ssl/ssl_bundle.crt;
ssl_certificate_key /etc/nginx/ssl/example.key;
location / {
root /home/ubuntu/example/build;
index index.html index.htm;
}
}
The Port has nothing to do with the certs OR TLS Termination in general. IN case my assumptions are correct and your Django app is exposing its port 3000 by itself you need a proxy configuration that terminates the TLS for you.
server {
listen 8080 ssl;
server_name example.org;
ssl_certificate /etc/nginx/ssl/ssl_bundle.crt;
ssl_certificate_key /etc/nginx/ssl/example.key;
location / {
proxy_pass http://127.0.0.1:3000/;
proxy_set_header Host $host;
.....
}
}
This will terminate the TLS Session for you on Port 8080 and forwards the traffic to your Django app. There are other, more advanced options, proxying traffic to your appserver but this one will do it.
Note: In case you want to proxy the traffic through NGINX make sure Port 3000 is not exposed to the public anymore.
I noticed something on an nginx config. There are 2 upstream blocks configured that are exactly the same:
upstream test1.example.com {
server flaskapp.example.com:5000
}
server {
listen 443 ssl;
proxy_pass test1.example.com;
ssl_certificate /opt/certs/example1.com.crt;
ssl_certificate_key /opt/example1.com.key;
ssl_protocols TLSv1.2;
ssl ciphers "ECDHE-ECDSA-AES128-GCM-SHA256"
}
upstream test2.example.com {
server flaskapp.example.com:5000
}
server {
listen 443 ssl;
proxy_pass test2.test.com;
ssl_certificate /opt/certs/test.com.crt;
ssl_certificate_key /opt/test.com.key;
ssl_protocols TLSv1.2;
ssl ciphers "ECDHE-ECDSA-AES128-GCM-SHA256"
}
I have 2 server blocks listening on port 443. So I have the same server listening for 2 separate connections on the same block... if that makes sense.
My thought was that this would fail because the same server listening for incoming https connections to test1 and test2.example.com wouldn't know 'where' to route the requests too. But that's not what's happening.
If I go to https://test1.example.com I am routed to the correct app. And https works as expected.
If I go to https://test2.example.com I am routed to the correct app. But https does not work as expected. This is confusing because both certs are wildcard certs. I am unsure why 1 succeeded and one failed.
If I comment out the first upstream block:
# upstream test1.example.com { server flaskapp.example.com:5000 }
# server {proxy_pass test1.example.com; }
Something stranger happens. Connecting to https://test2.test.com gives me a 'failed to connect to server' error message in my web browser. And the logs show this as the error:
No "ssl_certificate" is defined in server listening on SSL port while SSL handshaking
This is for test1.example.com, and I know the wildcard cert works. I'm using it elsewhere. So I'm unsure why I'm getting a 'failed to connect to server' error when I go to test1.example.com in this manner.
A few things to note:
Both test1.example.com and test2.test.com point to the same nginx server.
If both upstream/server blocks are working then test1.example.com shows the site is ssl secure. That is expected. But test2.test.com shows the website is insecure. This leads me to believe that only the first server/upstream block is working as expected. And the 2nd server/upstream block is being ignored.
actually does make sense, in that a server shouldn't be listening for incoming connections to the same port, and route to different servers. The proxy doesn't know what to do with 1 of the connections (bad explanation on my part).
But that doesn't explain why the 2nd server/upstream block would outright fail. Even when test2.example.com is the only server/upstream block configured.
Any advice is appreciate, thank you for your time and consideration. This is something I've been struggling to understand and make heads/tails of.
bossrhino
I think you need to use server_name directive. Because your web server listens on same ip and the same port for two subdomains.
I guess this config file should work properly:
upstream test1.example.com {
server flaskapp.example.com:5000
}
server {
listen 443 ssl;
server_name test1.example.com;
proxy_pass test1.example.com;
ssl_certificate /opt/certs/example1.com.crt;
ssl_certificate_key /opt/example1.com.key;
ssl_protocols TLSv1.2;
ssl ciphers "ECDHE-ECDSA-AES128-GCM-SHA256"
}
upstream test2.example.com {
server flaskapp.example.com:5000
}
server {
listen 443 ssl;
server_name test2.example.com;
proxy_pass test2.test.com;
ssl_certificate /opt/certs/test.com.crt;
ssl_certificate_key /opt/test.com.key;
ssl_protocols TLSv1.2;
ssl ciphers "ECDHE-ECDSA-AES128-GCM-SHA256"
}
What I want:
I want to redirect www.mydomain.eu and mydomain.eu to, let's say, www.google.com, while having access to a local gitea server through git.mydomain.eu.
What I have:
I have this nginx config in /etc/nginx/sites-available:
ssl_certificate /XXX/fullchain.pem;
ssl_certificate_key /XXX/privkey.pem;
server {
listen 443 ssl default_server;
listen 80 default_server;
server_name www.mydomain.eu mydomain.eu;
access_log /var/log/nginx/reverse-access.log;
error_log /var/log/nginx/reverse-error.log;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
location / {
return 301 http://google.com;
}
}
server {
listen 443 ssl;
server_name git.mydomain.eu;
access_log /var/log/nginx/reverse-access.log;
error_log /var/log/nginx/reverse-error.log;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
location / {
proxy_pass http://localhost:3000;
}
}
with XXX being an absolute location and mydomain being the actual name of my domain (this config file is also in sites-enabled thanks to a "ln -s" command)
What my problem is
When I go to https://mydomain.eu, I am redirected to https://www.google.com/. => great !
When I go to https://www.mydomain.eu, Firefox (and chrome) says that "This site can’t be reached" => :(, different behavior than mydomain.eu, why ?
Same with https://git.mydomain.eu ("This site can’t be reached") => why ? I am sure that http://localhost:3000 is a valid website, as I can access it through its IP address.
It seems that nginx ignores the "www" in my first rule, and I can't figure out why.
This is not related to nginx but your domain host configuration as the net traffic not even reach to your nginx server yet.
In order to be able to access git.example.com, you will need to have a CNAME configured at your host with CNAME host as git, and value as example.com. You also need another one for www, as shown below:
Type Host Value
CNAME git example.com
CNAME www example.com
One more thing to be aware is if you are using a sub-domain like git.example.com, depend on how you configure your ssl certificate and what kind of ssl certificate you purchased, the git.example.com may need a separate ssl certificate, unless you have a multi-site ssl certificate....
I have Mattermost installed in my server, currently I can login to it by browsing through http://192.168.x.x:8066, I've installed a self-signed cerrtificate for this IP, but when I tried to browse it with https://192.168.x.x:8065, it failed to redirect to the Mattermost page.
Below is the configuration of my nginx.conf:
server {
listen 443 http2 ssl;
listen [::]:443 http2 ssl;
listen 443;
server_name 192.168.3.201:8066;
ssl on;
ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
}
However, when I just browse the URL without port 8066 , it displays the default nginx page with no errors.
What's wrong with my nginx.conf file? I'm still new to nginx FYI.
Any suggestions will be very much appreciated.
I suggest you follow the example nginx configuration from the documentation here. Start with that config file, updating server_name to be the domain name you want mattermost to be reachable from, and server to be the IP address and port on which mattermost is listening.
Once you've got that working, you can continue through the instructions to #9 which covers setting up SSL.
I am having issues with CORS, specifically with max cdn. CORS was working properly with maxcdn until a few days ago. I have posted my host config and the cors header is included.
I am stumped at this point, as I have done the following to troubleshoot:
Disabled a rocket-cache specific configuration for nginx included in
the server block.
I have changed caching methods - rather than redis-hhvm I have tried
switching over to fcgi-hhvm with rocket cache.
I have disabled rocket cache after clearing it's cache - then purging
the entire cache, and used a third party plugin for wordpress
specifically for linking the cdn.
I am using SNI with SPDY on maxcdn - I have a cert just for the subdomain (cdn.jurisdesk.com). And I am using Digitalocean for hosting.
Below is my current nginx config (everything was working properly until a few days ago which prompted me to speak with maxcdn support - who are great by the way, and extremely knowledgeable when it comes to advanced configurations specifically using nginx).
server {
server_name www.jurisdesk.com;
ssl_certificate_key /path/to/key/foobar.key;
ssl_certificate /path/to/cert/foobar.crt;
listen *:80;
listen *:443 ssl spdy;
listen [::]:80 ipv6only=on;
listen [::]:443 ssl spdy ipv6only=on;
return 301 https://jurisdesk.com$request_uri;
}
server {
server_name jurisdesk.com;
listen *:80;
listen [::]:80;
return 301 https://jurisdesk.com$request_uri;
}
server {
server_name jurisdesk.com;
listen *:443 ssl spdy;
listen [::]:443 ssl spdy;
ssl on;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
ssl_certificate_key /path/to/key/foobar.key;
ssl_certificate /path/to/cert/foobar.crt;
access_log /var/log/nginx/jurisdesk.com.access.log rt_cache_redis;
error_log /var/log/nginx/jurisdesk.com.error.log;
root /var/www/jurisdesk.com/htdocs;
index index.php index.html index.htm;
include common/redis-hhvm.conf;
include rocket-nginx/rocket-nginx.conf;
include common/wpcommon.conf;
include common/locations.conf;
location ~ \.(ttf|ttc|otf|eot|woff|woff2|font.css|css|js)$ {
add_header Access-Control-Allow-Origin "*";
}
}
I have also added CORS to rocket-nginx.conf - as this is something I've been tinkering with lately and reflects a change to my config - however I have also removed the directive to eliminate that as the cause of the problem.