I am using Nginx and dehydrated.

This is primarily for our staging servers on sub domains eg www2 etc. I'm using route 53 for our dns and the sites seem to be served correctly and Firefox does not complain. However if I test the pages with GTmetix or validate the certificate with sslshopper I get this error.

"The certificate is not trusted in all web browsers. You may need to install an Intermediate/chain certificate to link it to a trusted root certificate."

Route 53 has an aws cert for www.domain.com and dns enrty for www2 pointing to my ip address

Does anyone have any idea how to resolve this problem. My settings in Nginx are

       ssl_certificate /var/lib/dehydrated/certs/www2.domain.com/cert.pem;
       ssl_certificate_key /var/lib/dehydrated/certs/www2.domain.com/privkey.pem;

Anyone else seen this ?

Thanks

Paul

 

Forum: 
Jeremy Davis's picture

Is your server TurnKey Linux? If so, our built-in dehydrated-wrapper script should construct the certs in such a way that they should "just work". I definitely have not come across that issue before.

I just checked Qualys SSL Labs and got an "A" rating (with some tweaks I could get more I'm sure) but no sign of that error you noted. I also tried SSL Shopper's "SSL Checker" and that passed. For some reason GTmetrix just gave me: "Analysis Error - An error occurred fetching the page: Server closed connection without sending any data back" so I have no idea what the issue is there?!

Regardless, I did a quick google and it seems that there are a number of people who have hit this issue. My quick reading suggests that there is some incorrect config somewhere (you probably already guessed that so it's probably not that helpful).

I suggest posting on the Let's Encrypt forums.

Sorry I'm not that much help...

Jeremy Davis's picture

My apologies, I just noticed your username so I am assuming that this is indeed a TurnKey server then?! Are you using our Let's Encrypt integration with the http hook we provide? FWIW, we write the "FULLCHAIN" to the cert file. I notice that there is a "CERTFILE" variable provided by Dehydrated, but we don't use that.

If you want to explain a bit more how things are set up (i.e. what you've done, changes you made, etc.) and perhaps even share your hook script, perhaps I can help you resolve this.

Thanks for reply Jeremy, my setup is as follows.

V15 Nginx server which is public facing on my external IP address.
V15 TK LAMP server running Plesk.

The Nginx Server acts as a reverse proxy to my 2 Plesk servers. I.e. issue the certificates using Nginx and dehydrated wrapper. With normal web browsing it appears the certificate is correct however I get the error when test the pages on GtMetrix. I don't think this is an issue with the sub domain as I get the same error across all of my sites.

The reverse proxy is using Http for the internal network.

Open shell in edit the domains txt file

etc/dehydrated/confconsole.domains.txt

then run

/usr/lib/confconsole/plugins.d/Lets_Encrypt/dehydrated-wrapper

I updated the V15 appliance as per

https://github.com/turnkeylinux/confconsole/releases/tag/v1.1.1

It seems the error is also not related to the DNS provider as I'm using more than one.

Is it something to do with the  .pem file Nginx is using ?

Thanks

 

 


Jeremy Davis's picture

Re the dehydrated setup, your last post suggests that you are using the Dehydrated default (plus your domains)?I But in your OP you said you were using these files:

ssl_certificate /var/lib/dehydrated/certs/www2.domain.com/cert.pem;
ssl_certificate_key /var/lib/dehydrated/certs/www2.domain.com/privkey.pem;

They look like they may be the raw files that Dehydrated pulls from Let's Encrypt? Rather than the ones constructed by our dehydrated wrapper?! FYI, the ones our wrapper builds overwrite the default self-signed ones. I.e. they are found here:

/etc/ssl/private/cert.key
/etc/ssl/private/cert.pem

So assuming that your Nginx reverse proxy is doing the TLS termination, then one way would be to put both of the domains on the same line (space separated) in /etc/dehydrated/confconsole.domains.txt. That will generate a single cert that signs both certs. Then you can just let our LE integration create the files in /etc/ssl/private and you can use them directly (i.e. as it works by default).

Alternatively, it looks like you may just be using the certificate itself, rather than the fullchain cert (and my reading of the error message suggests that it wants the full chain). Perhaps try using the full chain cert instead?

Jeremy Davis's picture

You note that you have installed Confconsole v1.1.1. If you haven't already, please be sure to disable the add-water service! If you don't, then next time your server reboots, Nginx may not be able to start... A race condition will exist where both Nginx and add-water will try to bind port 80. Which ever one starts first wins. To ensure that won't happen:

systemctl disable add-water

Note that add-water will run fine even when disabled. I just won't auto start on boot.

On V16

I placed all domains (20+) on single line now nginx wont start with this error

"nginx: [emerg] SSL_CTX_use_PrivateKey_file("/etc/ssl/private/cert.key") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)"

Tried LE via console but doesnt run as no nginx on port 80

Back on V15. I had already disalbed add water.

Are you saying I dont specoify the path to the ssl on a per domain conf file ? Just use

/etc/ssl/private/cert.key
/etc/ssl/private/cert.pem

For all domains ?

Thanks

 

 


Jeremy Davis's picture

Apologies on that. I didn't realise that you had 20+ domains! I'm not sure what the limit is for putting them all on one line. But I probably wouldn't have suggested putting them all on one line if I knew you had that many! (You only mentioned 2...).

I've seen your more recent responses, but for completeness (in case someone else reads this), yes, I meant just let Nginx use the consolidated certs. FWIW, if you are using a TurnKey appliance that came with Nginx, then they are auto included via the ssl config.

Using

       ssl_certificate /var/lib/dehydrated/certs/www2.domain.com/fullchain.pem;
       ssl_certificate_key /var/lib/dehydrated/certs/www2.domain.com/privkey.pem;

Resolves the chain issue.


Jeremy Davis's picture

I suspected that might have solved the issue. Thanks for confirming! :)

Have it working now on V16.0 using fullchain.pem. I prefer to use the lib/dehydrated path to each domain for certs. Just makes more sense to me. Otherwise debug nginx failing to start is confusing.

Still getting Grade B on https://www.ssllabs.com

This server supports TLS 1.0 and TLS 1.1. Grade capped to B.

How to move to Grade A

Thanks

Paul


Jeremy Davis's picture

By default, all of our appliances should be locked to only TLSv1.2 & TLSv1.3 (anything lower blocked). For Nginx that's this line: So either you aren't including that file, or perhaps you don't even have it?!

ssl_protocols TLSv1.2 TLSv1.3;

If you are using an appliance that shipped with Nginx (i.e. you didn't install it yourself) then you should already have that configured and included via the separate ssl config file (/etc/nginx/include/ssl).

Regardless though, I can't recommend enough Mozilla's SSL config generator (FWIW, I pre-filled with the appropriate v16.x versions of Nginx & OpenSSL but you can toggle/change a number of other settings).

We don't lock it down quite that much by default (via the config provided by the link above) - as that will block connection to a number of devices, plus auto redirect to HTTPS. Because of the array of TurnKey users, we try to balance security and flexibility/usability for a fairly broad audience. Hopefully you know which devices and browser versions you need to support, so you can lock it down as much as you like.

I had checked and noticed that my install of V16 has this line in nginx.conf

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE

Which is the old one So that explains it. I restored the V15 settings from the hub to the V16 machine.

Can you confirm if the restore replaces this default file. It's the only way I can think of that this is been overwritten as the date of the file is 2018. I always assumed the hub only restored user files ?

Nginx is

nginx version: nginx/1.14.2
built with OpenSSL 1.1.1d  10 Sep 2019

Thanks

Paul

 


Jeremy Davis's picture

Yes, unless you tell it otherwise, TKLBAM will happily restore your full backup over the top of whatever is there. So the default v16.x config was overwritten with the config from your v15.x.

Although FWIW, if you did a Debian "in place" upgrade, unless you chose to use the new config (which would have resulted in your current config being lost) then you'd still have your old config too.

I think I posted it before, but here's the Nginx SSL config file. You could just copy/paste it, or you can download the "raw" file, like this:

curl -O /etc/nginx/include/ssl https://raw.githubusercontent.com/turnkeylinux/common/master/overlays/nginx/etc/nginx/include/ssl

Re migrating data with TKLBAM, whilst restoring should get you going, to take full advantage of the updated config that we provide, I generally recommend doing a staged restore and only restore the files/directories that you definitely know you need.

I just did a clean install to check and don't know if this is an error but there are two duplicate lines in the V16 Nginx setup.

In etc/nginx/nginx.conf

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

and in etc/nginx/includes/ssl

ssl_protocols TLSv1.2 TLSv1.3;

So lookslike serve ris still supporting TLS v1 ?

Regards

Paul

 


Jeremy Davis's picture

When you say "clean install" do you mean of the Debian Nginx package? E.g. something like this:

apt purge nginx
apt update
apt install nginx

Or do you mean a fresh install of a TurnKey appliance? (And if so which one?).

I ask because that /etc/nginx/nginx.conf file you quote doesn't look like ours. In a TurnKey appliance all the SSL/TLS config should be in /etc/nginx/includes/ssl (FWIW, that's not a default Debian file, we provide that). I'm curious to understand how you got to where you are.

Also in nginx.conf I cant path to inc the ssl file only

include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;


Commented out the 2  lines and added  include /etc/nginx/include/ssl; Now A rating.

Paul


Jeremy Davis's picture

Glad to hear that you are now getting an A! :)

Although personally, I'd recommend that you have a look at the files within /etc/nginx/conf.d/ and/or /etc/nginx/sites-enabled/. IMO, unless you are serving a single fairly basic site, it's better to leave the 2 includes lines that you've removed. And instead edit (or remove) any of the files that are being included to be the way you want them. FWIW the /etc/nginx/sites-enabled/ dir is intended for scenarios where you are hosting multiple endpoints from the one server (like you are with your reverse proxy).

You noted earlier that you are using individual certs for each "site". Given that, then the "right" way to configure things (or at least my recommendation) is for each individual site's unique config to be within it's own appropriately named separate file in /etc/nginx/sites-available. All common config can go in /etc/nginx/nginx.conf and/or in a file in /etc/nginx/include/ which is included in /etc/nginx/nginx.conf. To "enable" a site, symlink from the file in sites-available to /etc/nginx/sites-enabled. Note that that would also require that you reinstate the "include /etc/nginx/sites-enabled/*;" line in /etc/nginx/nginx.conf. If there is config which is common to some sites but not all, you can create a new file in /etc/nginx/include/ and include it within the relevant site files in /etc/nginx/sites-available.

As something of an aside, in case you aren't already aware, in the Linux shell (or at least bash and the other common ones) '*' (asterisk/star) is a globbing wildcard. I.e. it will match with any filename (or part of a filename - in this context, a symlink to a file also counts as a file) within /etc/nginx/sites-enabled. The other one (/etc/nginx/conf.d/*.conf) will match with any file in /etc/nginx/conf.d/ which ends in '.conf'.

If you do your config that way, then all your common config can be managed together and adding/removing sites will be super simple. If you want to make changes to all sites, adjust nginx.conf and/or any files included in the main nginx.conf file. If you need to tweak an individual site, you know exactly where to go to change it. If you wish to disable a site (temporarily or permanently), you can just delete the symlink and restart Nginx. The config is still there if you change your mind and/or you could repurpose it for another (new) site.You could even have a template file in there that you could copy when you create a new site.

E.g. a structure that looks something like this:

├── sites-available
│   ├── disabled.domain.com
│   ├── www.my-enabled-domain.com
│   └── www.my-other-enabled-domain.com
└── sites-enabled
    ├── www.my-enabled-domain.com -> ../sites-available/www.my-enabled-domain.com
    └── www.my-other-enabled-domain.com -> ../sites-available/www.my-other-enabled-domain.com

FWIW, use the 'ln -s' command to make a symlink. It's done in this format:

ln -s /path/to/existing/file /path/to/new/symlink

I recommend using the full absolute path to the relevant files as I did in the 'ln' example above. Alternatively, cd to where you want the symlink and use the relative path to the file you're symlinking to (as I did when I created the example filesystem further up).

Thanks Jeremy,

I explained myself badly. I'm aware of the includes in sites-enabled etc that's how I do it. What I was trying to explain was the default v16.0 has these two lines.

In etc/nginx/nginx.conf

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

So V16 is supporting TLSV1 which is why you get a grade B.

the file /etc/nginx/includes/ssl

ssl_protocols TLSv1.2 TLSv1.3;

However this path is not in the default V16 nginx.conf include ?

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

So To get an A rating I did as follows.

Commented out

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

added the missing ssl config

include /etc/nginx/include/ssl;

Regards

Paul


Jeremy Davis's picture

Ok, no worries.

As for the 'ssl' include, in the Nginx appliance it's not in the nginx.conf, it's in the default site.

I was under the impression that it needs to be within the relevant 'server {}' block. I.e. where you define the specific HTTPS virtual host. So I wasn't aware that there was a workable way it put in the nginx.conf and have all virtual hosts pick it up?! That's why we moved it out to separate file in the first place! :)

But if it seems like there is someithing I'm missing, please share.

Add new comment