Acme.sh: Consider making ECDSA (p-256) the default certificate type

Created on 20 Jun 2019 · 8Comments · Source: acmesh-official/acme.sh

I'm not sure if this is the ideal place to post this, but I just wanted to give people a heads-up that Mozilla's future "Server Side TLS" guidelines will recommend ECDSA certificates for the Intermediate configuration level. This is one of the most commonly used TLS configurations for servers across the internet.

https://github.com/mozilla/server-side-tls/issues/178
https://github.com/mozilla/server-side-tls/issues/254
https://ssl-config.mozilla.org/

In our research, we found that ECDSA and RSA certificates were equally compatible with the vast majority of clients across the internet, comprising this set of clients:

Android 4.4.2+, released October 2013
Chrome 31+, released August 2016
Firefox 27+, released February 2014
IE 11 (Win 7 and Win 10), released October 2013
Edge (all versions)
Java 8u31+, released January 2015
OpenSSL 1.0.1+, released March 2012
Safari 9+, released September 2015

The reason why we are recommending ECDSA certificates over RSA certificates is that they give IE11 clients on Windows 7 access to ECDHE for key exchange; with RSA they are limited to classic DHE. My apologies if this project already uses ECDSA by default.

Please let me know if you have any questions! Thanks!

Source

april

👍5

Most helpful comment

@c33s The baseline requirements do not permit any publicly trusted CA to issue end entity certificates with an ed25519 public key at this time. Only RSA and ECDSA (with a specific set of curves, namely NIST P-256, P-384, or P-521).

cpu on 23 Jul 2019

👍4

All 8 comments

thanks. I will think about it.

Neilpang on 22 Jun 2019

Awesome, thanks. A lot of projects (such as Caddy) will continue to renew certs with the existing key type, and then switch over new certificates to ECDSA.

Either way, thank you so much for your consideration!

april on 22 Jun 2019

don't know if it is well supported to use ed25519 but using a key type which uses a broken number generator feels wrong for me.

c33s on 23 Jul 2019

😕2 👍2

cpu on 23 Jul 2019

👍4

don't know if it is well supported to use ed25519 but using a key type which uses a broken number generator feels wrong for me.

https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e8d60d3c54

https://security.stackexchange.com/a/74041

@cpu It's unlikely that browsers will support ed25519 (for authentication) in certificates any time soon (see for instance https://community.letsencrypt.org/t/can-should-isrg-submit-a-proposal-to-support-ed25519-ed448-certificates-to-ca-b-forum/85127/5 ), but many browsers and servers do support X25519 and X448 (for key exchange), instead of the NIST curves.

bjmgeek on 27 Feb 2020

It would be really cool, with two caveats:

don't make the switch for already installed acme.sh instances (or already issued certs, as @april said, I like this better), as rsa could have been an explicit choice.
probably should wait for the ecc intermediate from Let's Encrypt.

in the meantime, we could introduce an --rsa option and shiow a notice/warning if the user does not make an explicit choice for rsa or ecc.