Consider making ECDSA (p-256) the default certificate type

[april]

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.

mozilla/server-side-tls#178
mozilla/server-side-tls#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!

[Neilpang]

thanks. I will think about it.

[april]

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!

[c33s]

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]

@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).

[bjmgeek]

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.

[AvverbioPronome]

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.

[y377]

支持ECDSA

[FernandoMiguel]

implement this immediatley

@DuckFine PRs welcome :)

[8090s]

P-256 = secp256r1 = prime256v1 is not safe, why not use ed25519 or secp256k1 ?

[april]

P-256 is safe, and neither of your two options are currently allowed for use in publicly trusted certificates.

[AvverbioPronome]

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).

[Neilpang]

@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.

[Ressy66]

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 ;)

[hebbet]

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

[ghen2]

@Neilpang, can acme.sh reconsider this, too? (for new certificates, not for renewals)

[Neilpang]

yes, we will make this change soon.

[y377]

CA uses auth SHA384; will cause most of the openvpn to fail, which is really a headache

[AvverbioPronome]

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).

[y377]

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).

repair

[ghen2]

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?

[danielgran]

Nice, then this is closed. Took a decade

[maxbane]

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.

[AvverbioPronome]

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)

[fluggelgleckheimlen]

Is it possible to revert the default certificate type to RSA due compatibility issues?

[chadlwilson]

I'm a bit confused. I can see acme.sh started issuing ECC certs by default which is fine to me.

But --install-cert was still installing the old RSA certs which were left behind (and have started expiring) - so seemingly --install-cert has a different default logic for figuring out which cert to install where there are (now) multiple for a domain?

[Neilpang]

I'm a bit confused. I can see acme.sh started issuing ECC certs by default which is fine to me.

But --install-cert was still installing the old RSA certs which were left behind (and have started expiring) - so seemingly --install-cert has a different default logic for figuring our which cert to install where there are (now) multiple for a domain?

Add "--ecc" parameter

[chadlwilson]

Add "--ecc" parameter

Thanks for the tip. But this was pretty unexpected - I suppose I'd expect the defaults between commands to be consistent. If acme.sh is now renewing and "managing" an ECC cert by default and has abandoned my RSA cert - for it to do the same at installation time too :-/

I worked around earlier by archiving/renaming the old stale RSA folders which I suppose is roughly equivalent since they are all expiring shortly anyway.

[Neilpang]

Add "--ecc" parameter

Thanks for the tip. But this was pretty unexpected - I suppose I'd expect the defaults between commands to be consistent. If acme.sh is now renewing and "managing" an ECC cert by default and has abandoned my RSA cert - for it to do the same at installation time too :-/

I worked around earlier by archiving/renaming the old stale RSA folders which I suppose is roughly equivalent since they are all expiring shortly anyway.

If you have both rsa and ecdsa certs issued, that's the only way to distinguish them.

If you have only ecdsa cert, acmesh can select the correct cert automatically.

[bviktor]

@bviktor

1. Then your readme contradicts itself.
2. Also emphasis on the "you probably want to". Well, I don't. I use acme.sh to obtain wildcard certs, to be used on dozens of other servers, where the cert is deployed via Ansible. I use acme.sh to obtain certificates, not to manage my web server infrastructure and configuration, thanks. And it is nowhere stated that I MUST use acme.sh to deploy my certificates. I have my own, much better deployment tools.
3. You still haven't explained the REASON why it's a good thing to break many people's workflows with this exception, i.e. this _ecc suffix. You haven't even said "just cause", you simply ignore our inquiries on the basis that "we're holding it wrong".
4. You still haven't explained the reason why you still haven't provided us with an option to override this behavior.
5. I still don't want this certificate to be "installed". It will be used on other hosts, so I don't need acme.sh to modify (non-existent) host files, or set up cronjobs, etc.
6. I'd gladly "copy" this cert to some other path, if you insist that it's better to do 2 copy operations instead of just 1, before finally putting the cert in its final place, but I don't see a "copy" operation in the command line arguments, only "issue" and "install". How do I just copy, so that I don't conflict with your precious, randomly named "internal" directory structure?

[bviktor]

I'm a bit confused. I can see acme.sh started issuing ECC certs by default which is fine to me.
But --install-cert was still installing the old RSA certs which were left behind (and have started expiring) - so seemingly --install-cert has a different default logic for figuring our which cert to install where there are (now) multiple for a domain?

Add "--ecc" parameter

Just one more reason to not use separate directories. Just one more thing that causes confusion and breaks behaviors that existed for half a decade. On the basis of "just cause".

For issuance you don't ask for --ecc, but for install, you do? In other words, issue defaults to ecc, while install defaults to rsa? What kind of sense does that make? And this (currently broken) install command is that you're so eager to shove down our throats. Ridiculous. It's an antipattern at this point.

