--preferred-chain not taking effect

schoen · October 19, 2021, 5:33am

Maybe I'll have to correct myself back to my original impression and statement. Thanks, @Osiris!

Osiris · October 19, 2021, 5:35am

Maybe indeed. The first part of the OpenSSL output is just like when viewing the cert chain in a browser: it's showing which chain is being build. The second part is more interesting. For example, this is my OpenSSL output for the long chain:

CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = lencr.org
verify return:1
---
Certificate chain
 0 s:CN = lencr.org
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---

Notice that the chain send by the server is different (bottom part), but the top part, the chain actually build, is identical to the short chain above! (Besides the hostname of the site of course..) That's because my OpenSSL (1.1.1) will terminate the chain at ISRG Root X1, even with the long chain being send by the server. Just like most browsers.

jajoe · October 19, 2021, 7:13am

Yes, for sure.
It's an express server, the files cert.pem and key.pem are copied from /etc/letsencrypt/live/explogroup.ca/cert.pem (and privkey.pem).

const https = require('https');
const privateKey  = fs.readFileSync('key.pem', 'utf8');
const certificate = fs.readFileSync('cert.pem', 'utf8');

const credentials = {key: privateKey, cert: certificate};

const express = require('express');
const path = require('path');
const app = express();

app.use(express.static(path.join(__dirname, 'public')));

app.get('/*', function (req, res) {
          res.sendFile(path.join(__dirname, 'public', 'index.html'));
});

app.listen(80)

const httpsServer = https.createServer(credentials, app);
httpsServer.listen(443);

jajoe · October 19, 2021, 7:17am

The real domain is explogroup.ca
I have the certificates in the same folder than my express server. After renewing the certificates I delete the old ones and copy the new ones from /etc/letsencrypt/live/explogroup.ca
The fullchain.pem is the following :

Osiris · October 19, 2021, 7:27am

So you're not using fullchain.pem at all? Which is kinda weird, as your site is sending the short chain perfectly.

jajoe · October 19, 2021, 7:34am

Oh sorry, I forgot to write that I'm currently trying to use fullchain.pem insteand of cert.pem

About what you wrote yesterday @Osiris , it seems that https://www.lencr.org is working for me, but not https://www.explogroup.ca. By "not working", I mean with Safari on my Macbook I have an issue "This connection is not Private"

Do you have an idea why ?

schoen · October 19, 2021, 7:41am

Thanks! So, your site is currently correctly sending the short chain as you requested to, and your certificate configuration is valid. Are you having some compatibility or validation problems that are still concerning you?

jajoe · October 19, 2021, 7:47am

With Safari (version 14.1.2) on my Macbook Pro (macOS Bis Sur version 11.6) I still have the "This connection is not private" issue.
The trouble is that probably several of the visitors of the website will have the issue.
I was wondering if there is a way to fix this

MikeMcQ · October 19, 2021, 12:26pm

www.lencr.org sends the long chain. www.explogroup.ca is using the short chain. Have you tried using the long chain? Was there a reason you needed to use the short chain?

jajoe · October 19, 2021, 12:52pm

I'm not really familiar with the notions of short chain and long chain . So there is no reason why I'm using the short chain, and I think I didn't try to use the long one.
What do I have to do to use the long chain please ?

(I read the following article Providing a longer certificate chain by default to understand what a long chain is, but do I have it and am using the wrong file, and did I do something wrong when renewing ?)

rg305 · October 19, 2021, 12:59pm

The long chain is the default.
So the site has switched to using the shorter/alternate chain.

echo | openssl s_client -connect www.explogroup.ca:443 -servername www.explogroup.ca | head
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = explogroup.ca
verify return:1
CONNECTED(00000005)
---
Certificate chain
 0 s:CN = explogroup.ca
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---

If you can't access the site securely, then your client system lacks the "ISRG Root X1" trusted root cert.

MikeMcQ · October 19, 2021, 1:08pm

Remove the --preferred-chain option from your command. Then it should work the same for you as www.lencr.org

See:

jajoe · October 19, 2021, 2:00pm

Thanks for your answers @MikeMcQ @rg305 ,
How could I check if I'm currently using a long or a short chain ?
I try to renew without the preferred-chain and the result is currently in production, but it seems I still have the issue with the Macbook

(It was my 5th try for this domain, so now I reach the rateLimit )

MikeMcQ · October 19, 2021, 5:06pm

@jajoe You are still using the short chain. Rudy already showed the command to check the chain your server is currently using. The post I linked to about long/short chains also shows how right at the beginning.

If one of your previous certs was for the default long chain, you could temporarily change your server def to use a set from the /etc/letsencrypt/archive/... folder. Make sure to update your server def back to the live version once you finish.

You can check the chains for a local file a variety of ways - google has many - usually based on a script. But, this works for me:

openssl crl2pkcs7 -nocrl -certfile /etc/letsencrypt/archive/your-folder-name-here/fullchainX.pem | openssl pkcs7 -print_certs -noout

Iterate through each fullchain file until you find one using the long chain and use it and the related key/cert files as needed.

You really should read the "Long and Short Chains Explained" article I linked to previously. You should understand the tradeoffs involved between the two.

You can also make these chains by hand but I would not recommend that until you understand them well.

jajoe · October 19, 2021, 6:08pm

I found something in the archive, regarding https://decoder.link/sslchecker/explogroup.ca/443 (I tested too with the command shared by Rudy) things seem to be ok. Ok with Safari on my Macbook too !
I'm going to ask some users to check with their devices, but I think the issue is fixed now.
Thank you all for your help

exeral · November 17, 2021, 11:28am

Hello,

I came across this thread after trying to use --preferred-chain "ISRG Root X1" without any effect .
in certbot 1.7 (python 3.5)
on debian stretch

I updated to python 3.7
certbot to 1.21
now it works

system · December 17, 2021, 11:28am

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Cert-manager+LE giving unwanted DST X3 chain after Feb 8 Issuance Tech	8	838	March 20, 2024
DST Root CA certificate not yet valid - Fixed Help	6	777	September 18, 2022
Cert Chain issue Help	5	480	May 26, 2023
Let encrypt update for dst root ca x3 Help	6	1288	October 2, 2022
Is the preferred-chain 'DST X3 Chain' option live? Help	5	2099	January 20, 2021

--preferred-chain not taking effect

Related topics