ECDSA Intermediates
ETA: Before March 31, 2017
Let’s Encrypt only signs end-entity certificates with RSA intermediates. We will add the ability to have end-entity certs signed by an ECDSA intermediate.
&
ECDSA Signing Support
Enabled: February 10, 2016
Added the ability for Let’s Encrypt to sign ECDSA keys with Let’s Encrypt’s RSA intermediates. Support for signing ECDSA keys with a full ECDSA cert chain will be added later.
And here
ECDSA testing on staging
https://community.letsencrypt.org/t/ecdsa-testing-on-staging/8809/74
If I remember correctly, you can use ECDSA keys using the --csr flag, but not in any mode where certbot generates the certificate for you
All suggest it’s already doable, but not in automated fashion.
Is that still the case? That certbot automation does NOT support automated generation/retrieval of ECDSA SignatureAlgorithm certs?
Is there current documentation on howto best generate ECDSA certs?
I have worked on including EC leaf certificates for certbot, but there is some delay because as of yet, you can only choose one algorithm: your cert.pem is either RSA or ECDSA. Not two certificates at the same time. And there's discussion about how to implement both RSA and ECDSA, but there isn't a decision yet.
So for ECDSA leaf certificates you'll have to be patient I'm afraid.
If we were voting, and I understand we’re not, I’d personally much rather have an ESDSA-only, automated certbot option now – and wait for eventual 2-cert-type support than have no option.
That’d simply prevent the effort – I’m sure it’s being done & re-done – by users to manually script the ECDSA generation, installation, updating, etc.
That & alternative-port support for --standalone would certainly speed up our (clients’) roll-out/adoption.
I suspect the concern is that for every smart, capable person like you who thinks it’s annoying to need to knock up a CSR to get this to work, there will turn out to be ten, or more, who think ECDSA sounds modern and exciting and don’t realise there’s any downside to just picking it instead of RSA.
Right now a noticeable fraction of questions on this site end up being about non-certificate crypto choices that have made their site unexpectedly worse than they anticipated. They have switched off TLS < 1.2 and now Windows XP doesn’t work, they disabled most of the cipher suites, or they enabled HSTS then wanted to go back to plaintext HTTP.
Some of those people (and it doesn’t have to be lots to flood this place) will say to themselves “Ooh, ECDSA, that’s cool” and won’t go “I bet that has poorer compatibility and I shouldn’t deploy it for my site”. And then they’ll write confusing questions like “Why doesn’t site work for friend in Canada?” because they don’t know they mean “I enabled ECDSA and that doesn’t work with my friend’s archaic Amiga web browser” or whatever. So for that reason I understand cerbot’s caution.
It ends up being a race between delivering dual-certificate options and the most incompatible older browsers naturally dying out. We don’t worry about stuff that can’t work with Windows 95 for example, and we stopped worrying about servers that can’t do SNI (they still exist, but nobody is offering bulk hosting with them or anything like that).
By the way you can have alternate port support today IF you are redirecting somewhere to the right port number, for example you have a symmetric NAT or some load balancer setup that can’t work with the default port on the servers. The chances of getting non-default ports permitted for the actual remote validation step is almost nil. Google’s fairly influential rep to the CA/B forum thinks that’s an awful idea because of how easy it will be for some minor employee to start up an unnoticed server on an obscure port and get certificates issued, which violates the principle of least surprise for the domain’s owner. If anything more gets OK’d, expect it to be port 25 somehow.