Config option to resign existing public key #254

New Issue

2025-12-29T01:20:23+01:00

adam commented

2025-12-29 01:20:23 +01:00

Originally created by @madduck on GitHub (Sep 18, 2017).

With --cron, dehydrated creates a new keypair which it then signs, while --signcsr gives access to functionality that requests a new certificate for the existing keypair. This has the benefit that the public key ID/fingerprint does not change. However, --signcsr is really more of an ad-hoc method, while --cron is really handy to be run regularly.

Would it be possible to introduce a new config option (which should also be configurable per-domain) which causes dehydrated to preserve the keypair and CSR and simply request a new certificate, optionally revoking any existing ones?

Originally created by @madduck on GitHub (Sep 18, 2017). With `--cron`, dehydrated creates a new keypair which it then signs, while `--signcsr` gives access to functionality that requests a new certificate for the existing keypair. This has the benefit that the public key ID/fingerprint does not change. However, `--signcsr` is really more of an ad-hoc method, while `--cron` is really handy to be run regularly. Would it be possible to introduce a new config option (which should also be configurable per-domain) which causes dehydrated to preserve the keypair and CSR and simply request a new certificate, optionally revoking any existing ones?

adam closed this issue

2025-12-29 01:20:23 +01:00

adam commented

2025-12-29 01:20:24 +01:00

@dkg commented on GitHub (Sep 18, 2017):

I understand why you want to preserve the secret key. Is there a reason that you care about preserving the CSR specifically? seems like issuing a new CSR with the secret key should also be acceptable for your goals. Given that there are (iirc) timestamps in the CSR, issuing a new CSR seems better if there are ACME servers that test the incoming CSR for "freshness"

@dkg commented on GitHub (Sep 18, 2017): I understand why you want to preserve the secret key. Is there a reason that you care about preserving the CSR specifically? seems like issuing a new CSR with the secret key should also be acceptable for your goals. Given that there are (iirc) timestamps in the CSR, issuing a new CSR seems better if there are ACME servers that test the incoming CSR for "freshness"

adam commented

2025-12-29 01:20:25 +01:00

@lukas2511 commented on GitHub (Sep 18, 2017):

You can disable PRIVATE_KEY_RENEW to keep the key.
There is also key rollover support, I'd suggest taking a look at using that for pubkey pinning.

@lukas2511 commented on GitHub (Sep 18, 2017): You can disable `PRIVATE_KEY_RENEW` to keep the key. There is also key rollover support, I'd suggest taking a look at using that for pubkey pinning.

adam commented

2025-12-29 01:20:25 +01:00

@madduck commented on GitHub (Sep 18, 2017):

The setting @lukas2511 mentioned does the trick. I was of course grepping for PUB… sorry!

And @dkg: no, no need to keep the CSR, except I saw --signcsr.

@madduck commented on GitHub (Sep 18, 2017): The setting @lukas2511 mentioned does the trick. I was of course grepping for PUB… sorry! And @dkg: no, no need to keep the CSR, except I saw `--signcsr`.

adam referenced this issue

2025-12-29 01:29:03 +01:00

[PR #254] [MERGED] Fix default license help text in example config #770

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#254