--preferred-chain not taking effect

Found this thread because I too have issues with --preferred-chain not working as I had understood it to work.

I ran:
certbot renew --force-renewal --preferred-chain "ISRG Root X1"

preferred_chain = ISRG Root X1 is even in my /etc/letsencrypt/renewal/<domain>.conf

renewal was a success but both chain.pem and fullchain.pem still have a CA cert ISRG Root X1 signed by DST Root CA X3

Subject: C=US, O=Internet Security Research Group, CN=ISRG Root X1
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3

certbot-1.11, on EL7.

4 Likes

Hi @onmeac welcome to the LE community forum :slight_smile:

I think you need certbot version 1.12 (or higher) to use --preferred-chain

4 Likes

Thank you, that bit information was missing from all proposed sollutions

Maybe it helps someone else, I did this:

sudo yum install python3
sudo mkdir /certbot
sudo python3 -m venv certbot/
sudo /certbot/bin/pip3 install --upgrade pip
sudo /certbot/bin/pip3 install certbot
# stop any services listening op ports 80/443
sudo /certbot/bin/certbot renew --force-renewal --preferred-chain "ISRG Root X1"
4 Likes

Notice that using pip as the installation method is not the recommended method for most Linux distributions. While it could have been the only way for @onmeac to update their certbot, please refer to https://certbot.eff.org/ to check the recommended installation method for your distribution/OS.

4 Likes

For sure, thank you. Definitely something we'll need to consider doing. I didn't realize our version was that far behind what's current. :frowning:

Also a tad bit hesitant to update as I didn't write the automation and scripting we have set up so we'll definitely need to do a bunch of testing to make sure it doesn't break our current setup. But this is probably something we should do regardless.

4 Likes

Do you run it on CentOS? I think this comment is related: Nginx with preferred-chain "ISRG Root X1" - still showing "DST Root CA X3" - #31 by FelixSchwarz

it seems there is some issue in CentOS certbot package and the fix is on the way.

I have encountered the same problems on CentOS machines.

3 Likes

Short version: Try certbot 1.11.0-2 from epel testing.

For more details please read:

7 Likes

Hello,

I have exactly the same issue than @onmeac :
I ran certbot renew --force-renewal --preferred-chain "ISRG Root X1",
in /etc/letsencrypt/renewal/<domain>.conf I have preferred_chain = ISRG Root X1 and version = 1.20.0, but despite this my cert.pem still depends on R3.
I'm checking the certificate by running the following command openssl s_client -servername mydomain.ca -showcerts -connect mydomain.ca:443, and I still have
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 = mydomain.ca

Does someone have an idea of how to fix this ?

I tried the use of certbot installed by pip3 (after stopping any services listening op ports 80/443), as @onmeac did, but it didn't fix the issue.

Thanks in advance,

Jajoe

3 Likes

Hi @jajoe,

Your chain is the expected one if you specify `preferred_chain = ISRG Root X1`.

The R3 intermediate is always the issuer for all Let's Encrypt certificates. If you used the long chain, you would also be serving a path that refers to the expired DST Root CA X3. Since you specified the preferred chain, you are not serving that path and your server's suggested trust path chains up to ISRG Root X1, via R3, like all other current Let's Encrypt certificates.

Sorry, I mistook what you were saying about your openssl output.

Can you tell us your real domain? And what's in your fullchain.pem file? You didn't copy chain.pem elsewhere or hard-code a reference to a particular version of it or anything, right?

4 Likes

@jajoe
Can you show the lines of code in the web server that are using the cert files?

3 Likes

This is a regular output for OpenSSL chaining up to the ISRG Root X1 certificate. For example, if I connect to acme-v02.api.letsencrypt.org, whhich is also using the "short chain", my OpenSSL outputs:

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 = acme-v01.api.letsencrypt.org
verify return:1
---
Certificate chain
 0 s:CN = acme-v01.api.letsencrypt.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
---

So from that first output you can only see to which cert the chain is being build. But with the output just below that, you can see the chain send by the server.

5 Likes

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

4 Likes

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.

