Letsencrypt chain.pem or trusted root list cert?

I’m using Letsencrypt certificates for MQTT TLS, and it works great, however I’m a little confused about the use of chain.pem as a CA certificate.
In this post;


@schoen says that the chain.pemcacert.pem so I’ve used chain.pem as the CA Certificate in the TLS configuration.

However, others have advised that root certificate verification should be provided via Debian’s trusted root cert list, such as DST_Root_CA_X3.pem and not chain.pem

Could anyone advise the pro’s & con’s of those two certificates please?

Chain.pem should NOT contain the actual root cert.
Root certs should be known (or obtained/updated by other methods).
The chain.pem should provide all the necessary intermediary certs to complete the chain.
The last link in the chain(.pem) should point to an already trusted root cert (within your store).

So to answer your question:
“Letsencrypt chain.pem or trusted root list cert?”
You need both; because they are different and are both required to complete the chain of trust.

Hi @rossoreed

there is no pro and con. As @rg305 wrote, a webserver should not send the root certificate. The client says: “These are my root certificates”.

But there are sometimes online tools with wrong results.

Sorry, I’m new to this, and thanks for the help…

So should the broker use certs like this;

# Secure MQTT
listener 8883
cafile   /etc/ssl/certs/DST_Root_CA_X3.pem
certfile /etc/letsencrypt/live/mydomain.com/cert.pem
keyfile  /etc/letsencrypt/live/mydomain.com/privkey.pem

or should it be;

# Secure MQTT
listener 8883
cafile   /etc/letsencrypt/live/mydomain.com/chain.pem
certfile /etc/letsencrypt/live/mydomain.com/cert.pem
keyfile  /etc/letsencrypt/live/mydomain.com/privkey.pem

Both are looking wrong. Please share your domain name.

It’s https://digitalnut.co.uk which is a node-RED server on port 1880

There is a wrong / incomplete chain - https://check-your-website.server-daten.de/?q=digitalnut.co.uk:1880#connections

So the intermediate certificate is missing.

A correct chain should look like

Your first version is wrong, there is the root certificate included.

Your second may be correct, but chain.pem must have only one certificate (the intermediate certificate). If chain.pem has both certificates, remove the leaf certificate (it’s in cert.pem).

Change your configuration to use (2), then recheck your domain.

With (2) loaded I still get the same results.

chain.pem has only one certificate in it, whilst fullchain.pem has two, although I am not using chain.pem in the node-RED server config anyway, just privkey.pem and cert.pem could that be the cause of the Chain Incomplete error?

(this is the way node-RED enables HTTPS)

    // The following property can be used to enable HTTPS
    // See http://nodejs.org/api/https.html#https_https_createserver_options_re$
    // for details on its contents.
    // See the comment at the top of this file on how to load the `fs` module u$
    // this setting.
    //
    https: {
    key: fs.readFileSync('/home/pi/.node-red/certs/privkey.pem'),
    cert: fs.readFileSync('/home/pi/.node-red/certs/cert.pem')
           },

Try:

# Secure MQTT
listener 8883
cafile   /etc/ssl/certs/DST_Root_CA_X3.pem
certfile /etc/letsencrypt/live/mydomain.com/fullchain.pem #cert+chain
keyfile  /etc/letsencrypt/live/mydomain.com/privkey.pem

If you have only two places to add certificate files, use fullchain.

Then restart your server, then recheck your domain (there is no recheck visible, you have to start a recheck manual).

Still the same result

certfile /home/pi/.node-red/certs/fullchain.pem
cafile   /etc/ssl/certs/DST_Root_CA_X3.pem
keyfile  /home/pi/.node-red/certs/privkey.pem

Still the same result

    https: {
    key: fs.readFileSync('/home/pi/.node-red/certs/privkey.pem'),
    cert: fs.readFileSync('/home/pi/.node-red/certs/fullchain.pem')
           },

Could this be due to me using the same Letsencrypt certificates in both node-RED’s SSL config AND Mosquitto TLS?

How did you checked that?

Which instance answers port 1880?

Using the link which you gave above - https://check-your-website.server-daten.de/?q=digitalnut.co.uk:1880#connections

1880 is the port which serves the node-RED UI - https://digitalnut.co.uk:1880
MQTT is using port 1883

As written: You have to recheck the domain.

09.11.2019 18:55:14

The check is two hours old.

1 Like

What do I need to do to ‘recheck the domain’? Do you mean check again a little later?
The site is not cached, and the UI is showing live data.

Check it again (that info is from the last check):

For what it’s worth, I do see a proper chain at :1880

Certificate chain
 0 s:/CN=digitalnut.co.uk
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

Oh dear, that was embarrassing!

So using;

certfile /home/pi/.node-red/certs/fullchain.pem
cafile   /etc/ssl/certs/DST_Root_CA_X3.pem
keyfile  /home/pi/.node-red/certs/privkey.pem

In my Mosquitto config, and

    https: {
    key: fs.readFileSync('/home/pi/.node-red/certs/privkey.pem'),
    cert: fs.readFileSync('/home/pi/.node-red/certs/fullchain.pem')
           },

in node-RED config, it’s now looking much better!

Thank you both for your patience & help.

3 Likes

Cool.

Now when you get a chance, maybe you can improve your cipher preference order:
[completely unrelated]

ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-CHACHA20-POLY1305 ^^^
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA
AES256-GCM-SHA384
AES256-CCM8 vvv
AES256-CCM vvv
AES128-GCM-SHA256 ^^^
AES128-CCM8 vvv
AES128-CCM vvv
AES256-SHA256 ^^^
AES128-SHA256 ^^^
AES256-SHA
AES128-SHA

And maybe add an ECDSA cert t’boot!

1 Like

Now your chain is complete.

And I see: I should add a http/2 check if the port is a non-standard port not included in the port-check-list.

2 Likes