nginx - unable to use (different)certificate for second site - ssl

I originally used certbot for my first site(default)'s cert. All was well and it has worked wonderfully for the past 6months.
Recently I've tried to add another site to my server , and the problem occurs when I try to certify it. (It works fine running on http - using port 80).
I followed the exact same steps as before using certbot to generate the ssl-cert (albeit changing the names), and I had no issues.
However now when I add that cert for site2 to, it redirects to default & shows as not-secure in the url-bar.
If I try go to default, it works fine and is still certified.
I'm certain it is an issue with the certificate for site2, but i'm not sure where the issue lies?
My original website "default" is a php script.
However the second site "site2" is a html script.
Default's code;
server {
listen 80 default_server ;
listen [::]:80 default_server ipv6only=on;
server_name default.com www.default.com;
return 301 https://www.default.com$request_uri;
}
server{
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
include /etc/nginx/snippets/ssl-default.com.conf;
include /etc/nginx/snippets/ssl-params.conf;
location ~ /.well-known {
allow all;
}
root /var/www/default.com/site;
index index.php index.html index.htm index.nginx-debian.html;
server_name _;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.1-fpm.sock;
}
location ~ /\.ht {
deny all;
}
}
site2's code;
server {
listen 80;
listen [::]:80 ;
server_name site2.com www.site2.com;
return 302 https://www.site2.com$request_uri;
}
server{
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name _;
include /etc/nginx/snippets/ssl-site2.com.conf;
include /etc/nginx/snippets/ssl-params.conf;
location ~ /.well-known {
allow all;
}
root /var/www/site2.com/;
index index.html;
location / {
try_files $uri $uri/ =404;
}
location ~ /\.ht {
deny all;
}
}
sudo nginx -t output;
[warn] "ssl_stapling" ignored, issuer certificate not found
nginx: [warn] conflicting server name "_" on 0.0.0.0:443, ignored
nginx: [warn] conflicting server name "_" on [::]:443, ignored
nginx: [warn] conflicting server name "default.com" on 0.0.0.0:80, ignored
nginx: [warn] conflicting server name "www.default.com" on 0.0.0.0:80,
ignored
nginx: [warn] conflicting server name "default.com" on [::]:80, ignored
nginx: [warn] conflicting server name "www.default.com" on [::]:80, ignored
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
params.conf contains;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
# disable HSTS header for now
#add_header Strict-Transport-Security "max-age=63072000; includeSubDomains;
preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
ssl.site2.com.conf has the locations of the privkey and fullchain. (same format & location as default's just change of names..)
*Checking the "not-secure" in the url-bar, states the cert for site2 is issued to default

server_name _ should not be used on ssl hosts unless there is only one virtual host; you should set the explicit name in each server section.

Most likely, you have 2 or more configuration files where you set one value in server_name for the same port. As I can see, one of these files are default. Try to check /etc/nginx/sites-enabled for existing sites.
Try to remove line server_name _; from both ::443 configs and it should work.

Related

Nginx reverse proxy for docker web services

I am trying to use nginx as reverse proxy with ssl to access my locally running web services deployed by docker containers. When specifying locations in nginx, I don't only get the start page of the server but I am not able to follow any links on that page. Besides that, Images of my web service are not displayed.
I have already read the nginx documentation and tried out a lot of different things. For instance, when I am just omitting the location, the web service runs perfectly fine.
Working example of the nginx.conf:
location /{
location / {
proxy_pass http://127.0.0.1:7081/;
include /etc/nginx/proxy_params;
}
Not Working example of the nginx.conf:
location /wiki/ {
rewrite ^/wiki(.*) /$1 break;
proxy_pass http://127.0.0.1:7081/;
include /etc/nginx/proxy_params;
}
I am obviously missing something in the latter example. Does anyone know, what I am missing, so that I can simply proxy pass request directly to my dockerized web service?
EDIT:
Here a more and hopefully reproducible example:
The docker container I launched, was simply a base MediaWiki which was published internally on localhost on port 7081.
docker run --name some-mediawiki -p 127.0.0.1:7081:80 -d mediawiki
The file in /etc/nginx/sites-available/default looks like this:
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen 80;
server_name my.domain.de;
return 301 https://$host$request_uri; }
server {
listen 443 ssl;
server_name my.domain.de*;
# SSL-Certificate and key
ssl_certificate /etc/ssl/certs/my_full_chain.pem;
ssl_certificate_key /etc/ssl/private/my-key.pem;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
location /wiki {
rewrite ^/wiki(.*) /$1 break;
proxy_pass http://127.0.0.1:7081/;
include /etc/nginx/proxy_params;
}
}

NGINX + HTTPS causes 504 Gateway Timeout error for external requests

I'm running nginx server on my Raspberry Pi and it seems to be working just fine using HTTP protocol.
Recently, I decided to add HTTPS support to my server and got certificate from Let's Encrypt.
And it still works like a charm, if you are sending requests from local network. But every external request via HTTPS ends with 504 Gateway Timeout error.
Here is my config:
server {
listen 80 default_server;
listen [::]:80 default_server;
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name domain.name;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 180m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DHE+AES128:!ADH:!AECDH:!MD5;
ssl_certificate /etc/letsencrypt/live/domain.name/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/domain.name/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/domain.name/chain.pem;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
location ~ /.well-known {
allow all;
root /usr/share/nginx/html;
}
}
Found out that my ISP has a firewall service active by default. It was blocking all connections to 443 port. Disabling it resolved my issue.

Why is my WWW-Subdomain not showing?

I am curretly working on a project where WWW subdomain isn't resolving since I moved from my previous server and make my DNS point to the new IP address. Has it something to do with HSTS settings ? SSL certificates ? Wrong redirect format ? Wrong CNAME ?
On the previous server:
I issued a SSL certificate using LetsEncrypt for both domains : website.fr and www.website.fr., running with Debian/Apache
I terminated the instance without copying the certificate.
At that time, it worked on both https www and non www
On the new server:
I've created an AWS EC2 under Ubuntu16.04/Nginx
I've issued a new SSL for both domains using LetsEncrypt
Sites-available conf file (enabled):
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name website.fr www.website.fr;
return 301 $scheme://website.fr$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name www.website.fr;
ssl_certificate /etc/letsencrypt/live/website.fr/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/website.fr/privkey.pem;
include snippets/ssl-params.conf;
return 301 $scheme://website.fr$request_uri;
}
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
ssl_certificate /etc/letsencrypt/live/website.fr/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/website.fr/privkey.pem;
include snippets/ssl-params.conf;
root /var/www/...
...etc...
ssl-params.conf
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECD$
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
ssl_dhparam /etc/ssl/certs/dhparam.pem; #Diffie-Hellman 2048 group
DNS Zone settings:
IN A XX.XX.XX.XX
* IN CNAME website.fr.
www IN CNAME website.fr.
Why isn't my WWW-Subdomain also resolving ? Why isn't the page showing ?
Problem solved by itself...
Apparently, nothing was wrong in the configuration. DNS needed A LOT OF TIME to spread (24h+).
Just needed to be patient :)
You need to point another A Record with the host "www" to your IP.
This needs to be done wherever you bought the domain.

