please let me reuse a key during cert renewal

[dkg]

I have a cert that needs to keep the same public key over a couple years at least.

I like the short cert lifetimes, i just want to renew with the same public key.

But certbot automatically generates a new key at each renewal event. Please give "certbot renew" the option of re-using the existing key.

[pde]

There is already a flag --key-path, that should probably have these semantics.

[pde]

The CLI entry for key-path is currently way too complicated;

    section = "paths"
    if verb in ("install", "revoke"):
        section = verb
    # revoke --key-path reads a file, install --key-path takes a string
    add(section, "--key-path", required=(verb == "install"),
        type=((verb == "revoke" and read_file) or os.path.abspath),
        help="Path to private key for cert installation "
             "or revocation (if account key is missing)")

The section logic is obsolete since #3254 landed; we can just make the section be ["paths", "install", "revoke"]. Then the place to implement the actual key reuse logic would probably be to take an alternative path here if self.config.key_path is set.

[pde]

@dkg send us a pull request!

[thomaszbz]

There's also a technical use case for this (be it --key-path or --reuse-key like suggested by @schoen in the PR): DNSSEC/DANE, thereby not TLSA-pinning the CA but the public key itself (which is why the private key should not change every 3 months because that triggers the need to update DNS in time whereas in time means that DNS must provide TLSA-entries for both, old and new private key, until the caching period of DNS is over, which allows to drop TLSA-entries for the old private key and purely rely on the new private key for connections). As long as the private key remains the same, all the DNS overhead becomes obsolete (at least for 1-3 years until private key material should be replaced, just to be sure).

I think --reuse-key would be much easier to use, whereas use cases for --key-path exist as well. Why not both?

[ArchangeGabriel]

I agree with @thomaszbz.

[noqu]

Unless I am much mistaken, users of HPKP (HTTP Public Key Pinning) would also greatly benefit from --reuse-key.

With HPKP, in order to migrate from one public key to another, it is necessary to adapt the server's secondary pin-sha256 header well in advance of the actual migration, so that clients will accept the (future) new key as genuine.

This is definitely not something you would want to do every three months.

[ArchangeGabriel]

Yes indeed, but HPKP is dying and DNSSEC/DANE is what people should be focusing on. ;)

[vbertola]

I second --reuse-key for DNSSEC/DANE usage, especially if you could make it stick so that, when running a general "renew", the certificates that were created with --reuse-key will be renewed with the same option set (as "renew" promises to do anyway). So it needs to be an option for the "run" and "certonly" subcommands as well, and not just for "renew"; in these cases, --reuse-key would create the key as usual, but would mark the certificate so that the key will not be changed during future renewals.

[vbertola]

Thinking again, if you want to support DANE, you also need to implement another piece of the picture. You have to be able to rollover the private key every now and then! And at the same time, you have to generate the new key without making it go live immediately, because, once you create the new key, you need to extract the TLSA record, put it into the DNS and let it propagate, before being able to use it.

So what I would propose is this: for certificates created with the --reuse-key flag, you would have a special subcommand, or better, flag in the certonly subcommand, e.g. --rollover-key (e.g. certbot-auto certonly --rollover-key -d <FQDN>). In this case, certbot would only generate a new private key and store it in the archive directory, without updating the privkey.pem link in the live directory. Then, at the next renew run (or certonly without --rollover-key), the new private key would be used to request the new certificate, and both the new key and the new certificate would be symlinked in the live directory.

[dkg]

Willem Toroop points out to me that with a static key and CSR, this is easy to do in a one-shot way with:

certbot certonly --csr csr.pem --fullchain-path fullchain.pem

however, this doesn't come with all the nice timing/analysis that you get from certbot renew -- if you run this twice a day, you'll get two new certs every day :/