Certbot doesn't seem to autorenew on my Debian 9.8 installation


#1

I noticed my certificate is not getting renewed (it will expire in 7 days, so it should have been by now). I checked my crontab, and discovered nothing was there to trigger an auto-renew. I checked the documentation, but was disappointing: the Documentation simply states that certbot will make a script on installation and insert a rule in crontab to run it. It doesn’t say how to check if that has happened. It doesn’t say what to do if that has not happened.

I noticed there is no such thing as certbot-auto on my installation, only certbot itself.
I did run certbot renew --dry-run a while back, and it passed without any issues.
I do see a systemd certbot.timer

How do I make sure that certbot is scheduled to auto-renew? If it is not properly scheduled, how do I fix that?


My domain is:
[withholding because I don’t want to make public that I am the maintainer for that domain]

I ran this command:
sudo ctontab -e

It produced this output:
Nothing. An empty crontab.
But when I run systemctl list-timers I do see certbot.timer

My web server is (include version):
nginx 1.14.12

The operating system my web server runs on is (include version):
Debian 9.8

My hosting provider, if applicable, is:
unrelated

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.10.2


#2

Where does it say that exactly? In the Using Guide it only refers to the distributions with packages installing cronjobs or systemd timers. certbot itself won’t do that.

Further more, it matters how you installed certbot. Also, on Debian stretch, the current version of certbot is 0.28. How on earth did you end up with version 0.10.2?

Looking at the changelog for certbot-python on Debian, a cronjob is shipped since version 0.6.0.


#3

Ah right, that I read on some website, not in the docs. I shouldn’t have cited that.

Let’s only go by what the docs say. “Many Linux distributions provide automated renewal when you use the packages installed through their system package manager.”
So in what way is auto-renewal provided? Does it require any additional actions? How do I check I have indeed been provided with auto-renewal? How to correct this if auto-renewal is not properly set up?

The docs tell me to check crontab and systems timers. I did that, but don’t know how to proceed.


#4

systemctl list-timers” has columns that show whether a timer has been been running. Has it?

What does “sudo certbot certificates” show?

What does /var/log/letsencrypt/letsencrypt.log say Certbot has been up to?


#5

You can see that in the table provided in the docs I linked to: cron and/or systemd.

If the package used provides for a cronjob and/or systemd timer: no.

Run crontab -l as root and/or systemctl list-timers --all.


#6

yes it has
it ran 5 hours ago and is scheduled to run again in about 6 hours

This shows something very interesting, it shows to be valid for another 67days! this does not match what I see on-line, for example with ssl-labs. I think I am onto something.

The site has been switched to a placeholder, on the same domain, but wit ha different webroot-path. I suspect I might be renewing the certificate for the official site, but not for the placeholder which is currently on-line.

I will answer the other question and give feedback to the suggestion of @Osiris in a few moments.


#7

If your original site as well as the placeholder use the symbolic links in /etc/letsencrypt/live/, everything should work when renewed.

If you didn’t use the apache or nginx installer plugin, you also need to manually reload your webserver after renewal if you didn’t add some sort of reload command in a --deploy-hook.


#8

I do not remember adding a system timer, yet a system timer exists.

The same as before: there are no cronjobs listed, there is a systemd timer for certbot listed.

looks normal: it has a debug entry from today showing it querying ocsp (which is configured for this domain)

Could it be that the change in webroot-path means I am still renewing a certificate for the official site but not for this placeholder? Thee domain is still exactly the same.


#9

Let me read up on that to figure out if I have or not.


#10

I suspect this was the case. I installed python-certbot-nginx

The last time I configured certbot I used this command:

sudo certbot certonly --agree-tos --redirect --uir --hsts --staple-ocsp --must-staple --rsa-key-size 3072 -a webroot --webroot-path=/srv/webroot/exampleplaceholder -d example.com -d www.example.com

should I rerun this with --nginx? If I do that, may I expect automation to work from that point on?

