Is the renew timer running on my machine as it is supposed to?

Help
1

Hi guys,

quick question regarding automated certificate renewal.

Short version: Can I rely on the timer

$ systemctl list-timers
Thu 2020-04-02 18:01:17 CEST  2h 25min left Thu 2020-04-02 10:35:25 CEST  5h 0min ago  certbot.timer                certbot.service

to reliably renew the certificate when due time has come?

Long version: I managed to create a certificate thanks to your support. :slight_smile: Now I would like to make my machine automatically renew it when time is due such that it doesn’t expire without me noticing. I found this HowTo: https://techmonger.github.io/49/certbot-auto-renew/ and wanted to implement it, but then found out that exactly this script is already placed into /etc/cron.d/. Looks like the folks from Raspbian/Debian made a comfy package for us. However, the script has the following comment, I mean the last paragraph:

# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
#
# Important Note!  This cronjob will NOT be executed if you are
# running systemd as your init system.  If you are running systemd,
# the cronjob.timer function takes precedence over this cronjob.  For
# more details, see the systemd.timer manpage, or use systemctl show
# certbot.timer.

Since Raspbian indeed uses systemd, the comment does apply in my case. So I looked into the timer and it shows:

$ systemctl show certbot.timer
Unit=certbot.service
NextElapseUSecRealtime=50y 3month 20h 31min 17.696741s
NextElapseUSecMonotonic=0
LastTriggerUSec=50y 3month 13h 5min 25.549290s
LastTriggerUSecMonotonic=3d 13h 19min 18.141108s
Result=success
AccuracyUSec=1min
RandomizedDelayUSec=12h
Persistent=yes
WakeSystem=no
RemainAfterElapse=yes
Id=certbot.timer
Names=certbot.timer
Requires=-.mount sysinit.target
WantedBy=timers.target
Conflicts=shutdown.target
Before=certbot.service timers.target shutdown.target
After=time-sync.target -.mount sysinit.target
Triggers=certbot.service
RequiresMountsFor=/var/lib/systemd/timers
Description=Run certbot twice daily
LoadState=loaded
ActiveState=active
SubState=waiting
FragmentPath=/lib/systemd/system/certbot.timer
UnitFileState=enabled
UnitFilePreset=enabled
StateChangeTimestamp=Thu 2020-04-02 10:36:04 CEST
StateChangeTimestampMonotonic=307197325293
InactiveExitTimestamp=Tue 2020-03-31 20:45:30 CEST
InactiveExitTimestampMonotonic=170963190579
ActiveEnterTimestamp=Tue 2020-03-31 20:45:30 CEST
ActiveEnterTimestampMonotonic=170963190579
ActiveExitTimestampMonotonic=0
InactiveEnterTimestampMonotonic=0
CanStart=yes
CanStop=yes
CanReload=no
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=yes
OnFailureJobMode=replace
IgnoreOnIsolate=no
NeedDaemonReload=no
JobTimeoutUSec=infinity
JobTimeoutAction=none
ConditionResult=yes
AssertResult=yes
ConditionTimestamp=Tue 2020-03-31 20:45:30 CEST
ConditionTimestampMonotonic=170963176874
AssertTimestamp=Tue 2020-03-31 20:45:30 CEST
AssertTimestampMonotonic=170963176882
Transient=no
Perpetual=no
StartLimitIntervalSec=10000000
StartLimitBurst=5
StartLimitAction=none
InvocationID=89108875dbdd41d1a33f85f50ee9cb92

It also appears in the timers list as

$ systemctl list-timers
Thu 2020-04-02 18:01:17 CEST  2h 25min left Thu 2020-04-02 10:35:25 CEST  5h 0min ago  certbot.timer                certbot.service

So everything actually looks good to me, but just to be sure: Can I rely on the timer to renew the certificate without any further intervention from my side?

My domain is: photon.serverpit.com

I ran this command: sudo certbot --nginx

It produced this output: https://pastebin.com/Gzna3aQg

My web server is (include version): nginx 1.10.3

The operating system my web server runs on is (include version): Raspbian GNU/Linux 9.11 (stretch)

My hosting provider, if applicable, is: none

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): 0.28.0

Thanks!

2

Does your automatic renewal work? Then yes. You'll get emails starting from 20 days before expiration if it doesn't.

(You can check if it works with certbot renew --dry-run)

1 Like
3

Thanks for the quick reply! Yep, dry run worked fine, I was rather concerned about automated execution. Actually, there was one strangeness. I registered two domains, however the dry run seems to have renewed only one of them. Here is the output:

$ sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/tpiq.lmu.serverpit.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for photon.serverpit.com
http-01 challenge for tpiq.lmu.serverpit.com
Waiting for verification...
Cleaning up challenges

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/tpiq.lmu.serverpit.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/tpiq.lmu.serverpit.com/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

The part

new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/tpiq.lmu.serverpit.com/fullchain.pem

mentions only one of the two domains. Is that a problem?

Thanks!

4

That's not the case. It renewed one certificate

Processing /etc/letsencrypt/renewal/tpiq.lmu.serverpit.com.conf

with two domains:

Performing the following challenges:
http-01 challenge for photon.serverpit.com
http-01 challenge for tpiq.lmu.serverpit.com
1 Like
5

Ah, I see, so that was just the name of the common certificate. Thanks for the explanation!

6

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