Obtaining a certificate for a custom, pre-generated key pair

Feature Requests
1

This has been discussed here years ago, but for some reason I can't reply to that thread. (Either the thread is too old or my membership is too young. :stuck_out_tongue_winking_eye:)

Has there been any progress on using pre-generated key pairs to obtain signatures with the default certbot client?

A typical use case would be a DANE rollover scheme. (Yes, I get it, some say that DANE should be used for self-signed certificates only, but I see no reason not to publish keys signed by Let's Encrypt in DANE.)

  1. Generate your next key pair.
  2. Publish your public key in DANE at least one DNS expiry interval ahead.
  3. Obtain a signature from Let's Encrypt for the already published public key.
  4. Switch your service to the new key pair.
  5. Remove the old public key from DNS.
  6. Do nothing for ~2 months.
  7. Go back to 0.

The absence of a (obvious) rollover scheme is pointed out (also) by the internet.nl DNS and mail server checker (with further details about the whole concept):

rollover
rollover1265×2521 338 KB

1 Like
2

Hi @andrejpodzimek

not tested, but I don't understand the question.

  • Create a key pair with OpenSsl
  • Create a CSR (should be possible with OpenSsl or another tool)
  • Use that CSR with the --csr option (only certonly)
  • Install the certificate (or replace the old and restart your webserver)
3 Likes
3

Nope, although you can use a CSR (as @JuergenAuer mentions), at the cost of not being able to use certbot renew to renew that certificate. You can also fake it by

  • generating a certificate with a different key, then copying your key over /etc/letsencrypt/archive/privkey.pem, then doing certbot renew --force-renewal (note that this might not work depending on whether your particular authenticator plugin fails if it needs to restart your web server application before the new certificate is obtained—although you can sidestep this by getting the initial certificate with certonly and then changing this to add an installer for the second certificate, using run instead of renew and specifying the installer with -i)

or

  • patching the make_key function in crypto_util.py to do something like

return open("/tmp/myexistingkey.pem", "r").read()

instead of the existing

return crypto.dump_privatekey(crypto.FILETYPE_PEM, key)

(I haven't checked whether it should be "r" or "rb" to match the return datatype of dump_privatekey.)

I admit that these solutions are pretty terrible but I think the level of demand for this feature has never become all that huge (as contrasted with --reuse-key, to let Certbot generate the first key but then not change it thereafter, which comparatively a lot more people wanted).

3 Likes
4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.