Certbot's renewal error

Hello!

It is now less than a month before my certificate expires and it tried to auto-renew, but there was an error.
I have LAMP on Ubuntu 14.04 and Apache ver. is 2.4.7
I checked cron’s log and it worked. It’s set daily on 20:48. Letsencrypt’s log shows a GMT time (my time minus 3 hrs.) Then I restarted Apache and even my computer and it still didn’t renew. Then I checked letsencrypt’s log and there it says among other things:

2016-12-03 17:48:05,823:INFO:certbot.renewal:Cert is due for renewal, auto-renewing…

2016-12-03 17:48:05,904:WARNING:certbot.renewal:Attempting to renew cert from /etc/letsencrypt/renewal/kotkovski.com.conf produced an unexpected error: The apache plugin is not working; there may be problems with your existing configuration.

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

What’s going on and what should I do?

Try “manually” (i.e., not certbot renew) getting the certificate (i.e., use the same command line as before just in case it actually works :stuck_out_tongue:) and see what kind of error certbot throughs at you then.

Thanks!

I managed to renew the certificate manually. As root I did this:

./letsencrypt renew

in the directory /root/.local/share/letsencrypt/bin

Now what? Should I drop my cronjob that failed? This one:

48 20 * * * /home/kot/Downloads/cert/certbot-auto renew --quiet --no-self-upgrade

And instead to make a new cronjob. Something like this:

48 20 * * * /root/.local/share/letsencrypt/bin/letsencrypt renew

Beats me, I didn't expect your ./letsencrypt renew to work, because it complained about an Apache error before.. Do note that letsencrypt is the old name for the EFF client and probably misses some new functionality and/or bug fixes. That said, it apparently does work for you :stuck_out_tongue:

@bmw @erica, could one of you take a look at this error?

Your existing cron job should be preferred over the simple letsencrypt renew command. Are you able to provide more thorough logs of the failure you were getting? There should be information in there about why Certbot couldn't use the Apache plugin.

Just to clarify this, when using certbot-auto or letsencrypt-auto there is both a certbot and letsencrypt executable in ~/.local/share/letsencrypt/bin/. The letsencrypt executable is simply a shim for certbot and exists for people who were manually running the letsencrypt command before we renamed the project.

This is a special case, however. In general, you're correct that some of the letsencrypt executables out there are missing all functionality/patches we've added in the last ~9 months.

1 Like

letsencryptlog.txt (8.5 KB)

Here’s my let’s encrypt log file with an error. I’ve got a newer one in which I managed to renew the certificate manually. Had to change its extension in order to upload it here though. In Linux it doesn’t make any difference, as you probably know.

Okay, so what can go wrong if I keep on using my certificate after the renewal done the way I did it.
I understand that it’s not the best way, but still, is it usable? Seems to be working fine.

Anyhow, for a time being I won’t touch my cronjobs so we can try to figure out what went wrong with my certbot job. Strange that after the initial certbot usage, I made a dry run to check if it would renew OK.
It showed no errors back then. And now it doesn’t renew for some reason.

Apache and your certificate should be totally fine.

I think what’s going on here is a PATH problem. Certbot’s Apache plugin uses the executable apachectl/apache2ctl and when Certbot failed, it couldn’t find it. I think when you ran Certbot yourself in a shell (including the time you ran a dry run) the command is in your PATH, but it isn’t in cron.

You can verify this by following running command -v apachectl || comand -v apache2ctl to see where the executable is located. To see what PATH is used in cron, you can follow instructions similar to the accepted answer here. If the directory containing apachectl/apache2ctl isn’t in your PATH, this is the problem.

This problem has hit us in the past as documented here. If apachectl/apache2ctl is in /usr/sbin (or /usr/local/bin or /usr/local/sbin) the problem can be fixed by upgrading Certbot (which can be done by running something like certbot-auto --version and verifying the output says 0.9.3). If this doesn’t seem to be the problem or apachectl/apache2ctl isn’t in one of the three paths above, let me know!

1 Like

SOME UPDATE

When I ran this command in the terminal:

command -v apachectl || comand -v apache2ctl

I got this:

/usr/sbin/apachectl

Then I ran this command from within a directory where certbot-auto is located:

sudo ./certbot-auto --version

I think it said that it had to be upgraded from some version (not sure, but I think it started with 0.8.x) to 0.9.3 Couldn’t see that since it disappeared from terminal screen very fast.

I got this:

Creating virtual environment…
Installing Python packages…
Installation succeeded.
letsencrypt 0.9.3

Now what? After upgrading certbot, next time it should do the job ok (by that I mean running a cronjob with this command in it (certbot-auto renew --quiet --no-self-upgrade)

OR I still have to take care of PATH problem? Frankly, I didn’t take care of that yet. Just did what I described here.

You should be go. Starting with 0.9.0, if apachectl can’t be found in your PATH, we manually check /usr/sbin. In your case, we’ll find it and you shouldn’t have a problem.

Okay, great! Thanks a lot!
I hope that in about two months time when renewal is due, everything will work as it should. In any case, I won’t change anything in the system as far as cron and let’s encrypt are concerned.

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