ECDSA returning X1 rather than X2 chain?

Hi there, my understanding (perhaps incorrectly) of Chain of Trust - Let's Encrypt is that if I apply for an ECDSA cert, I will get issued with one via X2/E1 trust chain. However when I try certbot with --key-type ecdsa, I get an ECDSA certificate but the chain is X1/R3.

I'm interested in ECDSA to reduce bandwidth requirements on SSL handshake so it would be great if it was possible to get a full ECDSA chain. Also I control the applications which will connect so I can include the X2 root cert there if compatibility is considered a problem. Is there some reason for this to be happening or is there some flag to certbot to produce a cert via the X2/E1 chain so I can trial it?




Welcome @mzealey

Did you also see this section about getting on the allow-listed accounts?


Ah I missed this, thank you.


Note that even once your ACME account is on the allowlist, the default chain that the ACME server will send includes three certificates: leaf-signed-by-E1, E1-signed-by-Root-X2, and Root-X2-signed-by-Root-X1. If you're controlling the clients and have Root X2 in their trust stores, and you are really trying to shrink your handshake bandwidth as much as possible, then your server shouldn't send that last certificate. However, there probably isn't an easy way with popular ACME clients to configure them to do so, so you might need to configure the file of intermediates to send yourself rather than having your ACME client do so, and then you should subscribe to the API Announcements category so that you're informed if and when the certificate chain changes.


Yes I have tested just manually reducing fullchain.pem down a bit and it works well. Actually thinking about this as we control the client we can probably put E1/2 in there as well and not serve that in the normal case. If E1/2 change then we can just add them to the chain that we serve.

1 Like

I would highly recommend just putting roots in your trust stores, and let intermediates be sent by the server. Intermediates change much more often than roots, and with much less notice.

If your application requirements actually care about the extra bytes involved with sending the intermediate, and you have full control over the clients, you might be better served with your own private CA (just making your own P-256 cert that signs everything directly and is in your client trust stores), rather than trying to shoehorn Let's Encrypt in there which is much more designed for public servers.

Also, if this is some sort of "embedded" type device where updating the trust store can be challenging, you certainly want multiple CAs in your trust store anyway since you don't want to rely on Let's Encrypt's root being around indefinitely. While I certainly hope that it is around for a long time, if Let's Encrypt suffers a key compromise or runs out of funding or whatever, or just has an extended outage where you can't renew your server certificate in time, you want to be able to recover, and one way to do that is to ensure you have your own private CA in the trust store.


That's a good idea. The use-case is an android app where with a 6 month+ lag for adoption. And we really really care about data usage, with a scale of millions of daily users. So relatively easy to update it just takes a bit of time.

What I'm thinking to do is use the default android CA's and add in LE roots + LE intermediaries, and just serve the LE cert on its own to minimize bandwidth (we also heavily use SSL session resumption etc). If something does happen to LE or the intermediaries change, we can then easily switch to another cert provider and/or start including the intermediaries in the chain at a cost of more bandwidth but continued functionality.

I agree that running our own CA would also be an option (and I had not thought of this before), however I'm not convinced that our smallish team would have good enough knowledge of the intricacies around this not to break stuff or to handle key signing/rotation/security well enough so I'd probably rather not go down this route just yet and keep using the excellent service that LE provides.


I would gently caution against trying to customize trust stores unless you really have to: It is incredibly likely to cause you trouble in the future. The bandwidth savings are going to be pretty minimal, and as a small team, you're going to have trouble debugging this in the future when an outage is inevitably caused.


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