Can not restart Nginx after adding SSL cert configuration?

I just buy RapidSSL from Name.com and tried to install it following this link
https://www.digitalocean.com/community/tutorials/how-to-install-an-ssl-certificate-from-a-commercial-certificate-authority
So when i ran
sudo service nginx restart
I got this.
Job for nginx.service failed because the control process exited with error code. See "systemctl status nginx.service" and "journalctl -xe" for details.
So this is my /etc/nginx/sites-available/default
server {
listen 80;
server_name mydomain.co;
rewrite ^/(.*) https://mydomain.co/$1 permanent;
}
server {
listen 443 ssl;
ssl_certificate ~/key/www.mydomain.co.chained.crt;
ssl_certificate_key ~/key/www.mydomain.co.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
server_name mydomain.co;
root /www/mydomain/build;
index index.html index.htm;
rewrite ^/(.*)/$ $1 permanent;
location ~ ^.+\..+$ {
try_files $uri =404;
}
location / {
try_files $uri $uri/ /index.html;
}
location ~ /\. {
deny all;
access_log off;
log_not_found off;
return 404;
}
}
But when i remove this line
ssl_certificate ~/key/www.mydomain.co.chained.crt;
I can restart nginx.
Anyone know how to fix this?
Thanks!
The ~ in your nginx config file is probably not working in the way you intended. I assume you intended for it to become /home/username/key/www.mydomain.co.chained.crt, but it won't be handled like that.
To confirm this, readd the config line, and then run nginx -t. You will see nginx's config checking error log:
nginx: [emerg] BIO_new_file("/etc/nginx/~/key/www.mydomain.co.chained.crt") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/nginx/~/key/www.mydomain.co.chained.crt','r') error:2006D080:BIO routines:BIO_new_file:no such file)
I can't comment because of my new user reputation, but do you mind pasting the nginx error log ? The reason of failure should be there
The 2 things i can think on top of my head are:
1. wrong file permissions or bad location
2. wrong .crt contents - make sure that your certificate file contains the combined certificate + CA intermediate certificates in the right order (certificate first, CA after) and when you pasted those you did not added extra lines or missed some chars.