sudo certbot --nginx certonly --agree-tos --redirect --uir --hsts --staple-ocsp --must-staple --rsa-key-size 3072 -a webroot --webroot-path=/srv/webroot/exampleplaceholder -d example.com -d www.example.com

Note I use certonly, as I prefer to do some stuff manually so I gain an understanding for it.


#11

Hi,

In this case, you can try to use the following arguments to set the installer to Nginx.
sudo certbot renew -i nginx --cert-name example.com (The certname should match the one that was outputed by certbot certificates) and it would then install the certificate / reload nginx after renewal.

Thank you


#12

I am struggling to understand the difference between sudo certbot --nginx certonly and sudo certbot -i nginx

I also notice your command seems to only address renewal sudo certbot renew -i nginx --cert-name example.com

Does sudo certbot renew -i nginx --cert-name example.com make any changes to my nginx configuration? (I would like to understand what I am doing when I run that.)


#13

I have run sudo certbot renew -i nginx
The output shows no certificates due for renewal

I checked /etc/letsencrypt/renew/example.com.conf
In the conf I notice the webroot is pointing correctly to the placeholder, so that was not the issue for sure.

I checked ssllabs and it still shows the certificate will expire in a little over 7 days (which would normally be reason to renew)

It seems the certificates have been renewed, but nginx isn’t reloaded to serve the renewed certificates. (Thanks @Osiris for pointing that out, you were right)
Will it auto reload next time now that I have installed python-certbot-nging and I have run sudo certbot renew -i nginx ?


#14

Not really…

You might need to dig in to that conf file.
There should have one line like the following:

installer = nginx

If there aren’t a line stating installer, add the above line below the "authenticator“ line and save the file.
(The above line means certbot would try to install the certificate automatically to your nginx server)

Thank you


#15

I altered example.com.conf
installer = None
to read
installer = nginx

hope that triggers nginx to update and thus serve the new certificate from now on

I realize this particular part of the configuration is hard to test without waiting for a while. it might only get triggered when the actual certificate expires in 30 days (that takes another 37 days in my case) while the served certificate will expire long before that 7 days from now. I may have to manually reload nginx between now and 7 days and just hope the next reload will indeed be automated.


#16

Hi,

If you have a certificate that is close to expiring, you can change the configuration file for that certificate and do sudo certbot renew --force-renewal --cert-name the-certificate-name.

Thank you


#17

Thank you for pointing that out, but I know I can force renewal. What I don’t know is if the next time the certificate is about to expire, nginx will properly reload after renewal. Is there a way to test if nginx will reload automatically?


#18

Maybe I can force a short lived certificate to trigger a renewal within an hour, so I can see if nginx also reloads?


#19

Yes. That’s why i’m saying you could do force renewal.

Because when you force renewed the certificate (the one that you’ve set Installer to Nginx), you could check if that certificate is loaded on your website.

If the certificate that your web server served is the certificate you just force-renewed, then there’s prove that Nginx was reloaded following the renewal.

Thank you


#20

That makes perfect sense actually. Thanks for elaborating.

I preformed the forced renewal and I confirmed that without any manual action nginx did indeed relaod the certificate. It looks like my problem has been fully resolved.

Thank you to all the kind people who helped me solve an issue I could have prevented, if only I had used the nginx plugin from the start. I certainly learned about the importance of that plugin.

I have one final question, if I were to add a new certificate some day, do I use --nginx:

sudo certbot --nginx certonly --agree-tos --redirect --uir --hsts --staple-ocsp --must-staple --rsa-key-size 3072 -a webroot --webroot-path=/srv/webroot/somenewsite -d somenewsite.com -d www.somenewsite.com

or is the proper syntax -i nginx

sudo certbot -i nginx certonly --agree-tos --redirect --uir --hsts --staple-ocsp --must-staple --rsa-key-size 3072 -a webroot --webroot-path=/srv/webroot/somenewsite -d somenewsite.com -d www.somenewsite.com ?