This is possible, but not currently planned. ECDSA offers many benefits including fewer bytes per transaction so we're only offering the shortest, compatible chain for now.
I think that it's pretty close to being true though, in that I know somewhere somebody said that there were some old Android versions that couldn't handle the P-384 signatures that the Let's Encrypt ECDSA chain uses. For the most part, if you need compatibility with older systems then you should still use RSA certificates. And if you don't, then your systems are probably new enough to have the ISRG Root cert. And even if they aren't, having the chain all the way up to the DST Root may be long enough that you're not getting much of an advantage by switching to ECDSA anyway.
But regardless of the chains returned through the ACME endpoint, if one really want to go that route one could configure one's servers to send the really long leaf ← E1 ← ISRG Root X2 ← ISRG Root X1 ← DST Root CA X3 chain. You'd want to take care with your automation to handle well the case when the intermediate changes, but as long as you have your script or whatever just look for the chain ending in ISRG-Root-X2-signed-by-Root-X1 and append the Root-X1-signed-by-DST cert after it, I'd think it would be fairly resilient. Just using RSA certificates with the default ACME chain is probably a lot easier than setting all that up, though.
I agree, @petercooperjr. Aside from sending less bytes and any savings in processing, from a functional standpoint EC seems to me to be mostly about preference unless RSA were to be compromised or EC were to be proven strictly superior from a security standpoint. Barring the latter scenarios, there wouldn't really be a "need" to maximize support for EC.
I'd like to thank everyone for their patience while we work to update the ECDSA allow-list and send notifications on a timely schedule. We held back the last two boulder release tags because of errors found during our tests of those builds. As a result, our planned Thursday updates of the ECDSA allow-list got a little delayed. The allow-list is now up-to-date for all entries submitted through end-of-day on May 19th. If you don't recall when you submitted, e-mails will be sent soon and we apologize for delay.
Tomorrow, we will update the list again for all submissions from May 20th to end-of-day May 26th.
Yes, got the confirmation mail as well as my first E1-issued certificates, yay!
2 posts were split to a new topic: Apache chain issues with dual RSA/ECDSA certificates
Hi, will the ECDSA release list be updated this week?
Yes! The list was last updated on Friday, July 9th. The next update will be July 15th.
Is there a "public sample website" users can visit in order to check/verify that their clients accept the new production ECDSA certificate chain (the one from the staging environment won't do) without having to create a separate test account and to fill out the forementioned form?
The closest thing actually run by Let's Encrypt themselves is https://valid-isrgrootx2.letsencrypt.org/. However, that site is (intentionally) configured not to send the Root-X2-signed-by-Root-X1 certificate over the wire, so your client will only accept it if it's something like a web browser that already has that certificate in its cache (or has been manually configured to have Root X2 in its trust store directly).
Someone posted their E1 site here publically, so you might use that, though I believe it only has IPv6 connectivity so if you're using a backwards ISP that hasn't figured out how to do IPv6 yet then you might not be able to see it.
I personally have some E1 certificates but they're for things like my mail server and aren't really publicly accessible. AWS very recently announced support for ECDSA certificates in CloudFront, and I've been meaning to try it out, so maybe at some point I might put a little test site together. Don't hold your breath waiting for me, though, as I have plenty of other little side projects also on my list that I haven't gotten to yet.
And maybe there's something else out there that I'm not familiar with. Anyone feel like poking through the certificate transparency logs of everything signed by E1 and see if there's a good test site somewhere? It's hard to exclude all the
radiantlock.org certs that Let's Encrypt uses for testing but that aren't really public as far as I know.
For an IPv4 + IPv6 capable system, you can check out https://ecdsa-test.germancoding.com/ (Note that this is not official either)
It requires SNI though, but almost every TLS implementation does this nowadays. If you don't send SNI, you also get a valid cert, but with RSA key*.
Also note that the new ECDSA chain is just some intermediates terminating at ISRG Root X1 (ISRG Root X2 is considered an intermediate as of today, as it's not in root programs yet). Any client supporting ECDSA and trusting ISRG Root X1 should have no trouble with the chain. For ISRG Root X1, there is an official public test site (with RSA leafs and intermediates): https://valid-isrgrootx1.letsencrypt.org/
*If you do send SNI, but do not support ECDSA, you get an SSL/TLS handshake error (this is useful to check for ECDSA support). On my main pages I have an automatic RSA fallback, which is deliberately disabled on this test page.
Am I supposed to get a confirmation email when I have been accepted onto the allow-list for ecdsa cert issuance?
Yes, i got a confirmation email.
Usually yes, but you may be on the list even before you receive the email.
Okay, thanks, maybe it'll take a while before I get it.
Filled in the allow-list form last weeked and noticed today I was able to issue an ecdsa cert from E1.
Any (modern) Firefox will work. A Firefox concludes that this is trustworthy because it inherently knows X2 is signed by X1. When you download Firefox a complete set of such trust relationships for unconstrained intermediate CAs is included in the box. Mozilla policy requires CAs, such as Let's Encrypt to provide it with copies of such certificates whenever they issue them. Even the bare leaf certificate would work, Firefox will see that it has a valid signature from E1, and that's enough to work out that it's trustworthy.
You shouldn't configure your web sites this way, but some people do and Firefox works anyway.
I've reworked the test page to include some TLS data, to make it a bit more interesting. Would like to have a display too that shows if the connection actually used an ECDSA certificate*. Sadly I don't see an easy way to do this with current setup...
*This is rather easy on TLS 1.2, as one just needs to look at the signature algorithm in the cipher suite. TLS 1.3 doesn't have this anymore though, so it's not a viable solution anymore.
I submitted the form on Aug 17, 2021, but I haven’t received the email until now. Is this normal?
FWIW it's been 13 days between confirmation of my ID and pushing to production.
That's too bad
Hope to improve the process and increase transparency.