New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

please let me reuse a key during cert renewal #3788

Closed
dkg opened this Issue Nov 12, 2016 · 10 comments

Comments

Projects
None yet
8 participants
@dkg
Copy link

dkg commented Nov 12, 2016

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

This comment has been minimized.

Copy link
Member

pde commented Nov 15, 2016

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

@pde pde added this to the Wishlist milestone Nov 15, 2016

@pde

This comment has been minimized.

Copy link
Member

pde commented Nov 15, 2016

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

This comment has been minimized.

Copy link
Member

pde commented Nov 15, 2016

@dkg send us a pull request!

@thomaszbz

This comment has been minimized.

Copy link
Contributor

thomaszbz commented Dec 3, 2016

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

This comment has been minimized.

Copy link

ArchangeGabriel commented Dec 4, 2016

I agree with @thomaszbz.

@noqu

This comment has been minimized.

Copy link

noqu commented Dec 11, 2016

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

This comment has been minimized.

Copy link

ArchangeGabriel commented Dec 11, 2016

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

@vbertola

This comment has been minimized.

Copy link

vbertola commented Dec 14, 2016

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

This comment has been minimized.

Copy link

vbertola commented Dec 15, 2016

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.

supermari0 added a commit to supermari0/certbot that referenced this issue Dec 29, 2016

Add ability to reuse key during cert renewal (certbot#3788)
This allows users to reuse the private key used for signing a cert (--reuse-key
option) or specify their own private key to use for signing (--key-path
option).

supermari0 added a commit to supermari0/certbot that referenced this issue Dec 29, 2016

Add ability to reuse key during cert renewal (certbot#3788)
This allows users to reuse the private key used for signing a cert (--reuse-key
option) or specify their own private key to use for signing (--key-path
option).

supermari0 added a commit to supermari0/certbot that referenced this issue Dec 29, 2016

Add ability to reuse key during cert renewal (certbot#3788)
This allows users to reuse the private key used for signing a cert (--reuse-key
option) or specify their own private key to use for signing (--key-path
option).
@dkg

This comment has been minimized.

Copy link

dkg commented Feb 26, 2017

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 :/

@bmw bmw removed the current sprint label Jun 20, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment