Default to force new private key

[FernandoMiguel]

Certbot by default changes the private key for protection of forward secrecy.

In https://github.com/Neilpang/acme.sh/issues/914 an option was added for users to force this

Can we make this behaviour the default and align with the official client, and instead have an option to keep the key in case the user is doing key pinning?

[Neilpang]

Thanks for the prompt.

1. It's never our goal to align with certbot.
2. Our goal is:

   1. Powerful: Run all the ACME features on any platforms.
   2. Easy to use.
   3. Secure:  acme.sh would never make your system more insecure,  and would never mess up your system.

To be honest, I'm not sure why they(certbot) are so confident to make changes for the system administrators: they upgrade their systems, upgrade the python stuffs, install a lot of rubbish on the system, they even modify the apache/nginx configs silently. It looks stupid. As a system administrator, I would never allow such behaviors. I don't want anybody to mess up my system, and I won't do that either.

So, we (acme.sh) never changes the system, we respect all the system settings, we write little files, we even allow and respect the user customized file access mode. we keep cautious about any dangerous commands, such: sudo, chmod, chown and rm etc.

We never rm/overwrite files without the explicit permissions and confirmations, especially for critical files, such as account key or cert key.

When you use acme.sh, you can take it easy. it will never do anything out of your permissions and expectations.

It's silly to overwrite the keys by default silently. I don't want that.

[FernandoMiguel]

it's not a silent process. It's running the renewal process, which is expected to change things a bit.

It's also a decision about sensible security defaults.

here is LE/ @schoen stand on this https://community.letsencrypt.org/t/do-new-private-keys-get-regenerated-on-certificate-renewal/21486/4

[Neilpang]

yes, renewal process is silent to me too. I don't like it to overwrite files by default, unless I explicitly told it too.

[FernandoMiguel]

I respect your opinion @Neilpang , but I would like to state that in this particular case I disagree with the implementation. Have a great weekend, buddy

[janipewter]

+1 on rotating private key at each renewal. From a security standpoint, it makes absolute sense. There are no downsides to keeping the same private key other than it makes HPKP a bit easier, but that has been deprecated and replaced by CT and DNS CAA anyway and shouldn't be used.

[zoc]

I understand all contributors opinion and the idea behind rotating private keys, but having this as a default now, thus changing the current behavior of acme.sh, is clearly a big issue to me.

I'm currently having a lot of domains with DANE "3.1.1" TLSA records that are occasionally changed only (I mean, not every time the certificate is renewed). I'm also using public key pinning on my main postfix server to authenticate satellite MTAs. Rotating keys would break those records at each renewal, and given the acme.sh can be updated automatically, I might not even be informed it has been introduced.

I would also like to have rotating keys. But not by changing the default behavior.

[janipewter]

The case for HTTP Public Key Pinning is very niche now that all of the major browsers have completely removed it. Personally I believe rotating keys at certificate renewal should be the default behaviour, with a switch to disable it. The very very few (probably <1%) of people with an actual use case for not rotating keys, such as deploying HPKP in the few applications (probably custom ones) that still support it, are more likely to know they need to specify a flag in order to not do so. People who just want TLS certificates for their web server are less likely to look through the switches, and will just run the minimal command to get their cert, and in these cases there should definitely be key rotation by default.

[zoc]

Ok, as soon as it does not have any impact on renewing certificates that were created using the script before the change is introduced. I would like to avoid having to manually update the config file for all the certificates for which rotating key is not desirable.

[FernandoMiguel]

ideally, to keep retrocompatibility, any already issued certs should keep the existing settings. newly issued certs should default to rotate the key.

sounds like a plan?

[janipewter]

Just leave existing certs, and change the default behaviour for the future to be to rotate keys when deploying a cert. It won't help those who already have renewal configs which don't rotate keys, but it's far better than nothing.

[Neilpang]

lets wait and see.

I don't like my private key to be overwritten silently. If you want, you can use --always-force-new-domain-key option to issue a cert.

[nzvincent]

Hi Neil, thanks for your codes, it save me a lot of times renewing certificates. Just 2 questions, is there a parameter that I can use passphrase encrypt key? if this possible to include input .cfn file?

[Neilpang]

@nzvincent

is there a parameter that I can use passphrase encrypt key?

No.

if this possible to include input .cfn file?

what is a cfn file ?

[nzvincent]

@nzvincent

is there a parameter that I can use passphrase encrypt key?

No.

if this possible to include input .cfn file?

what is a cfn file ?

@Neilpang thank you for your prompt reply, it was my bad typo, I'm referring to openssl cnf template when generating CSR. https://www.phcomp.co.uk/Tutorials/Web-Technologies/Understanding-and-generating-OpenSSL.cnf-files.html