How do I get the shortest ISRG Root X2 ECDSA chain now

According to the announcement the shortest X2 chain should be available now. How do I get it now without the X1 chain, I am already on the production allow list and using it since it started in 2021.

Currently this is what I use to get X2 cert.

acme.sh --issue ... --keylength ec-256 --server letsencrypt

I believe with the option --preferred-chain "ISRG Root X2"

See acme.sh docs (link here)

chain as described here

I saw that this chain option was going to production Aug9 but I don't know what time zone. In my time zone it is still Aug8

Did you try the alternate chain in the staging system (STAGING) Bogus Broccoli X2 ?

5 Likes

I just looked at my most recent ECDSA certificates, and I don't see any alternate chain option as of now.

I also do not expect that: Most Let's Encrypt engineers are somewhere in between Pacific and Eastern time, so even if the deployment happens today it will take some more hours. I would advise to just be patient and look for an announcment in the appropiate thread: Root X2 alternate chain for ECDSA opt-in accounts

In staging the alternate chain is already available, as mentioned by @MikeMcQ. If you want to experiment now, do it there.

5 Likes

I tried using --preferred-chain "ISRG Root X2" but I am still getting a certificate with X1 cain

1 Like

I'm putting the change out this morning. We usually operate on business hours around GMT-7.

6 Likes

Just wanted to make sure is --preferred-chain "ISRG Root X2" the correct command to get X2 only chain?

2 Likes

That is the addition to the command that I would expect will work, but I don't know as anybody has tested yet. :slight_smile:

4 Likes

It's working now. Note how my chain3.pem is about half the size of the older chains:

root@uk2:/etc/letsencrypt/archive/other# ls -l
total 48
-rw-r--r-- 1 root root 1424 Aug  3 23:26 cert1.pem
-rw-r--r-- 1 root root 1363 Aug  7 12:16 cert2.pem
-rw-r--r-- 1 root root 1359 Aug  9 11:21 cert3.pem
-rw-r--r-- 1 root root 2599 Aug  3 23:26 chain1.pem
-rw-r--r-- 1 root root 2599 Aug  7 12:16 chain2.pem
-rw-r--r-- 1 root root 1021 Aug  9 11:21 chain3.pem
-rw-r--r-- 1 root root 4023 Aug  3 23:26 fullchain1.pem
-rw-r--r-- 1 root root 3962 Aug  7 12:16 fullchain2.pem
-rw-r--r-- 1 root root 2380 Aug  9 11:21 fullchain3.pem
-rw------- 1 root root  306 Aug  3 23:26 privkey1.pem
-rw------- 1 root root  306 Aug  7 12:16 privkey2.pem
-rw------- 1 root root  306 Aug  9 11:21 privkey3.pem
root@uk2:/etc/letsencrypt/archive/other#

Decoding the chain3.pem shows that it only contains the E1 certificate (signed by X2):

The X2 certificate signed by X1 has been removed.

(this is using --key-type ecdsa --preferred-chain "ISRG Root X2" obviously)

2 Likes

Here's the command I used to test it:

certbot --config "${X2_CFG}" certonly --domains valid-isrgrootx2.letsencrypt.org --preferred-chain="ISRG Root X2"

And here's the default API return:
https://acme-v02.api.letsencrypt.org/acme/cert/03700fa6ab0c0767e26c578708bd7064c8c2/0

and the alt return:
https://acme-v02.api.letsencrypt.org/acme/cert/03700fa6ab0c0767e26c578708bd7064c8c2/1

5 Likes

For some reason I cannot get acme.sh to get X2 only chain. I used --preferred-chain "ISRG Root X2" --keylength ec-256

1 Like

Your account needs to be opted in to the ECDSA issuer path, at present. See Root X2 alternate chain for ECDSA opt-in accounts.

4 Likes

I am already on that list.

1 Like

I'm unsure of the actual semantics of acme.sh for its implementation of --preferred-chain. Taking a quick look at https://github.com/acmesh-official/acme.sh/blob/0da839cce35f4ab014a6d62133fac03c8f4c6979/acme.sh#L5157, it appears that it'll try to match the issuer, but it's not clear to me that it's matching the most-trusted cert only. I'd have to stare a little harder / debug it.

I know initial implementations of this logic tended to match cross-signs, which would in this case catch the default chain and not the alternate. Anyway, we'd need debug logs and/or raising an issue against acme.sh about it. :confused:

4 Likes

Jup, AFAIK Certbot was buggy in that way too in the beginning, but it was (obviously) fixed quite soon :slight_smile:

1 Like

How are you checking the chain, my domain is iqbal.email

