ECDSA chain (YE2→Root YE→ISRG Root X2) shown as untrusted on some iOS/Safari clients — Generation Y rollout question

Help
1

Hi,
We run geekonai.ru (own VPS, nginx + certbot 2.9.0). Since the switch to the Generation Y hierarchy, our served certificate chain is:
leaf (ECDSA) → Let's Encrypt YE2 → ISRG Root YE → ISRG Root X2
openssl s_client -connect geekonai.ru:443 -showcerts verifies this chain with return code 0, but a portion of our visitors on iPhones report “This Connection Is Not Private” warnings in Safari.
Questions:

  1. Is there a known timeline for Apple adding ISRG Root YE to its trust store, or should the X2 cross-sign already in our chain cover any device that trusts X2 (added around iOS 16)? If so, any idea why some iPhones still reject it?
  2. Is there a way to request the full fallback chain through ISRG Root X1 instead of X2 for broader legacy compatibility? When we reissued with --key-type rsa, the chain came back as leaf → YR1 → Root YR with no X1 cross-sign at all, even with --preferred-chain "ISRG Root X1".
  3. Separately — we noticed LE-SA v1.7 names .RU/.SU TLDs regarding sanctions compliance. Our domain continues to issue/renew successfully as of today (Oct 15, 2026). Is this expected to keep working, or should we plan a migration to another CA preemptively?

Happy to share the full -showcerts output if useful.

Thanks!

My domain is:

I ran this command:
certbot certonly --nginx --cert-name geekonai.ru -d geekonai.ru -d www.geekonai.ru --key-type ecdsa --force-renewal --non-interactive

It produced this output:
Successfully received certificate.
Chain served: leaf (ECDSA) → Let's Encrypt YE2 → ISRG Root YE → ISRG Root X2
(verified via openssl s_client -connect geekonai.ru:443 -showcerts, Verify return code: 0 (ok))

My web server is (include version):
nginx/1.24.0 (Ubuntu)

The operating system my web server runs on is (include version):
Ubuntu 24.04.4 LTS

My hosting provider, if applicable, is:
Self-managed VPS

I can login to a root shell on my machine (yes or no, or I don't know):
Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 2.9.0

2

It looks to me like the chain goes all the way back to being signed by X1 (which might be what you were trying to say). This is the default and most compatible chain.

Certificate chain
 0 s:CN=geekonai.ru
   i:C=US, O=Let's Encrypt, CN=YE2
   a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA384
   v:NotBefore: Oct 15 07:40:52 2026 GMT; NotAfter: Jan 13 07:40:51 2027 GMT
 1 s:C=US, O=Let's Encrypt, CN=YE2
   i:C=US, O=ISRG, CN=Root YE
   a:PKEY: EC, (secp384r1); sigalg: ecdsa-with-SHA384
   v:NotBefore: Sep  3 00:00:00 2025 GMT; NotAfter: Sep  2 23:59:59 2028 GMT
 2 s:C=US, O=ISRG, CN=Root YE
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X2
   a:PKEY: EC, (secp384r1); sigalg: ecdsa-with-SHA384
   v:NotBefore: May 13 00:00:00 2026 GMT; NotAfter: Sep  2 23:59:59 2032 GMT
 3 s:C=US, O=Internet Security Research Group, CN=ISRG Root X2
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: EC, (secp384r1); sigalg: sha256WithRSAEncryption
   v:NotBefore: May 13 00:00:00 2026 GMT; NotAfter: Sep  2 23:59:59 2032 GMT

I don't think there is, but X2 or X1 in the trust store should be enough. I think you'd need more details about what the devices that reject it are seeing.

I don't understand the question; it looks like you're already using a chain through Root X1, and that's the default.

I'm not sure where you saw anything specific to ru or su domains; I don't think Let's Encrypt has anything specific to those. Any organization sanctioned by the US Government can't get a certificate from Let's Encrypt, but that's specific to the organization and not related to the TLD in use. In general, I recommend using multiple CAs just so that it's easier to deal with problems specific to a single CA, especially as lifetimes continue to get shorter. But you should be able to continue using Let's Encrypt as one of them unless the US Government objects to your existence.

3

There must be something wrong with how you view your chains.

Your ECC chain is (currently) leaf <= YE2 <= Root YE <= Root X2 <= Root X1
(the final X2-by-X1 cross-sign is optional, you can have a chain terminated at either X2 or X1)

Every current RSA chain is leaf <= YRn <= Root YR <= Root X1, with no other chains available at the moment.

Since you are not seeing the last cross-sig in either chain, this suggests an error in how you're looking at it. :slight_smile:

And as all default chains terminate on Root X1, both before and after the introduction of YE/YR, there should be no difference in client compatibility...

4

And to clarify: no chains ending in Root YR or Root YE are available at this moment, since they're not yet trusted by any client. So you should just think of them as extra intermediates for now.

5

Technically they are available as alternate chains they just don't produce a trusted connection unless you manually install those roots in all your clients. See: Chains of Trust - Let's Encrypt

6

Oops, you're right, I wasn't aware of this. Thanks!