Certbot has been configured to prefer certificate chains with issuer 'ISRG Root X1', but no chain from the CA matched this issuer. Using the default certificate chain instead

Help
1

Hi There,

I Have install newer version of certbot and, getting subjected error despite that certificate is being generated and over browser can be seen root cert is expiring on 2035 along with R3 intermediate cert(expiry 2025) signed by ISRG root.

linux# certbot certonly --server https://acme-staging-v02.api.letsencrypt.org/directory --agree-tos -m letsencrypt@xyz.com --dns-dnsmadeeasy --dns-dnsmadeeasy-credentials /etc/letsencrypt/creds/dnsmadeeasy.ini --dns-dnsmadeeasy-propagation-seconds 20 -d load.menu --test-cert --break-my-certs --preferred-chain "ISRG Root X1"
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Certificate not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/load.menu-0005.conf)

What would you like to do?

1: Keep the existing certificate for now
2: Renew & replace the certificate (may be subject to CA rate limits)

Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate for load.menu
Certbot has been configured to prefer certificate chains with issuer 'ISRG Root X1', but no chain from the CA matched this issuer. Using the default certificate chain instead.

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/load.menu-0005/fullchain.pem
Key is saved at: /etc/letsencrypt/live/load.menu-0005/privkey.pem
This certificate expires on 2022-04-08.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

However, I still seeing, cert is supposed to expire in 2025 instead of 2035.
here, what I'm getting in command output instead of this>>https://letsencrypt.org/certs/isrgrootx1.txt

linuxhost# openssl x509 -in /etc/letsencrypt/live/load.menu-0004/chain.pem -text -noout

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
91:2b:08:4a:cf:0c:18:a7:53:f6:d6:2e:25:a7:5f:5a
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
Validity
Not Before: Sep 4 00:00:00 2020 GMT
Not After : Sep 15 16:00:00 2025 GMT
Subject: C = US, O = Let's Encrypt, CN = R3
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:bb:02:15:28:cc:f6:a0:94:d3:0f:12:ec:8d:55:
92:c3:f8:82:f1:99:a6:7a:42:88:a7:5d:26:aa:b5:
2b:b9:c5:4c:b1:af:8e:6b:f9:75:c8:a3:d7:0f:47:
94:14:55:35:57:8c:9e:a8:a2:39:19:f5:82:3c:42:
a9:4e:6e:f5:3b:c3:2e:db:8d:c0:b0:5c:f3:59:38:
e7:ed:cf:69:f0:5a:0b:1b:be:c0:94:24:25:87:fa:
37:71:b3:13:e7:1c:ac:e1:9b:ef:db:e4:3b:45:52:
45:96:a9:c1:53:ce:34:c8:52:ee:b5:ae:ed:8f:de:
60:70:e2:a5:54:ab:b6:6d:0e:97:a5:40:34:6b:2b:
d3:bc:66:eb:66:34:7c:fa:6b:8b:8f:57:29:99:f8:
30:17:5d:ba:72:6f:fb:81:c5:ad:d2:86:58:3d:17:
c7:e7:09:bb:f1:2b:f7:86:dc:c1:da:71:5d:d4:46:
e3:cc:ad:25:c1:88:bc:60:67:75:66:b3:f1:18:f7:
a2:5c:e6:53:ff:3a:88:b6:47:a5:ff:13:18:ea:98:
09:77:3f:9d:53:f9:cf:01:e5:f5:a6:70:17:14:af:
63:a4:ff:99:b3:93:9d:dc:53:a7:06:fe:48:85:1d:
a1:69:ae:25:75:bb:13:cc:52:03:f5:ed:51:a1:8b:
db:15
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Subject Key Identifier:
14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6
X509v3 Authority Key Identifier:
keyid:79:B4:59:E6:7B:B6:E5:E4:01:73:80:08:88:C8:1A:58:F6:E9:9B:6E

        Authority Information Access:
            CA Issuers - URI:http://x1.i.lencr.org/

        X509v3 CRL Distribution Points:

            Full Name:
              URI:http://x1.c.lencr.org/

        X509v3 Certificate Policies:
            Policy: 2.23.140.1.2.1
            Policy: 1.3.6.1.4.1.44947.1.1.1

Can anyone help me here please..

thanks..

1 Like
2

