Cron job fails to renew certificate

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: negro.colmena.biz

I ran this command: Cron <root@negro> sleep $RANDOM && /usr/bin/certbot -n renew

It produced this output:

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

Processing /etc/letsencrypt/renewal/colmena.biz.conf

Cert is due for renewal, auto-renewing...
Non-interactive renewal: random delay of 71.1689365956 seconds
Could not choose appropriate plugin: The nginx plugin is not working; there may be problems with your existing configuration.
The error was: NoInstallationError("Could not find a usable 'nginx' binary. Ensure nginx exists, the binary is executable, and your PATH is set correctly.",)
Failed to renew certificate colmena.biz with error: The nginx plugin is not working; there may be problems with your existing configuration.
The error was: NoInstallationError("Could not find a usable 'nginx' binary. Ensure nginx exists, the binary is executable, and your PATH is set correctly.",)

All renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/colmena.biz/fullchain.pem (failure)

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

My web server is (include version):

1:1.20.1-9.el7

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

CentOS 7

My hosting provider, if applicable, is: Hostinger

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 1.11.0

2

Are you using nginx ?
which nginx
find / -name nginx

Did you recently update or recompile nginx ?

You wrote:

I don't get what that means.

1 Like
3

That's the version of nginx installed -- el7 stands for Enterprise Linux 7 -- and those packages as compiled and distributed by ius are also compatible with CentOS 7 which is more or less the free version of Red Hat Enterprise Linux 7.

/usr/sbin/nginx

I almost forgot I am using Cloudflare for caching, content distribution, and DDOS protection.

The server name domains amarillo.colmena.biz and negro.colmena.biz are not cached or protected behind the ddos wall but the others are. It's free and I can get by with fewer resources.

Unfortunately Certbot does not appear to be compatible with Cloudflare, because Cloudflare terminates the SSL and re-proxies the connection, so it has to be authorized in addition to Letsencrypt on the CAA in order for that to work, although it will optionally verify the letsencrypt certificate on the server when making the proxy connection.

4

I'm not sure how any of that adds towards a solution.
If you are renewing, then there was a cert issued that way [using --nginx].
If they worked before [some unknown event] and now it no longer works, then "something" broke it.
We can do one of three things:

  • spend a lot of time trying to figure out what broke and then how to fix it
  • uninstall certbot & nginx - then reinstall them
  • try other method(s) [instead of using --nginx (auth/installer)]
    Like: certonly --webroot
    Other ACME software [acme.sh]
1 Like
5

Does that command work from a 'normal' shell prompt? Is it failing only from cron?

(use sudo if needed)

6

Sorry if this is not appropriate or getting off track. I think I remember what happened three/six months ago.

It's the ddos content distribution caching proxy getting in the way, and if you ask those folks you don't even certbot because they offer SSL termination for free and you can have a self signed certificate on your web server for them, and it will be proxied commercially, which works for web but obviously not for an email server because nobody in that commercial zone wants to risk the civil liability of lifting a finger to help a spammer.

So it all depends to what extent certbot/letsencrypt is compatible or "supported" on Cloudflare, which is more of a political problem than a technical problem, sort of like an online city hall business permit, FBI background check and everything.

And that's a TANSTAAFL situation where any and all free software related stuff is somehow becoming progressively "hacked" or subtly disabled, crippled, prevented from working with WONTFIX bugs because there's aggressive "traffic shaping" on the internet backbone in an environment where "free" stuff is unwanted because it competes with someone else's paid non-free offering on some other platform but the big Silicon Valley tech cártel obviously isn't the pure capitalist free market they're claiming it is from a certain fringe element of politics with mental health trusts and intellectual property law, which is an area where the powdered wigs need to ripped off the barristers' heads for every tiny detail or else nothing ever works right the way it's supposed to.

7

The command works fine and successfully renews from the command line.

It only fails when installed as a cron job.

8

Please show output of:
crontab -l

2 Likes
9

0 0 * * * sleep $RANDOM && /usr/bin/certbot -n renew

10

The exact same cron job also fails on amarillo.colmena.biz for a different reason because that vm is on a different network with a firewall that seizes up and ends up blocking all outgoing connections unless it has just been manually reset.

From: "(Cron Daemon)" <root@colmena.biz>
To: root@colmena.biz
Subject: Cron <root@negro> sleep $RANDOM && /usr/bin/certbot -n renew
Content-Type: text/plain; charset=ANSI_X3.4-1968
Auto-Submitted: auto-generated
Precedence: bulk
X-Cron-Env: <XDG_SESSION_ID=32891847>
X-Cron-Env: <XDG_RUNTIME_DIR=/run/user/0>
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>
Message-Id: <20220129021547.B9CCC82E50@negro.colmena.biz>
Date: Sat, 29 Jan 2022 02:15:47 +0000 (UTC)

====

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/colmena.biz.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not yet due for renewal

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The following certificates are not due for renewal yet:
  /etc/letsencrypt/live/colmena.biz/fullchain.pem expires on 2022-04-28 (skipped)
No renewals were attempted.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

=====

11

Your PATH seems wrong for the cron job. Should find nginx the same as in shell but does not. Many ideas for fixing such as:

2 Likes
12

Indeed.

The root crontab does not have /sbin and /usr/sbin in its path!

13

There's a bash shell obviously but it has been stripped of its environment. It seems that I've had better luck before calling an explicit shell on every cron job. The complication to this method of "doing it right" is that any arguments with special characters need to be quoted or escaped one by one from the stripped shell and passed to the new shell which has been invoked explicitly with a default environment.

0 0 * * * /bin/bash sleep "$RANDOM" "&&" /usr/bin/certbot -n renew

Untested as yet.

14

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