Certbot command fails from cronjob, but works fine when I run it manually

Help
1

Hi

I have installed certbot from snap as recommended and generated my first certificates. I run certbot with certonly and DNS authenticator plugin (dns-domeneshop). When I manually run a renew command which checks and eventually renews the certificates, everything seems to work fine as well. But when I set up the very same command as a cron job for root user, it fails.

How can I set up cron job so certificates can renew automatically?

My domain is:
infinitum.no

I ran this command:

sudo crontab -e

          • /bin/bash -c "date >> /var/log/letsencrypt/renew.log; /usr/local/bin/certbot --version >> /var/log/letsencrypt/renew.log; /usr/local/bin/certbot renew >> /var/log/letsencrypt/renew.log"

The line above is the content of crontab for the root user. Apparently, the command logs the date and version in custom log file (renew.log) and finally tries to renew all letsencrypt certificates.

It produced this output:
(since command i run from crontab, this is output from the custom log file, renew.log)

Tue Apr 27 23:36:01 UTC 2021
Tue Apr 27 23:37:01 UTC 2021
Tue Apr 27 23:38:01 UTC 2021
Tue Apr 27 23:39:01 UTC 2021
Tue Apr 27 23:40:01 UTC 2021

(so nothing but the date command is logged. Renewal is not being attempted!)

I ran this command:

sudo /bin/bash -c "date >> /var/log/letsencrypt/renew.log; /usr/local/bin/certbot --version >> /var/log/letsencrypt/renew.log; /usr/local/bin/certbot renew >> /var/log/letsencrypt/renew.log"

It produced this output:
(output from the custom log file, renew.log)

Tue Apr 27 23:44:49 UTC 2021
certbot 1.14.0

Processing /etc/letsencrypt/renewal/dev.infinitum.no.conf

Processing /etc/letsencrypt/renewal/infinitum.no.conf

Processing /etc/letsencrypt/renewal/test.infinitum.no.conf

The following certificates are not due for renewal yet:
/etc/letsencrypt/live/dev.infinitum.no/fullchain.pem expires on 2021-07-25 (skipped)
/etc/letsencrypt/live/infinitum.no/fullchain.pem expires on 2021-07-25 (skipped)
/etc/letsencrypt/live/test.infinitum.no/fullchain.pem expires on 2021-07-25 (skipped)
No renewals were attempted.

My web server is (include version):
I do not use installer certbot plugin and have no running web server on my certbot linux server. Generated certificates are taken to production by one hook script.

The operating system my web server runs on is (include version):
Ubuntu Linux 18.04.5 LTS (Bionic Beaver)

My hosting provider, if applicable, is:
domeneshop

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

1 Like
3

When you install Certbot from snaps:

  1. The program is installed to /usr/bin/certbot. The copy of Certbot you have at /usr/local/bin/certbot was installed from elsewhere (probably by running pip).
  2. It automatically creates a systemd timer to perform renewal (step 9 here). You don't need to set up a cronjob yourself.

My suggestion would be to do away with the extraneous version of Certbot you have installed at /usr/local/bin/certbot, and the cronjob as well.

2 Likes
4

Note that this has to be done manually, according to the documentation @ certbot.eff.org.

1 Like
5

Hi

Thanks for answering. I am quite sure that I installed certbot only by snap. The only reason why I had to install pip is authenticator plugin from domeneshop and cloudflare. I ran specific commands to install those two plugins by pip, nothing else, but if pip did some background installation of certbot on its own, then I am unaware of it.

In addition I realized that I forgot to create manually a symlink as pointed in the EFF's guide for Ubuntu 18.04
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Now it is in place, but I didn't get any better situation.

The status is - If I run manually "sudo certbot renew" from CLI everything seems to work fine. Cronjob still does NOT execute. I would really like to know why? I don't see the difference between running a command from cron and manually?

At the other hand, if renewal should be let done by systemctl timer so I can live with that. But how can I know if certbot is trying to renew certificates at all? So far I can see certbot in timers but frankly I am not familiar with systemctl and I don't know how it works.

systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Wed 2021-04-28 11:39:00 UTC 1h 56min left Tue 2021-04-27 22:21:02 UTC 11h ago snap.certbot.renew.timer snap.certbot.renew.service
Wed 2021-04-28 11:44:51 UTC 2h 2min left Tue 2021-04-27 11:44:51 UTC 21h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Wed 2021-04-28 17:04:01 UTC 7h left Wed 2021-04-28 00:15:03 UTC 9h ago apt-daily.timer apt-daily.service
Wed 2021-04-28 21:58:00 UTC 12h left Wed 2021-04-28 02:46:03 UTC 6h ago motd-news.timer motd-news.service
Thu 2021-04-29 06:45:51 UTC 21h left Wed 2021-04-28 06:42:49 UTC 2h 59min ago apt-daily-upgrade.timer apt-daily-upgrade.service
Mon 2021-05-03 00:00:00 UTC 4 days left Mon 2021-04-26 00:00:04 UTC 2 days ago fstrim.timer fstrim.service

