HELP! Certbot not renewing Let's Encrypt Certificate

[darientan]

The operating system my web server runs on is:

• Ubuntu 16.04
• Apache

My hosting provider is:
Digital Ocean

I can login to a root shell on my machine:
Yes

I'm using a control panel to manage my site:
No

My domain is: www.addictivebakes.com

Here's the details:

I ran this command: crontab -e
Subsequently, I added "15 3 * * * /usr/bin/certbot renew --quiet " to the bottom of the script. It was supposed to renew my Let's Encrypt Certificate automatically.

However, Let's Encrypt Certificate did not renew automatically. Had to run "./certbot-auto renew" to renew the certificate manually. It was successful and this was the output.

root@AddictiveBakes:~# ./certbot-auto renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

---

Processing /etc/letsencrypt/renewal/addictivebakes.com.conf

Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for addictivebakes.com
http-01 challenge for www.addictivebakes.com
Waiting for verification...
Cleaning up challenges

---

new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/addictivebakes.com/fullchain.pem

---

Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/addictivebakes.com/fullchain.pem (success)

root@AddictiveBakes:~# ./certbot-auto certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

---

Found the following certs:
Certificate Name: addictivebakes.com
Domains: addictivebakes.com,www.addictivebakes.com
Expiry Date: 2017-12-08 03:35:00+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/addictivebakes.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/addictivebakes.com/privkey.pem

How do I set up a cronjob that will automatically renew the certificate in the future so that I do not have to do the renewal manually? Thanks a lot for any help!
P.S. The following link provides the entire explanation on the method which I set up my Let's Encrypt certificate for my website (HELP! Let's Encrypt and CloudFlare: Error 526 when using Full(Strict) SSL. (Ubuntu 16.04 & Apache)). Hope this provides sufficient information to resolve this issue. Thanks!

[mnordhoff]

The cron job is set to run /usr/bin/certbot, but the command you ran to renew it manually was /root/certbot-auto.

Does /usr/bin/certbot exist? Does it work? Maybe it’s an older version of Certbot that’s unable to renew successfully due to a newer feature or bug fix you rely on?

Do you have cron’s logs? Are there Certbot logs from the cron attempts in /var/log/letsencrypt?

As a side matter, this isn’t very important, but it helps spread out load on the Let’s Encrypt servers if the cron job doesn’t run at the exact same time every day. (03:15 is probably alright. 00:00 would be a problem, for example.)

Some Certbot packages do something like this to ensure it runs at a more random time (twice a day):

0 */12 * * * perl -e 'sleep int(rand(3600))' && /path/to/certbot -q renew

[darientan]

Hi mnordhoff, thanks for taking the time to look through this question.

1. I ran the command "cd /usr/bin/certbot" and it returned this

-bash: cd: /usr/bin/certbot: No such file or directory

I guess this means it does not exist? I'm not sure. (Sorry, I'm new to this).

2. When I run "/var/log/letsencrypt# ls", it returns this:

letsencrypt.log letsencrypt.log.12 letsencrypt.log.5 letsencrypt.log.9
letsencrypt.log.1 letsencrypt.log.2 letsencrypt.log.6
letsencrypt.log.10 letsencrypt.log.3 letsencrypt.log.7
letsencrypt.log.11 letsencrypt.log.4 letsencrypt.log.8

How do I navigate to determine if I do have the cron's logs?

Is there a specific code which I can replace the cronjob "15 3 * * * /usr/bin/certbot renew --quiet " ? Would the following line work?

0 */12 * * * perl -e 'sleep int(rand(3600))' && /path/to/certbot -q renew

[schoen]

Hi @darientan,

I can let @mnordhoff confirm the detailed answers, but I wanted to point to a couple of misconceptions that I thought I saw in your reply here:

First, to find out if a command exists, you can run ls (among other options). cd means “change directory” and should only be used with directories, not files. On Unix, all programs are files¹ which exist within some directory or other.

In this case, you could run ls /usr/bin/certbot to see if you have this file. However, the particularly error that you received already shows that it doesn’t exist. When you try to cd to a file, you can get two different errors:

bash: cd: /usr/bin/certbot: No such file or directory
(means it doesn’t exist at all)

bash: cd: /usr/bin/certbot: Not a directory
(means it does exist, but is a file so you can’t cd into it!)

Since you got the former error, you discovered that it doesn’t exist at all.

And I think it’s this that’s the underlying cause of your problem because whenever you read a tutorial or documentation that refers to /usr/bin/certbot, it’s intended for people who installed Certbot via different method than you did (using an OS package instead of the cerbot-auto autodownloader). Any reference to this path will not work properly on your system because this file doesn’t exist at this location.

However, when @mnordhoff (or any tutorial or documentation) refers to /path/to/certbot, this is a convention that means that you should actually write the location where the Certbot program exists on your system, rather than the literal string /path/to/certbot. On your system, this is /root/certbot-auto. Therefore, you should use /root/certbot-auto instead of /path/to/certbot.

If you use this path in your cron job, it will probably work properly. The encouraging thing is that when you ran /root/certbot-auto renew, you had a successful renewal, as you pointed out. Therefore, running versions of this command from cron will most likely also result in successful renewals (although you might not know for another 60 days because certbot-auto renew doesn’t try to do anything at all unless it finds a certificate that’s less than 30 days from expiry).

¹ Well, except for aliases and shell built-in commands, such as cd itself.

[darientan]

Hi @schoen,

Thank you for your detailed explanation. It was very insightful and easy to understand - I really appreciate it.
I have replaced my cronjob from

15 3 * * * /usr/bin/certbot renew --quiet

to

15 3 * * * /root/certbot-auto renew --quiet

This should hopefully work.
Or maybe, the following will work better?

0 */12 * * * perl -e ‘sleep int(rand(3600))’ && /root/certbot-auto -q renew

Yes, and l'll wait for @mnordhoff to confirm the detailed answers.

[schoen]

In this case, -q is a synonym for --quiet.

The difference between 15 3 * * * and 0 */12 * * * perl -e ‘sleep int(rand(3600))’ && is that the former means “every day at 3:15 a.m., do this”, while the latter means “every day at both midnight and noon, wait a random number of seconds up to an hour, and then do this”.

Both of these reflect a concern of the Let’s Encrypt CA not to have every user trying to renew at exactly the start of the hour, which would create unnecessary load on the CA compared to having renewals spread out at more random times.