Join us and learn about certificate chains!

Thank you! I mostly wondered whether using the E1 chain, which we are evaluating in production, is just as viable of a solution to the DST Root expiration issue, as this alternative does not seem to having been mentioned. Or is it not deemed ready to fully replace R3 yet?


E1 and R3 have "parallel issuance" that depends upon the type of key (ECDSA or RSA, respectively) in the certificate signing request (CSR) for a leaf/end-entity certificate. Currently your ACME account must be on an allow list to receive ECDSA certificates signed by E1. If it's not on the allow list, your submitted CSR with an ECDSA key will result in a certificate signed by R3.

See @Nummer378's excellent explanation below for more information:


There's a recording. Chat's still live.


wonder android got any better with root certificate store update: are they still tied to major OS version?


Not sure, but a great question. Hopefully someone around here will have some good information.


The E1 chain is just some intermediate(s) terminating at either ISRG Root X2 or ISRG Root X1.

Compatibility-wise, it is no better or worse than requesting the current R3 alternate chain (terminating at ISRG Root X1).

E1 will never replace R3, because they use different algorithms. R3 is RSA, while E1 is ECDSA. E1 is exclusively for ECDSA leafs, while R3 will in the future be exclusively for RSA leafs.

The only thing that will change is the current option of obtaining an ECDSA leaf signed by R3 (which will be removed at some point).


Given the fact that ISRG Root X2 is cross signed by X1, this is currently not a requirement and won't be for many years to come.

It will only be a requirement in the future if you want to shorten your chain and stop serving the cross-sign. But I see that as a very distant action, given how long it takes for new roots to be widely adopted.


You got me there, @Nummer378, and you're exactly right.



From my limited Android knowledge, yes. Since Google started standardizing the OS trust store variances between device vendors reduced, but updates are still tied to OS upgrades.

For outdated phones, Google seems to be relying on apps specifying their own roots, which are local per-app. The option to install user-defined root CAs gets more restricted on every update.


Thank you very much for elaborating! That was insightful.

I originally thought ECDSA intermediates were to replace the RSA ones at some far point in the future.


They could, but I suspect not for some significant time to come.

1 Like

If all else fails, there are always the valid, but unwanted, options:

  • Sign an ECDSA intermediate with an RSA root
  • Sign an RSA intermediate with an ECDSA root
1 Like

was it recorded ?


Yes, it was recorded.


Any idea when the recording will be released?

Can the chats be included?



Unfortunately the chats are not recorded in the video, I'll look to see if there's a way to do this with Hopin for the next time!


I just realized I never addressed the lack of "ECDSA vs RSA"

We could do an event around this when ECDSA is available in production whenever you request a cert with an ECDSA-signed key (instead of allowlisted); but I wonder if we do a whole event around this if it will be more than a 10-minute "here's what ECDSA is, here are the benefits" event... also I'm not sure that would be BAD to be so short, but it's a pretty cut and dry thing! Let me know if you would be interested in seeing that!

Since there was a lot to talk about with the expiration, we decided to keep this event focused only on that. And oof, that video is FULL of great information about that! Thanks again to the incredible chat and the awesome questions. I hope we can keep doing events like this!



This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.