3 Likes

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);
2 Likes

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 :

-----BEGIN CERTIFICATE-----
MIIFHzCCBAegAwIBAgISBKtwalzKWKL8v1Qa+lpTjQVlMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTEwMTgyMDIzMjJaFw0yMjAxMTYyMDIzMjFaMBgxFjAUBgNVBAMT
DWV4cGxvZ3JvdXAuY2EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDP
mEszFgQIlBItOPapC1R1ZoffTniiegvMZW2YXmOfdTEPtPNyfp7jbHdEnR5kGLt7
6JMDKt3aEzq4vKNznSlJHn37jfrNybb6VPfvDvwmFtqCNwZ2VDB6nuCyS6ChdQmn
7zJkvD2j4guG6ilklFO63nqkNmP8QKlHLMUljuRQS/ft3xHw9nXFvLGGeTQikh5s
ZTzIw9CarX8n2OM81GW0nP936SUD1CPG1Nx4osSOBINkHiX/Ad/g5S1LA+d96wV3
Bc8T9Skpwlz6E2Uakx3XCiPWkaXs/Tj64m1vDnah1gO07b1aEjHgxqejeg596IqY
nLjQEzyu4Zu1IuZ0hf3LAgMBAAGjggJHMIICQzAOBgNVHQ8BAf8EBAMCBaAwHQYD
VR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0O
BBYEFCchrG3JiNtfXQuyEJQ7gXZeInJ8MB8GA1UdIwQYMBaAFBQusxe3WFbLrlAJ
QOYfr52LFMLGMFUGCCsGAQUFBwEBBEkwRzAhBggrBgEFBQcwAYYVaHR0cDovL3Iz
Lm8ubGVuY3Iub3JnMCIGCCsGAQUFBzAChhZodHRwOi8vcjMuaS5sZW5jci5vcmcv
MBgGA1UdEQQRMA+CDWV4cGxvZ3JvdXAuY2EwTAYDVR0gBEUwQzAIBgZngQwBAgEw
NwYLKwYBBAGC3xMBAQEwKDAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5j
cnlwdC5vcmcwggEDBgorBgEEAdZ5AgQCBIH0BIHxAO8AdQBByMqx3yJGShDGoToJ
QodeTjGLGwPr60vHaPCQYpYG9gAAAXyVSZ/aAAAEAwBGMEQCIH3xIC9frFL0IB3z
R2fTWJKqbrtnwDOUgzBJdlVdcINzAiA77P7/PQEX3Fju2GEeLNKL4cpW7xn2dU0y
3cD81EcEYAB2AEalVet1+pEgMLWiiWn0830RLEF0vv1JuIWr8vxw/m1HAAABfJVJ
oBYAAAQDAEcwRQIhAI33oBCzL9M+ifDx6GwdCUk4Obc8WmckXi8wX2Uz/+vQAiAg
b+sZR+UodTNGOxD/n9gGd7dYB/j3ddaAey82ZtZ0VDANBgkqhkiG9w0BAQsFAAOC
AQEAT+5wwA0SfPu1xQb1bTna0QXrmsZBitgU78GpjYwH5kNNj5mf52atb8g1r9RY
VM5+87Jim3NcSOvwrGt2TTZB5TZftfWYxXVP3+nLlRMcnYRD4GUGhhtzPSkjb+BL
8FNx8B4fGs8i8twFXXIPRCPEgF41BOuvYTl+GtWvttpY7j14/xHBB5HcX3bdJjNc
E07dhfy5GGmzBK6nDPIEajsbX1WHHZHxLiJ7O6AXXvvBreP+AKc/MC4oQ5wkduPK
gkQPb8GKvo71Groti+ac+4gZIfxuCRQtnj0nv0Hul+B+WQyDvjqYaz0iTAVZ0Wcy
OkvRMAN6qWFH1iQrJELAwBw8nQ==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-----END CERTIFICATE-----
2 Likes

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

4 Likes

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 ?

2 Likes

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?

4 Likes

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 :thinking:

2 Likes

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?

4 Likes