And this wouldn't be a problem, if you used the same dir you've been using for years. Why does the install command need to know the cert's algo, seriously? Give me one reason. Just one. It should be completely irrelevant to the issue command, it's not an encryption tool, it's a copy tool. It shouldn't care less about the key algo. The directory name should be fixed. The directory belongs to domains, not algos.

All this fuss because you refuse to admit a bad design decision. Instead, you just double down.

[Neilpang]

@bviktor

Sorry for the confusions. but if you read the readme carefully, you will know that the internal folder structure is not reliable. And you will also know that the --install-cert command is just copying the files, it will not change any of your config files.

Then, if you folllow the usage of --install-cert to copy the cert/key files to your own folder, there would not have been any breaks.

Acctaully I don't know why you have to care about the folder structure. It was never recommended to use the files in the internal positions.

Imagine that if you use a hidden/undocumented api of Windows, then Windows updates , the api breaks. That's not Windows' fault.

For the --ecc suffix, it was born years ago, it's not changed for this bug.

I knew that the change for default key type is not a small change, but I had made everything possible to keep 99% compabible.

And I can guarantee that if one follows the public command line parameters, his acme.sh would not break.

The world is changing all the time, it's not a static world. We have to move on.

Sorry for the confustion again. if you have any more problems, I'd be happy to help you and all.

[chadlwilson]

For the --ecc suffix, it was born years ago, it's not changed for this bug.

I personally don't think this makes much sense. If I was OK with default RSA certs earlier, using --ecc would break things so i have no reason to know about this flag and setting it before the default change wouldn't work. Anyway, if this is how you think the software should work, that's your decision as maintainer/owner.

I understand that if there are multiple certs (e.g RSA and ECC) to use for --install-cert that acme.sh either needs to guess which one to use, or have the user tell it via a flag. My suggestion is that since the default key type to --issue a cert is now ECC, the default cert to choose with --install-cert (if there are multiple cert/key types available and it is ambiguous) should also be to choose the ECC cert - or the one that acme.sh is actively renewing/managing. Alternatively, it should fail and tell you its ambiguous, rather than silently installing the old RSA cert/key because it happens to still exist and eventually allowing your certs to expire on your domain :-)

If it helps, here's the story

1. I am happy renewing my RSA certs automatically with defaults for years. Great!
2. The library changes to an (arguably) more secure ECC default and magically starts getting me ECC certs. Also great! I like smaller keys/sigs and more secure defaults.
3. However importing the renewed certs now breaks, eventually my certs expire on my site (doh), and I need to make a manual change to add --ecc or manually remove the old RSA certs/keys. This is strange. Why bother to change the default issued cert if I then need to "opt in" to an extra flag to make it work properly?
4. There is nothing in the --log output from the automated renewals to tell me what has changed, what cert/key type has been selected to resolve the ambiguity for the --domain or any indication of what might be wrong.
5. To figure this out I need to look into at ./acme.sh --list and start digging into internals to figure out "ok, so which certificate IS acme.sh renewing, as it's not the one being installed"

I think this could be simpler with a different default selection. Happy to raise a separate issue/request if you think it might be useful.

[Neilpang]

the default cert to choose with --install-cert (if there are multiple cert/key types available and it is ambiguous) should also be to choose the ECC cert

That would also cause compaible issues. There are many existing users have both rsa and ecc certs issued. And they know and expect to use the RSA cert by default(witout --ecc parameters).
If the default selection behavior is changed, I believe there would also be many complaints.

Usually there is no 100% perfect solution while upgrading. It's just a choose between A and B.

There is nothing in the --log output from the automated renewals to tell me what has changed,

Yes, we can improve the logs or output or our docs about it. If any one has good advices, I'm all ears.

Thanks

[bviktor]

if you read the readme carefully, you will know that the internal folder structure is not reliable. And you will also know that the --install-cert command is just copying the files, it will not change any of your config files.

I checked the manual several times already. It makes no mention of --install-cert merely copying the certs. What is says instead is that:

acme.sh --install-cert -d example.com \
--key-file       /path/to/keyfile/in/nginx/key.pem  \
--fullchain-file /path/to/fullchain/nginx/cert.pem \
--reloadcmd     "service nginx force-reload"

The cert will be renewed every 60 days by default (which is configurable HOW?). Once the cert is renewed, the Apache/Nginx service will be reloaded automatically WHY?

I don't want any of this to happen.

Acctaully I don't know why you have to care about the folder structure. It was never recommended to use the files in the internal positions.

Precisely because there's either a) no option to just copy the certs and not do anything else on the system b) your readme is wrong.

For the --ecc suffix, it was born years ago, it's not changed for this bug.