I use certbot not acme.sh so things are a little different but first thing I did was find the newly-generated chain.pem (or whatever it's called for you)

E1 certificates with the new short chain (X2) should have a 1021-byte chain.pem
E1 certificates with the default/long chain should have a 2599-byte chain.pem
R1 certificates with the short chain (X1) should have a 1826-byte chain.pem
R1 certificates with the default/long chain should be ???? (too lazy to check)

Once you've restarted your webserver with the new certificate, use the Dev version of the SSL labs scanner at SSL Server Test (Powered by Qualys SSL Labs) because the production site doesn't fully support the X2 chain yet.

It looks to me like you do have the short chain

see how the X2 certificate says "in trust store" instead of "sent by server"?

1 Like

I checked on the same website and this is what I got

|1|Sent by server|iqbal.email
Fingerprint SHA256: be985d92ba57cba8219ba9a8d5b1b6a4cdc94a90b53655b7b8110ddd9b2ff91c
Pin SHA256: yeLUjflH46uuDxnvWN2f52bwVX+3sJ8kbBbNza8bfAQ=
EC 256 bits / SHA384withECDSA|
| --- | --- |
|2|Sent by server|E1
Fingerprint SHA256: 46494e30379059df18be52124305e606fc59070e5b21076ce113954b60517cda
Pin SHA256: J2/oqMTsdhFWW/n85tys6b4yDBtb6idZayIEBx7QTxA=
EC 384 bits / SHA384withECDSA|
|3|Extra download|ISRG Root X2
Fingerprint SHA256: 8b05b68cc659e5ed0fcb38f2c942fbfd200e6f2ff9f85d63c6994ef5e0b02701
Pin SHA256: diGVwiVYbubAI3RW4hB9xU8e/CH2GnkuvVFZE8zmgzI=
EC 384 bits / SHA256withRSA|
|4|In trust store|ISRG Root X1 Self-signed
Fingerprint SHA256: 96bcec06264976f37460779acf28c5a7cfe8a3c0aae11a8ffcee05c0bddf08c6
Pin SHA256: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
RSA 4096 bits (e 65537) / SHA256withRSA|

Are you sure you're on dev.ssllabs.com and not the main site? Main site is out-of-date.

1 Like

Now the dev shows two paths

Path #1: Trusted
1 Sent by server iqbal.email
Fingerprint SHA256: be985d92ba57cba8219ba9a8d5b1b6a4cdc94a90b53655b7b8110ddd9b2ff91c
Pin SHA256: yeLUjflH46uuDxnvWN2f52bwVX+3sJ8kbBbNza8bfAQ=
EC 256 bits / SHA384withECDSA
2 Sent by server E1
Fingerprint SHA256: 46494e30379059df18be52124305e606fc59070e5b21076ce113954b60517cda
Pin SHA256: J2/oqMTsdhFWW/n85tys6b4yDBtb6idZayIEBx7QTxA=
EC 384 bits / SHA384withECDSA
3 In trust store ISRG Root X2 Self-signed
Fingerprint SHA256: 69729b8e15a86efc177a57afb7171dfc64add28c2fca8cf1507e34453ccb1470
Pin SHA256: diGVwiVYbubAI3RW4hB9xU8e/CH2GnkuvVFZE8zmgzI=
EC 384 bits / SHA384withECDSA

Path #2: Trusted
1 Sent by server iqbal.email
Fingerprint SHA256: be985d92ba57cba8219ba9a8d5b1b6a4cdc94a90b53655b7b8110ddd9b2ff91c
Pin SHA256: yeLUjflH46uuDxnvWN2f52bwVX+3sJ8kbBbNza8bfAQ=
EC 256 bits / SHA384withECDSA
2 Sent by server E1
Fingerprint SHA256: 46494e30379059df18be52124305e606fc59070e5b21076ce113954b60517cda
Pin SHA256: J2/oqMTsdhFWW/n85tys6b4yDBtb6idZayIEBx7QTxA=
EC 384 bits / SHA384withECDSA
3 Extra download ISRG Root X2
Fingerprint SHA256: 8b05b68cc659e5ed0fcb38f2c942fbfd200e6f2ff9f85d63c6994ef5e0b02701
Pin SHA256: diGVwiVYbubAI3RW4hB9xU8e/CH2GnkuvVFZE8zmgzI=
EC 384 bits / SHA256withRSA
4 In trust store ISRG Root X1 Self-signed
Fingerprint SHA256: 96bcec06264976f37460779acf28c5a7cfe8a3c0aae11a8ffcee05c0bddf08c6
Pin SHA256: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
RSA 4096 bits (e 65537) / SHA256withRSA

Do you know why the second path includes RSA "ISRG Root X1 Self-signed"?

Looks right to me:

❯ echo "" | openssl s_client -connect iqbal.email:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X2
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = E1
verify return:1
depth=0 CN = iqbal.email
verify return:1
---
Certificate chain
 0 s:CN = iqbal.email
   i:C = US, O = Let's Encrypt, CN = E1
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA384
   v:NotBefore: Aug  9 16:08:06 2023 GMT; NotAfter: Nov  7 16:08:05 2023 GMT
 1 s:C = US, O = Let's Encrypt, CN = E1
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X2
   a:PKEY: id-ecPublicKey, 384 (bit); sigalg: ecdsa-with-SHA384
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
---

4 Likes