I'm using the following nginx.conf
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
server {
listen 80;
server_name mydomain.org;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2;
ssl_certificate /etc/letsencrypt/live/mydomain.org/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mydomain.org/privkey.pem;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/certs/dhparam.pem;
add_header Strict-Transport-Security max-age=15768000;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/mydomain.org/chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=86400;
root /var/www/html;
index index.php;
location / {
try_files $uri $uri/ /index.php?$args;
}
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
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;
}
location ~ [^/]\.php(/|$) {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
if (!-f $document_root$fastcgi_script_name) {
return 404;
}
root /var/www/html;
fastcgi_pass wp_db:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/html$fastcgi_script_name;
include fastcgi_params;
}
}
}
But nginx container complains with:
nginx: [emerg] BIO_new_file("/etc/letsencrypt/live/mydomain.org/fullchain.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/mydomain.org/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
I have all the certificates on that path for let's encrypt.
I found this thread
https://serverfault.com/questions/537343/nginx-startup-fails-ssl-no-such-file-or-directory
And did
chown -R root:root /etc/letsencrypt/live/mydomain.org/fullchain.pem
chmod -R 600 /etc/letsencrypt/live/mydomain.org/fullchain.pem
Same error was thrown from nginx container. I've placed the certs on /docker-compose/etc/nginx/certs giving the same permissions and changing links on nging.conf but nothing changed.
What I'm missing?
I was experiencing the same problem deploying harbor (a docker registry + access control UI) using volume mapping /etc/letsencrypt:/etc/letsencrypt
nginx reported "no such file" when loading the certificate file, even though I could enter that container (docker exec bash ..) and cat the files using the exact same path.
I suspected the problem is caused by letsencrypt use of symlinks, so my solution was to copy the live certs into another folder using cp -rL (to de-reference symlinks)
root#registry:/etc/letsencrypt# mkdir copy
root#registry:/etc/letsencrypt# cp -rL live/* copy/
then I changed the nginx.conf to refer to 'copy' instead of 'live'
Now nginx correctly starts inside docker.
This is not a long-term solution because when the certs are renewed the copy won't get automatically updated. But since I'll be running letsencrypt renew from a cronjob, that task can run the copy process again.
Also I've read that nginx must be restarted if the certs change, so that's another issue I'll need to face. But at least nginx starts correctly now.
I got this error when I renamed apps in Dokku (0.5.4). What had happened is that the links in the new app directory pointed to the old app name, e.g.
/home/dokku/[new app]/letsencrypt/certs/current -> /home/dokku/[old app]/letsencrypt/certs/f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1
So I manually recreated the links so the pointed to the right place.
try to start with /root :
ssl_certificate /root/etc/letsencrypt/live/mydomain.org/fullchain.pem;
ssl_certificate_key /root/etc/letsencrypt/live/mydomain.org/privkey.pem;
I solved the problem like this.
Joy
I wasted a day today and found the solution.
Run nginx docker engine with
-v /etc/letsencrypt/archive/your_domain.com:/nginx/letsencrypt/your_domain.com
and nginx.conf
ssl_certificate /nginx/letsencrypt/your_domain.com/fullchain1.pem;
ssl_certificate_key /nginx/letsencrypt/your_domain.com/privkey1.pem;
Related
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;
}
}
I am trying to enable TLS 1.3 on my server. I have followed an abundance of articles on Google and have the same configs settings in my own config, yet I cannot get it past TLS 1.2.
I am on Ubuntu 16.
I am using NGINX version 1.14 which is built with OpenSSL 1.1.1.
➜ nginx -V
nginx version: nginx/1.14.2
built with OpenSSL 1.1.1 11 Sep 2018 (running with OpenSSL 1.1.1a 20 Nov 2018)
TLS SNI support enabled
These are all the required versions of the software I have seen that are needed to support TLS 1.3.
I'm using Chrome 72 and SSL Labs when testing the certificate but it just always says it's on 1.2.
Here is the part of my NGINX config file that's related to the SSL options
ssl_protocols TLSv1.3 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_ecdh_curve X25519:secp256k1:secp384r1:prime256v1;
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES25
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:10m;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 216.146.35.35 216.146.36.36 valid=60s;
resolver_timeout 2s;
I got the Ciphers from https://cipherli.st.
With these configuration options, I cannot get past the TLS 1.2 protocol.
I believe this is everything I can think of that might be causing me issues, but I can tell you of anything further you might need to know to help my case.
Thanks,
Chris
Enabling TLSv1.3 on Nginx might be looking pretty straight forward, but is not documented as it should.
Cutting to the chase now. The trick is to include the SSL settings in every server block of your config. Not doing so, will result in the fact of a disabled TLSv1.3. This makes sense in the way that the tls protocol is not "upgraded" upon the first request that hits the server:
sudo vi ssl_config
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header Referrer-Policy no-referrer;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;
ssl_session_tickets on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_ecdh_curve auto;
keepalive_timeout 70;
ssl_buffer_size 1400;
ssl_dhparam ssl/dhparam.pem;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=86400;
resolver_timeout 10;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
And:
server {
server_name xxx.xxx.xxx.xxx; #Your current server ip address. It will redirect to the domain name.
listen 80;
listen 443 ssl http2;
include ssl_config;
return 301 https://example.com$request_uri;
}
server {
server_name www.example.com;
listen 80;
listen 443 ssl http2;
listen [::]:80;
listen [::]:443 ssl http2;
include ssl_config;
# Non-www redirect
return 301 https://example.com$request_uri;
}
server {
server_name example.com;
listen 443 ssl http2;
listen [::]:443 ssl http2;
root /var/www/html;
charset UTF-8;
include ssl_config;
location ~* \.(jpg|jpe?g|gif|png|ico|cur|gz|svgz|mp4|ogg|ogv|webm|htc|css|js|otf|eot|svg|ttf|woff|woff2)(\?ver=[0-9.]+)?$ {
expires max;
add_header Access-Control-Allow-Origin '*';
add_header Cache-Control "public, must-revalidate, proxy-revalidate";
access_log off;
}
#access_log logs/host.access.log main;
location ~ /.well-known/acme-challenge {
allow all;
root /var/www/html;
default_type "text/plain";
}
location / {
index index.php;
try_files $uri $uri/ /index.php?$args;
#limit_conn num_conn 15;
#limit_req zone=num_reqs;
}
error_page 404 /404.php;
#pass the PHP scripts to FastCGI server listening on php-fpm unix socket
location ~ \.php$ {
try_files $uri =404;
fastcgi_index index.php;
fastcgi_pass php:9000; #for docker.
#fastcgi_pass unix:/var/run/php7-fpm.sock; #for non-docker.
fastcgi_pass_request_headers on;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_intercept_errors on;
fastcgi_ignore_client_abort off;
fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_request_buffering on;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
include fastcgi_params;
}
location = /robots.txt {
access_log off;
log_not_found off;
}
location ~ /\. {
deny all;
access_log off;
log_not_found off;
}
}
Now it will work 100%, using the strongest ciphers available.
I made a blog post a while back about how to enable TLS 1.3 in Nginx.
As added bonus, as of versions 1.18.0, 1.17.10 and above,i maintain fresh tls1.3 enabled docker images
Your ssl_protocols should be ordered as TLSv1.2 TLSv1.3.
Then, your ssl_ciphers should include the list of TLSv1.3 ciphers first (in this order):
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256
followed by your TLSv1.2 ciphers. Here's what tls13.iachieved.it nginx.conf looks like:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_8_SHA256:TLS_AES_128_CCM_SHA256:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
ssl_prefer_server_ciphers on;
And connecting to it with Chrome 72:
And the response from the site:
Your User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
Your client supports the following ciphers: 0x2a2a:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:0x000a
The negotiated cipher with this server is: TLS_AES_256_GCM_SHA384
Note that the your client supports the following ciphers is what your web browser supports, not the server.
Did you also check /etc/nginx/sites-enabled/yoursite and if you are using Let's Encrypt, /etc/letsencrypt/options-ssl-nginx.conf? Only editing /etc/nginx/nginx.conf might not be enough.
I experienced the same problem today. For me, the reason was that I use letsencrypt's Certbot. It creates /etc/letsencrypt/options-ssl-nginx.conf, where the ssl-protocols are also defined. If you don't adjust them there, changing the /etc/nginx/nginx.conf won't help.
Be careful when editing /etc/letsencrypt/options-ssl-nginx.conf as it is managed by Cerbot. Check, if everything is still working using sudo certbot renew --dry-run.
For further reading, I recommend https://libre-software.net/tls-nginx/.
anyone seeing this should be sure they check/adjust the protocol and cipher list in their default server block in nginx.conf also.
Just try to start nginx with simply ssl configuration:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
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.
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.
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.