(re)generating a "Renewal Configuration File" for a dns01-auth'd domain/cert, for remote deployment & automated *renewal*?

[pgn]

i’m working an a certbot script to automate my renewals.

my locally-managed setup includes ‘preferred-challenges = dns’ & ‘authenticator = dns-rfc2136’.

cert gen is trivial, with

 certbot -c $conf/cli.ini \
  certonly \	  
  --csr            $csrs/request.ec.csr.der \
  --cert-path      $certs/cert.ec.crt.pem \
  --chain-path     $certs/intermediate_ca.ec.crt.pem \
  --fullchain-path $certs/fullchain.ec.crt.pem

where,

cat cli.ini

	non-interactive = true
	agree-tos = true
	email = "me@example.com"
	duplicate = true
	expand = true
	manual-public-ip-logging-ok
	break-my-certs = true
	hsts = true
	must-staple = true
	redirect = true
	rsa-key-size = 4096
	staple-ocsp = true
	uir = true
	preferred-challenges = dns
	authenticator = dns-rfc2136
	dns-rfc2136-credentials = "/sec/le/rfc2136.creds"
	dns-rfc2136-propagation-seconds =  60
	work-dir = /var/lib/letsencrypt
	logs-dir = /var/log/certbot
	max-log-backups = 0

as for deployment/install, since i’m using dns auth, apparently “run” & its install hooks don’t function.

it’s easy enough to manually deploy the generate certs to my remotes outside of certbot.

now, i’m trying to get a certbot instance on those remotes to renew the live/deployed certs.

for that, iiuc, I need to feed certbot the domain’s “Renewal Configuration File”.

but, one’s not generated in the ‘certonly’ step; There’s no relevant “…/renewal/” DIR that I can find.

how do I force the creation of “Renewal Configuration File” for a domain?

or, where’s the doc for manually creating one, and pointing ‘renew’ at it?

[_az]

When you run Certbot with --csr, it essentially cuts out 99% of the functionality present in Certbot related to renewal (and generation of any renewal configuration). It is completely stateless.

For most users, it is not a recommended mode of operation.

The basic model for what I think you want to do is something like:

certbot certonly \
--dns-rfc2136 --dns-rfc2136-credentials=... \
-d example.com \
--deploy-hook /sbin/deploy-to-remotes.sh

where the deploy hook just copies the fullchain.pem via rsync or whatever to your other servers and triggers a server reload on them.

If the (by default) rotation of the private key is a problem for you, you can use --reuse-key, bootstrap the private key one time to your remotes, and after that, only sync the renewed certificate.

I’m not really sure why you have made the choices you’ve made so far, but hopefully this answer will point you in the right direction.

Edit: ah, are you using --csr because you want to use an ECDSA subject key? That poses a problem. I’d probably suggest a different ACME client if that’s a hard requirement for you.

[pgn]

--deploy-hook /sbin/deploy-to-remotes.sh

where the deploy hook just copies the fullchain.pem via rsync or whatever to your other servers and triggers a server reload on them.

If the (by default) rotation of the private key is a problem for you, you can use --reuse-key, bootstrap the private key one time to your remotes, and after that, only sync the renewed certificate.

What I'd like to do is

(1) continue to create, and initially install, all my certs locally and deploy them as needed to my remote servers.

this, I already do.

AND,

(2) on those remote servers, 'simply' issue a "certbot renew" (or as close to that simplicity as possible), and have certbot -- on the remote -- renew only that remote's certs.

For that to occur, I need to "tell" certbot, on the remote, about those certs ...

IIUC, the presence of the "Renewal Configuration File" in/under /etc/letsencrpyt/renewal/ should (?) be sufficient. Which is why I'm trying to get one ...

Edit: ah, are you using --csr because you want to use an ECDSA subject key? That poses a problem. I’d probably suggest a different ACME client if that’s a hard requirement for you.

Yes, in part.

I have been using a fully manual certbot config/deploy for quite awhile. It's just gotten messy(ishh) to manage.

Which is why I started looking for a well-managed/supported alternative.

I've taken both lego & acme.sh for a spin. for my tastes, lego's too 'opinionated', and lacking docs. and, it refuses to build in my local go env; not encouraging.

acme.sh is fine in principle -- it looked like it'd be the right fit for my interests.
but cert generation is frequently/intermittently buggy, and filed bugs don't get prompt attention (so far, anyway).

[_az]

I see.

The only way I see this working is for you to setup a similar --csr command on the remote, add it to cron, and continue to avoid Certbot’s renewal functionality.

You can’t really reverse-engineer the renewal configuration into existence if --csr is your starting point. Besides /etc/letsencryt/renewal/*.conf, renewal also relies on the internal state of /etc/letsencrypt/archive.

I think you are buying yourself a lot of problems by bootstrapping certificates locally and then trying to get the remotes to carry the torch. Though I do understand that you have your reasons for it.