nginx wildcard ssl configuration

I have this nginx configuration for my site and using a wildcard certificate for my domain
server {
server_name *.domain;
root /var/www;
index index.php;
listen *:80;
listen *:443 ssl http2;
listen [::]:443 ssl http2;
# indicate locations of SSL key files.
ssl_certificate /etc/nginx/ssl/domain.chained.crt;
ssl_certificate_key /etc/nginx/ssl/domain.key;
ssl_trusted_certificate /etc/nginx/ssl/domain.crt;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_stapling on;
# Enable HSTS. This forces SSL on clients that respect it, most modern browsers. The includeSubDomains flag is optional.
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
# Set caches, protocols, and accepted ciphers. This config will merit an A+ SSL Labs score as of Sept 2015.
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
# config to enable HSTS(HTTP Strict Transport Security) https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security
# to avoid ssl stripping https://en.wikipedia.org/wiki/SSL_stripping#SSL_stripping
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";
# WordPress single site rules.
# Designed to be included in any server {} block.
# This order might seem weird - this is attempted to match last if rules below fail.
# http://wiki.nginx.org/HttpCoreModule
location / {
try_files $uri $uri/ /index.php?$args;
}
# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
# Directives to send expires headers and turn off 404 error logging.
location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
access_log off; log_not_found off; expires max;
}
# Uncomment one of the lines below for the appropriate caching plugin (if used).
#include global/wordpress-wp-super-cache.conf;
#include global/wordpress-w3-total-cache.conf;
# Pass all .php files onto a php-fpm/php-fcgi server.
location ~ [^/]\.php(/|$) {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
if (!-f $document_root$fastcgi_script_name) {
return 404;
}
# This is a robust solution for path info security issue and works with "cgi.fix_pathinfo = 1" in /etc/php.ini (default)
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
# fastcgi_intercept_errors on;
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
fastcgi_buffer_size 16k;
fastcgi_buffers 4 16k;
}
error_log /var/log/nginx/error.log;
access_log /var/log/nginx/access.log;
}
But im getting the error
NET::ERR_CERT_COMMON_NAME_INVALID
with message
This server could not prove that it is staging.wp.domain; its security certificate is from *.domain. This may be caused by a misconfiguration or an attacker intercepting your connection.
What im missing.
Thanks
This server could not prove that it is staging.wp.domain; its security certificate is from *.domain
Since you're using "example" names in your post, it's a bit difficult to say, but I suspect you are trying to do multiple sub domains with a wild card, which doesn't work.
Let's say you have a certificate that is valid for these names:
example.com
*.example.com
This is likely the kind of wild card certificate you have. You can tell by looking at the Subject Alternative Name in the certificate.
The "*" in a certificate does not mean "many levels deep", it means "one level deep".
These domains are valid for our certificate:
foo.example.com
bar.example.com
example.dom
These are not valid for this the certificate:
foo.bar.example.com
bar.foo.example.com
Your only option here is to get a certificate for *.wp.domain, or just staging.wp.domain if you don't need a wild card. A CA won't issue a certificate that is valid for *.*.example.com, and even browsers will ignore these kinds of wildcard rules.