Shell script for cert renewal

Client dev
1

So Fun. I successfully converted my janky old site from http://tomshiro.org to https://tomshiro.org with y'alls help. I'm very pleased with all of it.

If I read the apache/Debian/pip instructions correctly, I want to check the certificate every 12 hours + (60 minutes % random number) . I wrote a shell script instead of using the suggested crontab entry:

#!/bin/bash

Run certbot for https renewal

Charles Shapiro 2 Jun 2025

/opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo

RESULTS=/tmp/certbot_results$$.txt

DELAY=$(( $RANDOM % 60 ))

sleep ${DELAY}m

certbot renew -q

certbot renew > ${RESULTS} 2>&1

export TZ='America/New York'

{
echo from: root@tomshiro.org
echo to: charles.shapiro@tomshiro.org
echo subject: certbot results
echo
echo Run time: $(date)
echo Results:
cat ${RESULTS}
} | /usr/sbin/sendmail redacted@tomshiro.org

rm ${RESULTS}

And of course my crontab(8) currently reads:

m h dom mon dow command

0 0,12 * * * root/bin/renew_certbot.sh

It seems to work ok fine. The mail I am seeing in my inbox is:

Run time: Thu Jul 24 16:24:22 EDT 2025
Results:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/tomshiro.org.conf

Certificate not yet due for renewal

The following certificates are not due for renewal yet:
/etc/letsencrypt/live/tomshiro.org/fullchain.pem expires on 2025-10-16 (skipped)
No renewals were attempted.

My only question is: Can I get away with less than every 12 hours? Maybe once a day or once a week? My cert says it expires in October or so, and from what I'm reading it'll be eligible for renewal in late August. Or is running with an expired cert gonna cause me to, like, drop off the web until it renews?

2

Oof. Guess I should learn a little more about markdown. Here is what the script really looks like:

#!/bin/bash
#
#  Run certbot for https renewal
#  
#  Charles Shapiro 2 Jun 2025
#

# /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo 
#
RESULTS=/tmp/certbot_results$$.txt

DELAY=$(( $RANDOM % 60 ))

sleep ${DELAY}m


# certbot renew -q

certbot renew > ${RESULTS} 2>&1

export TZ='America/New_York'

{
        echo from: root@tomshiro.org
        echo to: charles.shapiro@tomshiro.org
        echo subject: certbot results
        echo
        echo Run time: $(date)
        echo Results:
        cat ${RESULTS}
} | /usr/sbin/sendmail charles.shapiro@tomshiro.org

rm ${RESULTS}
3

Hello @lemgandi, welcome! :slight_smile:

Sure; but what is reasoning of the why?

Using an expired certificate causes clients (i.e. Web browsers, etc.) to fail, thus one wants to keep certificates renews in a timely fashion.
That is why your certificate is valid for 90 days and suggested to renew after 60 days with only 30 days left before expiring. In the future these will be come shorter, thus automation is your friend.

2 Likes
4

Modern versions of Certbot feature ARI, which will tell Certbot to renew it when instructed by the ACME server, even if it's not yet time to renew it based on the expiry date. Things like upcoming mass revocation events could trigger this.

With ARI it's recommended to run certbot renew quite often, maybe even more frequent than twice a day.

Especially with just one or a few certificates, there's not much harm in running certbot renew relatively frequent. It will just check if it's time to renew it based on expiry date and ARI. Nothing more.

4 Likes
5

Ah, now I get it after some thought. So "certbot renew" just checks some local dates most of the time. I was a little worried about server load on the letsencrypt side, notta mention 2 daily emails in my inbox.

And of course the cron script didn't pop ( if you look closely at my crontab entry, you'll see the missing "/" at the beginning of the script call ).

So when I've actually got this going correctly, I'll probly grep(1) for "No renewals were attempted" in the output and only email if I don't see that string.

So Fun!

1 Like
6

Until version 4.1 (released last month), certbot renew operated entirely off the timestamps on local files.

The current version now utilizes a low-cost HTTPS query for ARI information to modify renewal time (in case of potential revocation). This information is cached on disk for several hours.

if you are using 90 day certs, checking at least every 24 hours is recommended. If you decide to adopt the forthcoming short term certificates, you should run it at least every 4 hours. The reason for these intervals is a mixture of the revocation policies and how ARI replacement windows currently work; those intervals should catch all revocations timely, and also cause renewal within a valid ARI "replaces" window - which bypasses certain ratelimits and would preclude other operations from failing.

Edit: You can / certainly-should run it more frequently. These are just the current minimum times, and are expected to change as the boulder ARI implementation is fine-tuned and new shorter certificates are rolled out.

3 Likes
7

Not really, it checks OCSP responses (if embedded in the cert).

Just don't "hammer" the services, twice a day is currently recommended. More frequent might be useful in very specific reasons when using ARI (requires Certbot 4.1.0 or newer).

Please see the --quiet Certbot option.

3 Likes
8

I forgot some CAs still have those!

3 Likes
9

Thx all, I have this working the way I want now. If the servers are OK with twice a day, I am OK with twice a day.

2 Likes