Handling scheduled renewals when /etc/letsencrypt/ folder is not available?


#1

I have a setup where certbot is being run, using a small bash script, inside of a Docker container. The script issues a certificate and sticks the files in a location (not using a mounted volume, but uploading them) and is scheduled to run using a cron job

The script issues the certificate using

certbot certonly \
–non-interactive \
–agree-tos \
–webroot \
–webroot-path ./challenges \
–email <some-email> \
–domains <some-domain>

All this works fine. That said, I need to figure out the proper way to handle renewals in this scenario. I’d like my cronjob to run twice per day, but since the content of the docker container is ephemeral, the next time it fires then the /etc/letsencrypt/ folder is no longer available, so it would think it is requesting the certificate again. At twice per day it would hit the Duplicate Certificate limit of 5 certificates per week, i.e I think I would not be counted towards the Renewal Exemption limit as described at https://letsencrypt.org/docs/rate-limits/

To make sure you can always renew your certificates when you need to, we have a Renewal Exemption to the Certificates per Registered Domain limit. Even if you’ve hit the limit for the week, you can still issue new certificates that count as renewals. An issuance request counts as a renewal if it contains the exact same set of hostnames as a previously issued certificate. This is the same definition used for the Duplicate Certificate limit described above. Renewals are still subject to the Duplicate Certificate limit. Also note: the order of renewals and new issuances matters. To get the maximum possible number of certificates, you must perform all new issuances before renewals during a given time window.

I’m basing this on the fact that I do not have the /etc/letsencrypt/renewal/ folder available when I run it. Is there a way (command line option etc?) that let me run the above command (but modified) twice per day and it would only send me the cert files if they’re due for renewal?

I hade a look at https://certbot.eff.org/docs/using.html#certbot-command-line-options but couldn’t find anything

Thanks!


#2

How can certbot know which files are due for renewal if there don’t actually exist any?
Rethink your issuance process.


#3

Well certbot might not know, but the Let’s Encrypt servers do know about the certificates and when they’re due for renewal. Basically I was hoping there would be a way for me to pass a flag to the server on my request (or something similar)


#4

I think that your only hope to get this done with such a requirement is to check the cert that is actually in use and decide to run certbot based on that date - but there may be other ways.
There is always another way!

Scrape the expiration date from the cert and compare that to a threshold and then run your already defined script when its’ close enough to expiration.

Requires having access to the previously issued public cert (to get that expiration date) <<<probably the most difficult part.
Text to date manipulation (to work with it as a date)
An expiration date minus today subtraction function (to get the diff in days)
Then an IF statement (when diff less than X do your certbot script “and issue a new cert”)

I leave all that to your capable hands and mind; as this is a forum just for LetsEncrypt issues.


#5

No, there isn’t. You may check expiration by yourself (openssl x509 -dates -noout -in /path/to/certificate.pem) but this also requires at least a temporarily stored file. Besides from that, think about the account you use (registered for). If you always start with an empty /etc/letsencrypt directory, you will end up creating many one-purpose accounts on the ACME server. This is (at least from my point of view) considered to be discouraged.


#6

I had not thought of that, and I do agree it is bad practice to do so.

So that leaves him with… somehow storing and retrieving the basic essentials to be able to renew the cert “normally”.


#7

Even if the LE servers would know that, your private key would be gone. Private keys are always kept on the issuing server.

You should make changes to your Docker configuration to make sure the /etc/letsencrypt/ directory is not ephemeral.


#8

Yeah I’ve opted on mounting a persistent folder into my container instead. I think I’ll have to split my bash script into two. One for running the actual certbot command and one that is called by --renew-hook so I can act when a renewal actually happened, because, from what I could tell, there is no way to check this based on the return code (i.e it’s zero 0 for success or non-zero for errors).

Thanks


#9

Are the –post-hook, –pre-hook and –renewal-hook available when you run certbot certonly instead of certbot renew?


#10

I don’t know since I don’t use certbot. Just try it out :smiley:


#11

I did and nothing was triggering… unsure if I was doing something wrong or if this was a limitation :grinning:


#12

The pre and post-hooks should always run.
I believe the renewal-hook was replaced with deploy-hook (which should run only if a new cert is obtained).


#13

The Let’s Encrypt servers don’t necessarily have this concept in the way that you might think, since they don’t know whether certificates are still in use or not and they don’t know whether or how overlapping certificates are installed on multiple servers.

You could use the data from https://crt.sh/ to do a search to figure out for yourself whether or not there are valid certificates out there for the names that you want, and when those certificates will expire. However, I think the idea later in this thread of trying to persist /etc/letsencrypt is a much simpler solution in the long run!


#14

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