Cert renews even though no crontab or certbot-auto used

My domain is: region10.org

I ran this command: N/A

It produced this output: N/A

My web server is (include version): Apache/2.4.6 (CentOS)

The operating system my web server runs on is (include version): CentOS Linux release 7.8.2003 (Core)

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):certbot --version
certbot 1.13.0


How do I find out how my cert is being auto renewed when I am not using certbot-auto and I am not running any script via crontab and the systemd service for certbot is not being used? In short, I cannot determine what/how my certbot is getting renewed (and it is getting renewed).

I would look in /var/log and grep some files for "letsencrypt" and "acme". you can also try to pin down the timing with the date in the active certificate. that may give you a hint about what client was invoked.

Options used in the renewal process

account = xxxxxxxxxxxxxxxxxxxxxx
authenticator = apache
installer = apache
server = https://acme-v02.api.letsencrypt.org/directory

Found the above in the /etc/letsencrypt/renewal/account.conf file. Does this indicate that Apache handles the renewal processing?

The log file /var/log/letsencrypt/letsencrypt.log also shows:

2021-03-18 06:05:02,200:INFO:certbot._internal.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2021-03-18 06:05:02,200:DEBUG:certbot.display.util:Notifying user: Processing /etc/letsencrypt/renewal/account.conf
2021-03-18 06:05:02,214:DEBUG:certbot._internal.plugins.selection:Requested authenticator <certbot._internal.cli.cli_utils._Default object at 0x7fd6694ecd90> and installer <certbot._internal.cli.cli_utils._Default object at 0x7fd6694ecd90>
2021-03-18 06:05:02,229:DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): r3.o.lencr.org:80
2021-03-18 06:05:02,278:DEBUG:urllib3.connectionpool:http://r3.o.lencr.org:80 "POST / HTTP/1.1" 200 503
2021-03-18 06:05:02,279:DEBUG:certbot.ocsp:OCSP response for certificate /etc/letsencrypt/archive/account.org/xxx.pem is signed by the certificate's issuer.
2021-03-18 06:05:02,286:DEBUG:certbot.ocsp:OCSP certificate status for /etc/letsencrypt/archive/account.org/xxx3.pem is: OCSPCertStatus.GOOD
2021-03-18 06:05:02,288:INFO:certbot._internal.renewal:Cert not yet due for renewal
2021-03-18 06:05:02,288:DEBUG:certbot._internal.plugins.selection:Requested authenticator apache and installer apache
2021-03-18 06:05:02,290:DEBUG:certbot._internal.plugins.selection:Selecting plugin: * apache
Description: Apache Web Server plugin

I did see the following when I grep'd for acme:


No, the other way around: certbot uses Apache for its authentication processing.

Certbot requires to be envoked by something: it doesn't just run on its own (although OS packages may add cronjobs or systemd timers).

Did you check the cronjob for the root user? You probably did, but it's easy to run crontab -l as the usual user and forget it doesn't list the root crontabs.

Also, to be clear: certbot-auto was just a wrapper script around the certbot program. It didn't make certbot auto-run or something like that.

The crontab for 'root' does not invoke certbot. In fact, I checked all the crontabs for all users -- no certbot invoked.

I did see the following when I grep'd for acme:


Those are just the standard account directories used by certbot.

Perhaps you might see a pattern in the envocation of certbot in the logs from /var/log/letsencrypt. As far as I know, certbot generates a new log every time it runs. Your most recent log was apparently run today at 06:05. The most commonly used cronjob or systemd timers installed by OS packages are twice a day, but (unfortunately for diagnosing this issue) often include a random delay so the Let's Encrypt servers don't get peak usage at the whole hour. However, you might see logs appearing twice a day, which might hint to some kind of hidden (?) cronjob or systemd timer.

One can see all services by running : systemctl list-units --type=service

I see snapd running and the following installed snaps

#> ]# snap list
Name Version Rev Tracking Publisher Notes
certbot 1.13.0 1042 latest/stable certbot-eff✓ classic
core 16-2.49 10859 latest/stable canonical✓ core
core20 20201210 904 latest/stable canonical✓ base

looks like the first one is the process, wouldn't you say?

systemctl status snapd.socket
● snapd.socket - Socket activation for snappy daemon
Loaded: loaded (/usr/lib/systemd/system/snapd.socket; enabled; vendor preset: disabled)
Active: active (running) since Sun 2021-02-21 04:00:36 CST; 3 weeks 4 days ago
Listen: /run/snapd.socket (Stream)
/run/snapd-snap.socket (Stream)

snap refresh --time
timer: 00:00~24:00/4
last: today at 14:16 CDT
next: today at 23:30 CDT

@certbot-devs Does the snap service also install some kind of renewal timer?

systemctl status snap.certbot.renew.timer
● snap.certbot.renew.timer - Timer renew for snap application certbot.renew
Loaded: loaded (/etc/systemd/system/snap.certbot.renew.timer; enabled; vendor preset: disabled)
Active: active (waiting) since Wed 2021-03-03 19:26:09 CST; 2 weeks 0 days ago

Mar 03 19:26:09 mellon-test.region10.esc10.org systemd[1]: Started Timer renew for snap application certbot.renew.

systemctl cat snap.certbot.renew.timer

looks like twice a day, every day,



Auto-generated, DO NOT EDIT

Description=Timer renew for snap application certbot.renew






OnCalendar=--* 06:05

OnCalendar=--* 21:16



1 Like

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