Also, in above comment >>Digital Signature, Certificate Sign, CRL Sign) can be seen in the below command output.
linuxhost# openssl x509 -in /etc/letsencrypt/live/load.menu-0004/chain.pem -text -noout

1 Like
3

I'm sorry, but what exactly is the issue? You're using the staging server and Certbot is "complaining" about a root not being found. Which makes sense. Because.. Staging server.

5 Likes
4

That is the correct preferred-chain value for the production server. You have chosen the staging server to test (thanks) but the chain name is different.

I believe you could use --preferred-chain "Fake LE Root X2" for test server as noted here

Also, what version of certbot do you have? Some versions had a bug (not causing problem with staging but for after).

Do,

certbot --version

UPDATE: @salman I just realized the link which described the Fake LE Root was from 2020. I do not know if that will still work for staging server. Please let us know either way and about your certbot version.

6 Likes
5

Staging has a new chain, the root is now called "(STAGING) Pretend Pear X1", so it would be

--preferred-chain "(STAGING) Pretend Pear X1"
7 Likes
6

@MikeMcQ I used "Fake LE Root X2" as preferred chain still seeing same error and I'm having certbot version 1.22.0

2 Likes
7

Please see @MikeMcQ 's edit and the post of @Nummer378.

Also, please elaborate on what you're trying to accomplish here exactly.

6 Likes
8

I'm getting the error preferred chain not found, Certbot has been configured to prefer certificate chains with issuer 'ISRG Root X1', but no chain from the CA matched this issuer. Using the default certificate chain instead.

And second why I'm getting certificate is expiring 2025(Not Before: Sep 4 00:00:00 2020 GMT & Not After : Sep 15 16:00:00 2025 GMT along with Digital Signature, Certificate Sign, CRL Sign) while I should be getting 2035(https://letsencrypt.org/certs/isrgrootx1.txt) since using "ISRG Root X1"

1 Like
9

Why are you using the staging server and combining that with values to options for and expecting results from the production server?

You're even using the --break-my-certs option, which is sort of "proof" you're understanding what you're doing.. However, I'm very much doubting that?

7 Likes
10

@Nummer378, I don't see error by using preferred chain (STAGING) Pretend Pear X1)

And still seeing root cert expiry 2025 instead of 2035>>https://letsencrypt.org/certs/isrgrootx1.txt
linux# openssl x509 -in /etc/letsencrypt/live/load.menu-0004/chain.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
91:2b:08:4a:cf:0c:18:a7:53:f6:d6:2e:25:a7:5f:5a
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
Validity
Not Before: Sep 4 00:00:00 2020 GMT
Not After : Sep 15 16:00:00 2025 GMT
Subject: C = US, O = Let's Encrypt, CN = R3
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:bb:02:15:28:cc:f6:a0:94:d3:0f:12:ec:8d:55:
92:c3:f8:82:f1:99:a6:7a:42:88:a7:5d:26:aa:b5:
2b:b9:c5:4c:b1:af:8e:6b:f9:75:c8:a3:d7:0f:47:
94:14:55:35:57:8c:9e:a8:a2:39:19:f5:82:3c:42:
a9:4e:6e:f5:3b:c3:2e:db:8d:c0:b0:5c:f3:59:38:
e7:ed:cf:69:f0:5a:0b:1b:be:c0:94:24:25:87:fa:
37:71:b3:13:e7:1c:ac:e1:9b:ef:db:e4:3b:45:52:
45:96:a9:c1:53:ce:34:c8:52:ee:b5:ae:ed:8f:de:
60:70:e2:a5:54:ab:b6:6d:0e:97:a5:40:34:6b:2b:
d3:bc:66:eb:66:34:7c:fa:6b:8b:8f:57:29:99:f8:
30:17:5d:ba:72:6f:fb:81:c5:ad:d2:86:58:3d:17:
c7:e7:09:bb:f1:2b:f7:86:dc:c1:da:71:5d:d4:46:
e3:cc:ad:25:c1:88:bc:60:67:75:66:b3:f1:18:f7:
a2:5c:e6:53:ff:3a:88:b6:47:a5:ff:13:18:ea:98:
09:77:3f:9d:53:f9:cf:01:e5:f5:a6:70:17:14:af:
63:a4:ff:99:b3:93:9d:dc:53:a7:06:fe:48:85:1d:
a1:69:ae:25:75:bb:13:cc:52:03:f5:ed:51:a1:8b:
db:15
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Subject Key Identifier:
14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6
X509v3 Authority Key Identifier:
keyid:79:B4:59:E6:7B:B6:E5:E4:01:73:80:08:88:C8:1A:58:F6:E9:9B:6E

        Authority Information Access:
            CA Issuers - URI:http://x1.i.lencr.org/

        X509v3 CRL Distribution Points:

            Full Name:
              URI:http://x1.c.lencr.org/

        X509v3 Certificate Policies:
            Policy: 2.23.140.1.2.1
            Policy: 1.3.6.1.4.1.44947.1.1.1

