What kind of alternative chains LE give for E1 certificates?

well easiest way to test would be requesting one, but I don't have account key that in whitelist.
iirc default is x1-x2-e1-leaf but what about alternative chains?

1 Like

as stated here there is no alternative chains.

2 Likes

I kinda expected longer then the long chain x3-x1-x2-e1-leaf

1 Like

you can do that by adding the X1 cross signed to the chain.

https://crt.sh/?id=3958242236

2 Likes

While you can indeed manually craft yourself a long long chain, Let's Encrypt doesn't offer this from their ACME protocol itself.

I believe this is mainly because ECDSA is thought of to be the modern choice with bandwidth considered. So E1 chains should be as few bytes as possible.

Looking at my own chains, (some of) my current certificates count the following bytes (in DER/wire encoding):

ECDSA chain RSA chain
976 bytes 1697 bytes* leaf
714 bytes 1306 bytes E1/R3 intermediate
1124 bytes 1380 bytes ISRG Root X2/ISRG Root X1 cross-sign
2814 bytes 4383 bytes Total

*This is a 4096-bit RSA key, so it's roughly 256 bytes longer than standard 2048 keys.

Here we can see that a long RSA chain (the current default), with long keys is currently about 1,5 times as big as some ECDSA chain, even though the ECDSA chain also contains an RSA cross-sign up to ISRG Root X1.

Adding even another cross-sign to that chain would increase total count to 4194 bytes, equaling the size of a current RSA chain (at least with 2048 bit keys). This would completly kill any byte savings. If old device compatibility is desired, you probably shouldn't serve ECDSA at all - just RSA. Otherwise it makes not that much sense, as you're then dealing with bugs in ECDSA stacks (such as the Android 7.0 bug), which doesn't increase your compatibility, but you also haven't saved many ressources**. Generally we would even try to get rid of that ISRG Root X2 cross-sign as soon as possible, which can enable some addtional 1KB of savings. The ECDSA chain is just not made for "let's support everything made in the last two decades", so the ACME server doesn't even offer this - you need to hack it yourself, if you really want it.

**There are a few additional interesting resource savings though: For one, generating ECDSA signatures can be faster than generating RSA signatures, so you're reducing server load with ECDSA. Verifying signatures is computationally not that different from RSA (RSA is usually faster here though), but there aren't as much bytes to hold in memory, so in extremly space-limited devices, this can be helpful.

2 Likes

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