# Questions regarding "Shortening the Let's Encrypt Chain of Trust"

**URL:** <https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581>\
**Category:** Help\
**Created:** [July 10, 2023, 7:12pm UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581 "2023-07-10T19:12:24Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![webprofusion](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/webprofusion/32/85310_2.png) [@webprofusion](https://community.letsencrypt.org/u/webprofusion)\
**Post date:** [July 19, 2023, 4:45am UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/21 "2023-07-19T04:45:59Z")

</div>

> [@dinakozlov](#):
>
> How can we request the longer chain?

Although you _can_ request the longer chain you should consider whether this approach (actively extending a legacy dependency which has a known impending expiry/failure) is a potential risk to your business continuity.

If you have a serious known dependency on the long chain you need to start to fix that now, because it's going away in less than a year. If you don't have a serious dependency on the long chain then consider changing now to test your assumptions and quantify the impact. If you don't know, then you need to find out.

---

<div class="post-metadata">

**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\
**Post date:** [July 19, 2023, 5:08am UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/22 "2023-07-19T05:08:09Z")

</div>

> [@webprofusion](#):
>
> If you have a serious known dependency on the long chain you need to start to fix that now, because it's going away in less than a year.

Further to that point, while Let's Encrypt community members will probably not routinely specifically recommend a different ACME CA, _if you happen to have a particular client base or device/application that has trouble_ as a result of the upcoming expiration event, it might be that Let's Encrypt won't be an appropriate CA for your needs after that event, in which case you may want to have a plan to switch to a different CA.

There are fortunately now several ACME CAs that provide services somewhat similar to Let's Encrypt's and that are compatible with the same clients. This was a hope and a goal of the people who created the Let's Encrypt project, and it seems to be working out. The switching costs are relatively low, although no other CA's offerings are exactly identical to Let's Encrypt's. While the ISRG roots are now widely supported and the vast majority of Let's Encrypt users will probably not see any major loss of compatibility after the upcoming expiration events, those who decide it's a particular problem for them will also have other options—and that's a great testament to the technology that the Let's Encrypt community has created. 🙂

---

<div class="post-metadata">

**Author:** ![saudiqbal](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/saudiqbal/32/76117_2.png) [@saudiqbal](https://community.letsencrypt.org/u/saudiqbal)\
**Post date:** [July 21, 2023, 5:03am UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/23 "2023-07-21T05:03:18Z")

</div>

What about the even shorter ECDSA chain X2? without the X1 chain, is this possible?

---

<div class="post-metadata">

**Author:** ![mcpherrinm](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mcpherrinm/32/59604_2.png) [@mcpherrinm](https://community.letsencrypt.org/u/mcpherrinm)\
**Post date:** [July 21, 2023, 5:59am UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/24 "2023-07-21T05:59:03Z")

</div>

We are still only signing with X2-based chains via an opt-in list due to the lower compatibility of that root, but that is an option available today.

---

<div class="post-metadata">

**Author:** ![orangepizza](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/orangepizza/32/19597_2.png) [@orangepizza](https://community.letsencrypt.org/u/orangepizza)\
**Post date:** [July 21, 2023, 6:00am UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/25 "2023-07-21T06:00:07Z")

</div>

well you could if you were in whitelist as even newest Android released doesn't support it (only 14 beta does)

---

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [July 21, 2023, 6:04am UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/26 "2023-07-21T06:04:01Z")

</div>

But Boulder only serves a X2 chain cross-signed by X1, right? As far as I know (but can be incorrect here) it doesn't offer an alternative chain with the self-signed X2?

It's not too difficult to manually set a chain with self-signed X2 though.

---

<div class="post-metadata">

**Author:** ![mcpherrinm](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mcpherrinm/32/59604_2.png) [@mcpherrinm](https://community.letsencrypt.org/u/mcpherrinm)\
**Post date:** [July 21, 2023, 4:55pm UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/27 "2023-07-21T16:55:37Z")

</div>

I thought we did! Turns out we don't. I'll add that.

---

<div class="post-metadata">

**Author:** ![petercooperjr](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/petercooperjr/32/84698_2.png) [@petercooperjr](https://community.letsencrypt.org/u/petercooperjr)\
**Post date:** [July 21, 2023, 4:57pm UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/28 "2023-07-21T16:57:50Z")

</div>

If you're going to start offering an alternate chain for Root X2 not signed by Root X1, I'd recommend keeping it, its timing, and its messaging completely separate from the messaging discussed here of the "regular" chain changes.

---

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [July 21, 2023, 5:16pm UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/29 "2023-07-21T17:16:33Z")

</div>

In my memory, this was a concious choice due to the fact that X2 wasn't accepted in most root programs. According to [ISRG Root X2 Submitted to Root Programs - #46 by Nummer378](https://community.letsencrypt.org/t/isrg-root-x2-submitted-to-root-programs/149385/46) however, this is currently not longer the case. Might be a good idea to update [Certificate Compatibility - Let's Encrypt](https://letsencrypt.org/docs/certificate-compatibility/) perhaps? 🙂

---

<div class="post-metadata">

**Author:** ![saudiqbal](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/saudiqbal/32/76117_2.png) [@saudiqbal](https://community.letsencrypt.org/u/saudiqbal)\
**Post date:** [July 24, 2023, 1:47pm UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/30 "2023-07-24T13:47:38Z")

</div>

So it will be possible to request a pure X2 chain soon?

---

<div class="post-metadata">

**Author:** ![dnowakowski](https://avatars.discourse-cdn.com/v4/letter/d/ba8739/32.png) [@dnowakowski](https://community.letsencrypt.org/u/dnowakowski)\
**Post date:** [July 31, 2023, 7:40am UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/31 "2023-07-31T07:40:27Z")

</div>

What will be root certificates used after the change in prod and staging? Will they change from what Let's Encrypt uses now?

---

<div class="post-metadata">

**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\
**Post date:** [July 31, 2023, 7:49am UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/32 "2023-07-31T07:49:03Z")

</div>

@dnowakowski  
Basically, the cross-signed path will no longer be used.

---

<div class="post-metadata">

**Author:** ![dnowakowski](https://avatars.discourse-cdn.com/v4/letter/d/ba8739/32.png) [@dnowakowski](https://community.letsencrypt.org/u/dnowakowski)\
**Post date:** [July 31, 2023, 7:55am UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/33 "2023-07-31T07:55:36Z")

</div>

Thanks, @rg305. What is the equivalent of "ISRG Root X1" in staging? Is it "(STAGING) Pretend Pear X1"?

---

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [July 31, 2023, 8:15am UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/34 "2023-07-31T08:15:35Z")

</div>

Yes, while the names are completely fictional and different, the suffixes like "X1" represents the corresponding "production" certificate.

You can read (a little bit) more about the staging certificate hierarchy at [Staging Environment - Let's Encrypt](https://letsencrypt.org/docs/staging-environment/#staging-certificate-hierarchy). While not named in that document, there also exists a "X3" root cert in production corresponding to the now-expired DST Root CA X3 root cert.

---

<div class="post-metadata">

**Author:** ![saudiqbal](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/saudiqbal/32/76117_2.png) [@saudiqbal](https://community.letsencrypt.org/u/saudiqbal)\
**Post date:** [August 1, 2023, 2:44am UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/35 "2023-08-01T02:44:08Z")

</div>

Any news on ISRG Root X2 certificate only. Can I request a ECDSA only chain soon?

---

<div class="post-metadata">

**Author:** ![webprofusion](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/webprofusion/32/85310_2.png) [@webprofusion](https://community.letsencrypt.org/u/webprofusion)\
**Post date:** [August 1, 2023, 7:40am UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/36 "2023-08-01T07:40:20Z")

</div>

> [@saudiqbal](#):
>
> Can I request a ECDSA only chain soon?

As far as I know you can do that now, as long as your account is on the allow list: [Chain of Trust - Let's Encrypt](https://letsencrypt.org/certificates/)

---

<div class="post-metadata">

**Author:** ![saudiqbal](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/saudiqbal/32/76117_2.png) [@saudiqbal](https://community.letsencrypt.org/u/saudiqbal)\
**Post date:** [August 1, 2023, 3:54pm UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/37 "2023-08-01T15:54:54Z")

</div>

I am already on that list but I can see it is signed by ISRG Root X1 \> ISRG Root X2 \> E1 \> domain. com

just wanted to see if I can request an even small chain starting from X2.

---

<div class="post-metadata">

**Author:** ![petercooperjr](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/petercooperjr/32/84698_2.png) [@petercooperjr](https://community.letsencrypt.org/u/petercooperjr)\
**Post date:** [August 1, 2023, 4:03pm UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/38 "2023-08-01T16:03:08Z")

</div>

They're not offering it yet, but they may offer it as an "alternate" at some point (not related to the topic of this thread about changes to the default chain for certificates signed by R3).

You can configure your server to remove the last certificate in the chain if you don't want it to send the X2-signed-by-X1, and any client that has X2 trusted will be fine with it. There's just no way yet to have your ACME client create that chain file itself automatically.

---

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [August 1, 2023, 4:22pm UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/39 "2023-08-01T16:22:11Z")

</div>

> [@petercooperjr](#):
>
> You can configure your server to remove the last certificate in the chain if you don't want it to send the X2-signed-by-X1 (…)

I'd recommend to check the certificate due for removal _first_ if it's really the cross-signed X2 cert. Because if you'd hardcode simply removing the last cert of the chain, then OP will get in trouble if the default chain changes to the short chain.

---

<div class="post-metadata">

**Author:** ![catharsis](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/catharsis/32/48964_2.png) [@catharsis](https://community.letsencrypt.org/u/catharsis)\
**Post date:** [August 1, 2023, 8:19pm UTC](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581/40 "2023-08-01T20:19:55Z")

</div>

I currently use two certificates per server, one RSA and one DSA, using certbot

certificate 1:

```plaintext
[renewalparams]
account = XXX
key_type = ecdsa
elliptic_curve = secp384r1
must_staple = True
authenticator = dns-cloudflare
dns_cloudflare_credentials = /root/cloudflare.ini
server = https://acme-v02.api.letsencrypt.org/directory
preferred_chain = ISRG Root X2
dns_cloudflare_propagation_seconds = 180

```

certificate 2:

```plaintext
[renewalparams]
account = XXX
rsa_key_size = 4096
must_staple = True
authenticator = dns-cloudflare
dns_cloudflare_credentials = /root/cloudflare.ini
server = https://acme-v02.api.letsencrypt.org/directory
key_type = rsa
preferred_chain = ISRG Root X1
dns_cloudflare_propagation_seconds = 180

```

I want to make sure I'm understanding correctly... since my RSA certificate is already using `preferred_chain = ISRG Root X1`, nothing will change for me on February 8th? After February 8th, should I remove the `preferred_chain` (since it'll no longer be doing anything at that point) or leave it in place? Or does it matter?

And nothing will change with my DSA certificate, right?

And a more general question, is there a way to query what "preferred\_chain" options an ACME server supports?

[Previous page](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581.md?page=1)

[Next page](https://community.letsencrypt.org/t/questions-regarding-shortening-the-lets-encrypt-chain-of-trust/201581.md?page=3)