Signature Algorithm: sha256WithRSAEncryption
     85:ca:4e:47:3e:a3:f7:85:44:85:bc:d5:67:78:b2:98:63:ad:
     75:4d:1e:96:3d:33:65:72:54:2d:81:a0:ea:c3:ed:f8:20:bf:

what does it mean about Digital Signature, Certificate Sign, CRL Sign in above command output.

1 Like
11

You're checking the intermediate certificate, not the root certificate. So it makes sense you're not getting the same dates.

Those are the "usages" the R3 intermediate certificate is purposed for. See for more info RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

4 Likes
12

Could you please let me know the correct syntax here what I should be using for staging.

thanks

1 Like
13

How do you mean "for staging"? The correct syntax for what exactly? I'm still not clear what you're trying to accomplish.

Looking at the "0004" and "0005" in the outputs of your posts you're issuing a lot of certificates.. It seems to me you have absolutely no clue what so ever what you're doing. Please elaborate more about the GOAL you're trying to achieve so we can help you better.

By the way, no judgement here, it's fine to have no clue what so ever, but please, explain what you're trying to do and why.. Let us guide you if we can.

5 Likes
14

Hey @Osiris never mind,

I was wondering why my preferred chain is not matched that is resolved now.

And, why I'm seeing expiry 2025 instead of 2035 while I'm using ISRG Root X1.
in this command(openssl x509 -in /etc/letsencrypt/live/load.menu-0005/chain.pem -text -noout) output.

but as you said I'm checking intermediate certificate. so can you guide me how to check root certificate please(I might be asking invalid question not sure so apologize)

2 Likes
15

And, what is the fix to avoid using the intermediated R3 certificate.

1 Like
16

There's nothing to avoid. The intermediate is part of the chain of trust.

What is it you want to check exactly?

5 Likes
17

I was expecting that I should be getting exactly this output as it is on this url https://letsencrypt.org/certs/isrgrootx1.txt from this command**(linux# openssl x509 -in /etc/letsencrypt/live/load.menu-0005/chain.pem -text -noout)** output. since R3 is the part of this chain, so it will show 2025

linux# openssl x509 -in /etc/letsencrypt/live/load.menu-0005/chain.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
4d:f4:2b:95:d1:ee:9b:3a:4c:2e:b3:3b:8d:10:5d:d6
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1
Validity
Not Before: Sep 4 00:00:00 2020 GMT
Not After : Sep 15 16:00:00 2025 GMT
Subject: C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot R3
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:bb:a4:d1:f3:ee:f8:6f:8e:a6:38:4d:45:53:00:

2 Likes
18

Ah. They will not match even if you were using the production server.

ISRG Root X1 is a root which resides in your system's trust store.

The chain you are looking at is sent from a server to a client along with the "leaf" (cert.pem). The client (browser ...) looks at the leaf and chain from the server to see if it leads to a root it trusts. If so, the connection is considered secure.

If you let us know which oper sys and version you are using we could describe how to find that root on your system.

5 Likes
19

I'm using Ubuntu "20.04.3 LTS (Focal Fossa)"

2 Likes
20

I want to highlight that you do not send the root certs to the client. It makes no sense as if they trusted what you sent them there would be no point to certs. The trusted root store on your system is important to remain secure.

That said, for Ubuntu:

All the trusted roots are in a single (bundle) file here. This bundle is used by clients like curl, wget, and certbot when verifying ssl connections to other systems.

/etc/ssl/certs/ca-certificates.crt

We often instruct people to do something like this to see if they have a certain one:

grep -Ei 'ISRG Root|Daddy' /etc/ssl/certs/ca-certificates.crt

See this for Ubuntu details

6 Likes