Questions re: Production ECDSA allow-list

We've posted an announcement about the availability and usage of the ECDSA hierarchy in production:

If you have any questions or concerns, feel free to put them here!


So excited, going to fill out the form now! Already did test runs in staging weeks ago :slight_smile:


I am not sure whether this is the right place to ask.

In the ECDAS allowlist request form, it asked ACME account ID.

From the doc here (Finding Account IDs - Let's Encrypt), it said that the account ID is a URL of the form like:

I am using script to obtain certificate. I have the links as follows:****/939899**********

How can I get the account ID?



For, the account url can be found in this file:

Where is the folder where is installed (often ~/


Thank you so much. found that.


:wave: The announcement says:

If you would like your account to be allow-listed for ECDSA issuance in Production, please fill out this form:

We'll be processing allow-list requests in batches, most of which will go out Thursday with our normal Production updates.

Will you be sending a message to the contact address of accounts that are added to the production update list or should we expect the change will happen at some point without notification?



You don't have an official Let's Encrypt issued crystal ball, @cpu? :astonished:


1 Like

We are sending out confirmation notifications after the list is updated to the address provided in the form. There are a few wrinkles in the process that we're working to smooth out so this week's update is a little behind. We'll be improving it over the next week so there is less guessing involved.


My auto renewal got me my first E1-issued cert today, but haven't got any email confirmation [yet]. You're probably still tuning knobs, right?


I laso didnt get any confirmation email yet, however since it was said allow list gets updated after maintenance i just tried to issue new cert from E1 on thursday, couple of hours after maintenance and it was already working.


I also got upgraded to ECDSA chain without receiving any e-mail confirmation.

Anyway, my question is: would it be possible to provide alternate chain that would extend the current chain with the ISRG Root X1 certificate cross-signed by DST Root CA X3? This would help in minor cases where ISRG Root X1 is still not in trust chain. So the chain would be on par with current default RSA chain.


Awesome, thanks for confirming!


I feel like this is a very valid concern. While ECDSA certificates are respectively new, I don't think it's reasonable to assume that the set of devices that support ECDSA certificates is a subset of the set of devices that trust ISRG Root X1.

1 Like

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