I want to let people know that we have submitted ISRG Root X2 (our new ECDSA root) to the Microsoft, Apple, Google, Mozilla, and Oracle root programs for inclusion.
This is the first step towards direct trust of our new root. We will let people know when root programs approve inclusion.
Note that ISRG Root X2 is already widely trusted via a cross-sign from our ISRG Root X1. The advantage of direct inclusion in the root programs is a shorter certificate chain and no dependency on other roots.
Great to hear this magnificent step!
When can we expect to get certs using X2?
Per the Chain of Trust page,
We have also issued a new ECDSA intermediate (“E1”) and started issuing from it for internal testing. In April 2021, we will make ECDSA issuance pubicly available with an account based allow-list. This page will be updated soon on how get an account on the allow-list.
So, it'll be Soon™.
Though "pubicly" is an unfortunate typo.
If anybody's interested in seeing Mozilla's process at adding this, looks like it's being tracked at 1701317 - ISRG Root X2 inclusion request
I don't think other root programs give public status of inclusion requests in the same way, though.
Shoot, looks like you were slightly faster than I was at getting that pull request in. 
I spotted the typo as soon as you quoted it. 
Is ISRG Root X1 will still be included in the future with X2 because it is an RSA cert, I thought X2 is completely ECDSA only certificate.
From my understanding, it is necessary to include ISRG Root X1 (as the cross-signing root) in the ECDSA chain with ISRG Root X2 for the time being (despite ISRG Root X1 being an RSA certificate itself) in order to ensure immediate trust in ISRG Root X2.
If the other participant trusts X2, then X1 doesn't matter for these certificates. But, most people in this community provide services to either everybody or at least to general users who would just be trusting whatever roots their operating system, browser or other software trusts. This thread is about the (likely multi-year) process by which Let's Encrypt gets those operating systems, browsers and other software to trust X2. Until that happens to a degree that's satisfactory for you, the chain to X1 needs to be there or else these systems have no reason to trust your certificate.
From a totally selfish local point of view, having ECDSA end entity certificates already means your server doesn't need to do RSA, the chain is just a bunch of bytes which needn't be interpreted locally.
In web browsers and other modern sophisticated software, as trust in X2 becomes widespread (perhaps as soon as next year I think) these clients don't need to do RSA any more because they can conclude X2 is trustworthy despite being sent the longer chain. So for them the X2->X1 chain link is just a few hundred bytes on the wire extra wasted.
Eliminating that last waste is a compromise between the wasted bytes sent (a very tiny but real cost) and the inconvenience of older systems not trusting a system unless it chains back to X1. That cheap Android phone you bought in 2018 may never end trusting X2, so either your site just doesn't work with that phone or you'd need to keep delivering a longer chain.
It would be nice if the “compatibility” page on the website noted this, and was updated with status information as it becomes available.
thank you for running with my idea!
Hi
The ISRG Root X2 test page at https://valid-isrgrootx2.letsencrypt.org/ serves a chain including the X1-X2 cross-signed certificate, so it is not actually testing whether the browser/client trusts X2 – it is sufficient to trust X1.
@ghen That's incorrect. Did you check that in your browser? Because browsers can build their own chain, disregarding the intermediates send by the server.
If you check with openssl s_client -connect $host:$port you'd see:
Certificate chain
0 s:CN = valid-isrgrootx2.letsencrypt.org
i:C = US, O = Let's Encrypt, CN = E1
1 s:C = US, O = Let's Encrypt, CN = E1
i:C = US, O = Internet Security Research Group, CN = ISRG Root X
2
Which is the correct chain.
I'm sorry, you are right. I was suprised that my browser (not having X2 in its trust store, I checked) was able to access this page, and indeed it displays X1 at the end of the chain. I guess it already cached the X1-X2 cross-signed cert from another site, to be able to construct this chain...
openssl s_client indeed shows the chain anchoring on X2. Also curl indicates an unknown issuer.
Sorry for the noise.
In fact, I'd noticed that my browser didn't trust the valid-isrgrootx2 site, and then I went to my own site that I got an E1 certificate for, and then afterward my browser did trust the site. It just needed to have seen the X2-signed-by-X1 in the past and it remembered. (Firefox actually goes even further than most other browsers and outright preloads all intermediates and cross-signed roots from the CAs directly.)
I wasn't aware of that fact, thanks for sharing!
I have mixed feelings about such measure though... While it helps in this case, in general it just hides errors and "demotivates" website owners to be careful about their certificate chains.
Yes, this behavior has led to huge debugging problems over and over again on the forum, where site operators will say "it works for me and most of my users, but not for two of my users" or many variations of that.
Can somebody chime in on which EKUs Root X2 is being submitted to be enabled for in the Microsoft Root Program? It appears that Root X1 is only enabled for Server Authentication, which was a little surprising to me, so I'm wondering if Root X2 will also be Server Authentication only or if it would also be enabled for Client Authentication.
Thanks.