Enhancement: Allow use of provided CSRs in normal renewal flow #221

New Issue

adam · 2025-12-29T01:19:11+01:00

adam commented

2025-12-29 01:19:11 +01:00

Originally created by @timmc on GitHub (May 23, 2017).

I have a use-case where I want to periodically renew a cert, but I have to use a CSR I created elsewhere. I could use --signcsr, but then I'd have to reimplement all of the renewal logic that dehydrated already provides. What do you think about an enhancement to allow a --csr parameter that skips the CSR generation step and uses the provided one instead?

In my case, I need to generate a certificate for a Jabber IM server that uses the same domain as my website. My best option is to generate a private key and CSR on the Jabber server, then copy the CSR over to my web host to complete the ACME flow. I'd like to just keep that CSR there and have a cron job that uses dehydrated to renew the cert and then ship the cert back to my Jabber server. This would make it a lot easier to use Let's Encrypt for non-website TLS!

I understand that one complication is that this would limit the request to a single domain at a time (perhaps requiring the --domain parameter.) Are there other complications with this request?

Originally created by @timmc on GitHub (May 23, 2017). I have a use-case where I want to periodically renew a cert, but I have to use a CSR I created elsewhere. I could use `--signcsr`, but then I'd have to reimplement all of the renewal logic that dehydrated already provides. What do you think about an enhancement to allow a `--csr` parameter that skips the CSR generation step and uses the provided one instead? In my case, I need to generate a certificate for a Jabber IM server that uses the same domain as my website. My best option is to generate a private key and CSR on the Jabber server, then copy the CSR over to my web host to complete the ACME flow. I'd like to just keep that CSR there and have a cron job that uses dehydrated to renew the cert and then ship the cert back to my Jabber server. This would make it a lot easier to use Let's Encrypt for non-website TLS! I understand that one complication is that this would limit the request to a single domain at a time (perhaps requiring the `--domain` parameter.) Are there other complications with this request?

adam closed this issue

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

adam commented

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

@lukas2511 commented on GitHub (Jul 10, 2017):

Mh this won't easily work when you are using the same domain for both services. You could in theory easily run multiple instances of dehydrated, since the account key is part of the verification filename it should even be easy to forward a request to a different server, or you could use dns verification. That way you could run a dehydrated cronjob with hooks and everything on your jabber server and benefit from automatic reloading on certificate renewal and stuff.

@lukas2511 commented on GitHub (Jul 10, 2017): Mh this won't easily work when you are using the same domain for both services. You could in theory easily run multiple instances of dehydrated, since the account key is part of the verification filename it should even be easy to forward a request to a different server, or you could use dns verification. That way you could run a dehydrated cronjob with hooks and everything on your jabber server and benefit from automatic reloading on certificate renewal and stuff.

adam commented

2025-12-29 01:19:14 +01:00

@timmc commented on GitHub (Jul 16, 2017):

Yes, I would be running a different instance of dehydrated. Forwarding is not easy, because .well-known/acme-challenge needs to be accessible for both the web server's verification and the Jabber server's verification. DNS verification is decidedly not easy, because even if my host supported API access to DNS, I'm not sure I'd want to distribute such sensitive keys to my Jabber server.

That's why I'm interested in precomputing a CSR and giving that to dehydrated. Does that make sense?

@timmc commented on GitHub (Jul 16, 2017): Yes, I would be running a different instance of dehydrated. Forwarding is not easy, because `.well-known/acme-challenge` needs to be accessible for both the web server's verification and the Jabber server's verification. DNS verification is decidedly not easy, because even if my host supported API access to DNS, I'm not sure I'd want to distribute such sensitive keys to my Jabber server. That's why I'm interested in precomputing a CSR and giving that to dehydrated. Does that make sense?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#221