acmesh-official
Consider making ECDSA (p-256) the default certificate type
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!
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!
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
@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).
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.
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.
P-256 = secp256r1 = prime256v1 is not safe, why not use ed25519 or secp256k1 ?
P-256 is safe, and neither of your two options are currently allowed for use in publicly trusted certificates.
P-256 = secp256r1 = prime256v1 is not safe, why not use ed25519 or secp256k1 ?
Certificate curves and ECDH key exchange curves are both used at the same time, don't mix them up.
You can only (currently) have a P-256 or a P-384 certificate (also 512, but not on Let's Encrypt), which only certifies you control the domain name, and at the same time you can use whatever curve you want (browser support permitting) for an Elliptic-curve Diffie–Hellman key exchange. The actual data is encrypted with an ephemeral key (AES 128 or 256 usually).
@8090s
As far as I know, "ed25519" cert is not supported by CAB yet.
And secp256k1 is not P-256. The CAB only supports P-256 now.
Hey Neil, for this to work well, we need to be able to use -k ec-foo with --renew, but at present that is not possible,
so AFAICT only way is to revoke and remove cert and issue new -k ec-foo, it would be nice to upgrade using just --renew
Certbot is switching to ecdsa with the next big upgrade
https://community.letsencrypt.org/t/ecdsa-certificates-by-default-and-other-upcoming-changes-in-certbot-2-0/177013
@Neilpang, can acme.sh reconsider this, too? (for new certificates, not for renewals)
CA uses auth SHA384; will cause most of the openvpn to fail, which is really a headache
CA uses auth SHA384;
That's a CA/B requirement when using a p384 intermediate.
If the CA uses a p256 intermediate it must then use sha256 in signatures. If it uses an RSA intermediate, then it can use sha256 (and others, I think).
CA uses auth SHA384;
That's a CA/B requirement when using a p384 intermediate.
If the CA uses a p256 intermediate it must then use sha256 in signatures. If it uses an RSA intermediate, then it can use sha256 (and others, I think).
yes, we will make this change soon.
Hi @Neilpang,
Just for reference, Certbot 2.0 now issues ECC (P-256) certificates by default (for new certificates, renewal of existing RSA certificates not impacted), see https://github.com/certbot/certbot/releases/tag/v2.0.0.
You may want to wait a bit to see how that goes, but then make the switch for acme.sh as well?
Hi, this broke my Unifi deployment as soon as I started issuing certs from a new clone of acme.sh, because the Unifi-OS web application only supports RSA certificates. It was necessary to delete the domain directory that had been created under ~/.acme.sh (which ended with _ecc), and start over by adding -k 4096 to the acme.sh --issue command to make RSA certs again. Just FYI for anyone else who might use acme.sh to generate certs for their UDM-Pro or other Unifi device. If you use a fresh clone, you may need to use a different issue command than you used to.
adding
-k 4096
If you want RSA 4096 bits, it's fine. But don't. You have two perfectly fine shorter lengths.
-k, --keylength <bits> Specifies the domain key length: 2048, 3072, 4096, 8192 or ec-256, ec-384, ec-521.
(nb: acme.sh supporting it doesn't mean the CA will support it)
Is it possible to revert the default certificate type to RSA due compatibility issues?
You can still request RSA certificates for legacy applications where needed, this shouldn't hold a better default for everyone else.
I don't mind the new cert type, but what I do mind is the _ecc suffix for new deployments. Why would I want a new algo to exist in a different dir. Since when does the cert dirname supposed to indicate the algo in use? Why don't we indicate key bits as well while we're at it? Or staging or production? Or any other random info? Who the hell decided we should indiciate the algo in a directory suffix, but only if it's ECC? It makes absolutely no sense whatsoever.
I saw some random requests where they wanted to use RSA and ECC at the same time, because reasons, like here:
https://github.com/acmesh-official/acme.sh/issues/74
Then how about THEY use --cert-home or any other command line flag if they're so eager to use totally random setups? Instead of breaking it for everyone else?
This is just another mess to deal with. And of course there's no command line flag to disable this behavior, ECC_SUFFIX is hardcoded. I tried --cert-home foobar.com, but all it does is put the cert under foobar.com/foobar.com_ecc instead, so yeah, very helpful.
The best I can do is check if this _ecc dir exists, and create a symlink to it I guess.
@phenri00 don't rely on the path names in the .acme.sh folder.
use the acme.sh --install-cert command to copy the cert/key files to your target folder. Then you can rely on your folder.
The _ecc suffix broke my script. Why use a suffix in this case?
The _ecc suffix broke my script too. I spent half an hour identifying and locating the breaking change mentioned in this issue and ec0e871.
Now I've added --keylength 2048 to my script to adapt to the breaking change.
Hope you guys can be kinder to remind us the breaking changes in the future.
@phenri00 don't rely on the path names in the
.acme.shfolder. use theacme.sh --install-certcommand to copy the cert/key files to your target folder. Then you can rely on your folder.
Install does several other things than just issuing the cert. Things that I don't want to happen, because I deal with them on my own.
Additonally, your own docs explicitly state this for "Just issuing a cert":
The certs will be placed in ~/.acme.sh/example.com/
So clearly, we are definitely supposed to rely on this directory structure. And you're definitely not supposed to break that on the basis that "it's gonna be there except for ECC". I can only repeat myself: it makes no sense.
All you cause with this nonsensical behavior is that people fall back to RSA (me included).