I ran this command: I can't find the command that actually requests renewal automatically. It seems to be set up to use ? Systemctl times so I found where the files were and none of them contain any certbot renewal commands????
The last time I tried this renewal didn't work until I changed the certbot renewal command so this I really need to know so I can sleep at night.
My web server is (include version): apache 2.3
The operating system my web server runs on is (include version): RHEL 7
I can login to a root shell
The version of my client is the latest
This is all I find in the systemctl timers:
#snap.certbot.renew.service
[Unit]
# Auto-generated, DO NOT EDIT
Description=Service for snap application certbot.renew
Requires=var-lib-snapd-snap-certbot-3024.mount
Wants=network.target
After=var-lib-snapd-snap-certbot-3024.mount network.target snapd.apparmor.service
X-Snappy=yes
[Service]
EnvironmentFile=-/etc/environment
ExecStart=/usr/bin/snap run --timer="00:00~24:00/2" certbot.renew
SyslogIdentifier=certbot.renew
Restart=no
WorkingDirectory=/var/snap/certbot/3024
TimeoutStopSec=30
Type=oneshot
#snap.certbot.renew.timer
[Unit]
# Auto-generated, DO NOT EDIT
Description=Timer renew for snap application certbot.renew
Requires=var-lib-snapd-snap-certbot-3024.mount
After=var-lib-snapd-snap-certbot-3024.mount
X-Snappy=yes
The line here that causes the renew to be invoked is
The meaning of certbot.renew in the Certbot snap is defined here:
A copy of this snapcraft.yaml file is (somewhere) inside of the installed snap, so that the snap command can find it.
The actual command it's running is then
bin/python3 -s $SNAP/bin/certbot -q renew
This is basically a form of the certbot renew command, which is Certbot's command to check whether renewals are required and attempt them if necessary.
The details of which certificates to check for renewal period, and how to attempt to renew any given certificate, are kept by Certbot in files in /etc/letsencrypt, mainly /etc/letsencrypt/renewal. For example, if you provided options like a particular DNS API credential or a particular webroot path or a particular web server application integration plugin, those would be kept in that file and certbot renew would read them out when attempting a renewal.
If you're not sure whether your renewals will succeed or not but you want to check, you can run
certbot renew --dry-run
This attempts to simulate a renewal of your certificates using the Let's Encrypt staging server, which checks challenges in a very similar way to the real Let's Encrypt service, although it doesn't issue publicly-trusted certificates as a result of this test. It uses the same options that the real renewal will use when it's due, so usually it will succeed if the real renewal would succeed, and will fail if the real renewal would fail.
I'm not familiar with any of the things required to make this change but I think I could follow it based on your instructions. It was a billion times less complex when it was made using crontab. I would like to have had a choice what task schedule method while installing. I would have picked the simplest one.
Command change
from back in 2020 on a sever that has since been decommissioned every --dry-run test ran and said renewal would succeed until the cert actually tried to renew from the scheduled task which always failed. Until I modified the renew command in crontab.
The command change to the scheduled renewal was this
sudo certbot renew --webroot -w /var/www/html/
Here are the only notes I have about making that change:
sudo certbot renew --webroot -w /var/www/html/
I was trying things all day though so there may be other factors.
The server was not at all responding to web requests made to the temp folder alias that the verification ID file was supposed to go in so I made a actual folder on the server for that challenge ID and it didn't help. Someone on the forum told me that wouldn't work because the challenge folder is made off a different folder than the servers actual web root.
Then I remembered I had just read in the manual there was a command modifier that you could use to tell it to use any Webroot folder you wanted BUT it was discussed only in the context of manual certificate download.
The command with --webroot above is nowhere in the documentation for auto-renewal but it made sense to me so I tried it and boom shaka-laka, shakalaka boom.
The renew command uses the same method and options to get a replacement cert that you used to obtain the original.
When you obtain a new cert (or update the method used), the /etc/letsencrypt/renewal folder contains a conf file with these options. The renew command just uses this conf file.
It is unusual to modify the renew command like you have. It indicates something has changed in your server config since your last cert. It would be better to re-get the cert or update the renewal config using the certbot reconfigure command. Although this requires a version 2.x of Certbot or later.