6 timers listed.
Pass --all to see loaded but inactive timers, too.

Where should I look after eventual logs of renewal attempts?

BR Zertcert

1 Like
6

Additional info. I investigated a bit more my certbot installation by whereis command.

whereis certbot
certbot: /usr/bin/certbot /usr/local/bin/certbot /snap/bin/certbot

There are 3 certbots, or actually 2, since /usr/bin/certbot is just a pointer to /snap/bin/certbot

As one can see in logs below, /usr/local/bin/certbot is the one which works fine, while /usr/bin/certbot doesn't work correct. Both run manually. And still none of them want execute from cron. Why is that?

first certbot variant

sudo /usr/local/bin/certbot renew

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/dev.infinitum.no.conf

Cert not yet due for renewal

Processing /etc/letsencrypt/renewal/infinitum.no.conf

Cert not yet due for renewal

Processing /etc/letsencrypt/renewal/test.infinitum.no.conf

Cert not yet due for renewal

The following certificates are not due for renewal yet:
/etc/letsencrypt/live/dev.infinitum.no/fullchain.pem expires on 2021-07-25 (skipped)
/etc/letsencrypt/live/infinitum.no/fullchain.pem expires on 2021-07-25 (skipped)
/etc/letsencrypt/live/test.infinitum.no/fullchain.pem expires on 2021-07-25 (skipped)
No renewals were attempted.

second variant

sudo /usr/bin/certbot renew

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/dev.infinitum.no.conf

Renewal configuration file /etc/letsencrypt/renewal/dev.infinitum.no.conf (cert: dev.infinitum.no) produced an unexpected error: 'Namespace' object has no attribute 'dns_domeneshop_credentials'. Skipping.

Processing /etc/letsencrypt/renewal/infinitum.no.conf

Renewal configuration file /etc/letsencrypt/renewal/infinitum.no.conf (cert: infinitum.no) produced an unexpected error: 'Namespace' object has no attribute 'dns_domeneshop_credentials'. Skipping.

Processing /etc/letsencrypt/renewal/test.infinitum.no.conf

Renewal configuration file /etc/letsencrypt/renewal/test.infinitum.no.conf (cert: test.infinitum.no) produced an unexpected error: 'Namespace' object has no attribute 'dns_domeneshop_credentials'. Skipping.

No renewals were attempted.

Additionally, the following renewal configurations were invalid:
/etc/letsencrypt/renewal/dev.infinitum.no.conf (parsefail)
/etc/letsencrypt/renewal/infinitum.no.conf (parsefail)
/etc/letsencrypt/renewal/test.infinitum.no.conf (parsefail)

0 renew failure(s), 3 parse failure(s)

1 Like
7

Hey,

It looks like your problem is caused by using a mix of different installation methods for Certbot and the DNS plugin.

If installing Certbot via snap, any DNS plugins need to be installed via snap as well. Unfortunately it doesn't look like the authors of the certbot-dns-domeneshop project have made their plugin available as a snap.

The next best thing is to install Certbot via pip instead of via snap. You can find the official instructions for doing so here.

Please note that this is different to the way that you have installed Certbot using pip.

That page also has instructions on how to correctly set up a cron job for the pip edition of Certbot.

If you intend to use this method to install Certbot (and the domeneshop plugin), you should remove the Certbot snap (snap remove certbot).

2 Likes
8

Thanks, _az!

It makes sense. I think I will spin up a new VM and deploy it all over again from scratch by pip (pip3 to be precise). The reason behind is that I am quite dependent on the named authenticator plugin.

I am curious, what are pros/cons in certbot installation by snap vs pip3? As far as I can see, both binaries on my server are in version 1.14.0.

1 Like
9

Thanks, one more time, _az!

I did follow pip installation guide and ended up with fully working certbot with cron as automation engine.

Issue solved! :slight_smile:

However, it would be nice if anybody could point out what are cons and pros between snap and pip deployments. Clearly I had to go for pip because of plugin, but I also understand that cerbot prefers snap. Why?

2 Likes
10

snaps provide a way for the Certbot and its plugins to be packaged, distributed and installed in a relatively foolproof way for ~all Linux distros. This avoids some issues which have come up historically: broken Python installations on the system, lack of updates/upgrades and automatic upgrade (esp. on "stable" distros), no automatic cronjob, reliance on external packagers.

The pip instructions were later added for when snap isn't an option (like with your DNS plugin). It is more involved to setup, lacks automatic upgrade and setup of the cronjob, but is still pretty good.

4 Likes
11

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