--ecc is not a suffix, it is a command line argument, you just decided to also turn it into a directory suffix. And after all these days you still haven't addressed the question as to why you felt the need to indicate this ONE thing in the directory name, among the dozen other certificate details you could also put in the dirname. But only if it's ECC - if it's not ECC, you don't include it in the dirname. Because unexplained reasons.

This, to me, still makes no sense, regardless of whether I should touch files under ~/.acme.sh or not.

But like I said, feel free to call it whatever you want, as long as you either give me a flag (or update the readme about such flag) that copies the cert to a second folder, and does absolutely nothing else.

[chadlwilson]

That would also cause compatible issues. There are many existing users have both rsa and ecc certs issued. And they know and expect to use the RSA cert by default(witout --ecc parameters). If the default selection behavior is changed, I believe there would also be many complaints.

It's your choice to evaluate, but personally I would consider the "principle of least astonishment" and that would be sensible defaults that are consistent with one another across commands.

Since changing the default key type is still a breaking change for everyone previously using default RSA and --install-cert, as well as folks depending on the directory structure, I would suggest that when you properly release the changes here (noting they are on master only), you bump the major version and change all of the defaults consistently and allow --rsa to lock the old behaviour (or similar).

Treating some commands differently to others with respect to defaults is just going to cause more confusion over time, I feel.

[Neilpang]

@bviktor

Well, now you got it. --install-cert just copies the files and run the reload-cmd (if provided). Nothing else will happen.

I will update the readme soon. And maybe I will rename the command to --copy-cert. Is that better?

OK, To anyone who reads this post in future: never, never ,never use the files directly in the internal folder ~/.acme.sh. The folder structure may change any time. Just use --instll-cert to copy the cert/key files to your own folder to use.

Anyone can also contibute to the readme.md files too.

[Neilpang]

Since changing the default key type is still a breaking change for everyone previously using default RSA

If you issued RSA cert before, the cert will be renewed without any breaks.

[chadlwilson]

Since changing the default key type is still a breaking change for everyone previously using default RSA

If you issued RSA cert before, the cert will be renewed without any breaks.

You cut off the important part of the sentence with the "and".

Since changing the default key type is still a breaking change for everyone previously using default RSA and --install-cert

I explained above exactly how it's a breaking change when combining defaults with --install-cert. As you said yourself, you need to manually add --ecc to your install cert to get the correct behaviour. Manual intervention means breaking change.

[ghen2]

As you are running acme.sh master branch code in production, you should expect changes from time to time... The P-256 default is not in any acme.sh release yet.

[chadlwilson]

As you are running acme.sh master branch code in production, you should expect changes from time to time... The P-256 default is not in any acme.sh release yet.

Yes, fair enough, I understand. However to be extra fair that is the suggested install approach,
without documentation or recommendation of how to select a branch/tag, and the current version on master isn't bumped to reflect anything like a semver-ish breaking change (it is 3.0.6). Has been 3 months since this change was made without adjustments it seems, enough for my certs to expire :)

It also doesn't look like the official release is going to be any different in 'breakingneas' of behaviour anyway based on the above, so discovery on master may be a moot point. And if it is different than current master, it'll likely be because folks on the edge tried out master and provided feedback.

[bmeirellesRJ]

when will it be possible to use ed25519 and ed448?

[AvverbioPronome]

when will it be possible to use ed25519 and ed448?

That's a question for the CA/B Forum.

[april]

Even if CA/B forum didn't forbid their issuance, it wouldn't matter much as browsers do not yet support EdDSA as a signature scheme for digital certificates anyways.

[bmeirellesRJ]

I understood. They could be released for us to use with other applications. I, for example, have been using ed25519 for a long time with openvpn generating my self-signed certificates with easy-rsa

[Neilpang]

I think we will support Ed algorithms when the ACME protocol supports them.

[bmeirellesRJ]

I think we will support Ed algorithms when the ACME protocol supports them.

on page 12 of rfc8555 it says that it should be implemented:

https://datatracker.ietf.org/doc/html/rfc8555#section-6.2

"An ACME server MUST implement the “ES256” signature algorithm [RFC7518] and SHOULD implement the “EdDSA” signature algorithm using the “Ed25519” variant (indicated by “crv”) [RFC8037]."

Today I was looking at the bind9 log and even the dnssec zones already support it:

named[10861]: DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
named[10861]: DS algorithms: SHA-1 SHA-256 SHA-384
named[10861]: HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512

I understand that browsers don't support it, but we could generate our certificates with the --eddsa or --ed25519 parameter to use in other services, for example dns-over-tls and dns-over-https. In addition to being more secure, it is faster and uses less server processing.

[AvverbioPronome]

That's for JWS and JWS alone. Not for TLS.

But don't worry too much. CA/B will eventually decide to support EdDSA, you just have to wait for the Chrome and/or Firefox teams start pushing it. It will only work with the newest versions, tho. And ecdsa p-256 is small enough already.