My domain is: server.eyethrees.net
My web server is: Apache v2.4.6
The OS my web server runs on is: centos-release-7-7.1908.0.el7.centos.x86_64
I can login to a root shell on my machine: yes
I’m using a control panel to manage my site: Webmin v1.94 1
The version of my client is: certbot version 1.0.0
so after installing my certs I used the following command to edit the crontab for renewal as recommended by the install page ( https://certbot.eff.org/lets-encrypt/centosrhel7-apache.html ) echo "0 0,12 * * * root python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew -q" | sudo tee -a /etc/crontab > /dev/null
the crontab seems to be running: tail of /var/log/cron shows May 16 12:00:01 server CROND[34615]: (root) CMD (python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew -q)
but i’ve gotten two emails about expiration … 30days out and 20days out now…
i could run the renewal manually (but i did that last time)
$cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# For details see man 4 crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed
0 0,12 * * * root python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew -q
Hmm. I don’t think those installation instructions should be suggesting setting up a separate renewal cron. I believe the certbot package from EPEL comes with renewal tasks already:
systemctl status certbot-renew.service
journalctl -u certbot-renew.service
Do those show that Certbot has been running on its own?
You might also want to consider going through some of the recent files in /var/log/letsencrypt/, find the logs from a couple of days ago, they should document why renewal failures have been occurring, if any.
If you’ve issued a new certificate that adds or removes a name relative to your old certificate, you will get expiration email about your old certificate
Sorry for the false alarm with the systemd timer - TIL it comes disabled by default.
you are correct that the email expiration warning is for my old certificate certbot certificates shows my current cert (without the www domains) valid for another 4 weeks
thanks for the help
Yes. Take a look in /var/log/letsencrypt/ through some of the recent logs.
Some of them (maybe letsencrypt.log or letsencrypt.log.1 or something) should have tried to renew your certificate. If something went wrong, the reason for the failure should be there.
not sure their solution of a 'rouge www ServerAlias" applies to me, but maybe...
one thing that i think might help is that the log seems to create the .well-known validation challenges all under server.eyethrees.net but then the file not founds are all .well-known directories under each vhost's domain
my 'webroot path' in /etc/letsencrypt/renewal/server.eyethrees.net.conf is /var/www/html/server.eyethrees.net,
is the comma supposed to be there? is the webroot supposed to be just /var/www/html?
It looks like your domains all have distinct webroots … so the renewal configuration would need to reflect that, in order to be able to renew your certificate.
Usually when using the webroot plugin is used with multiple distinct domains, you would specify each domain’s webroot separately. The resulting renewal config file would look something like:
Otherwise, as in your case, it would try to authenticate each domain using the same /var/www/html/server.eyethrees.net webroot, which is probably not right. The result would be the unauthorized errors you saw.
Since you are using Apache anyway, perhaps consider trying using the Apache plugin as your authenticator. In general, it does things a lot more “automagically” than the webroot plugin.
You could test it out without any commitment with:
certbot renew --cert-name server.eyethrees.net -a apache --dry-run
Otherwise, I think you’d need to fix up your webroot config.