How to set auto-renewal of Let's Encrypt SSL?

simii

New Member
#1
I have an AWS EC2 instance running OpenLiteSpeed, with multiple sites/domains hosted on it.

Everything works fine, but is there a way to set up the auto-renewal of SSL certificates (Let's Encrypt ones)?
 

gilles

Active Member
#2
There is no way to do it directly through OLS. The easiest is probably to set up a cron job calling certbot directly or install certbot as systemctl service ("apt install certbot" on Ubuntu).
 

Cold-Egg

Administrator
#3
Hi @simii,

I remember Let's Encrypt should has auto setup a cronjob on the system, you might need to add the hook for server restart
Edit /etc/cron.d/certbot , and add "--deploy-hook 'systemctl restart lsws' " hook to the end of the default certbot command
 

gilles

Active Member
#4
@Cold-Egg is right in that there is a /etc/cron.d/certbot file.

My /etc/cron.d/certbot file looks like this:
Code:
# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.  --deploy-hook "/usr/local/lsws/bin/lswsctrl restart"
#
# Important Note!  This cronjob will NOT be executed if you are
# running systemd as your init system.  If you are running systemd,
# the cronjob.timer function takes precedence over this cronjob.  For
# more details, see the systemd.timer manpage, or use systemctl show
# certbot.timer.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew  --deploy-hook "/usr/local/lsws/bin/lswsctrl restart"
Now reading the help message, it says that the certbot.timer will take precedence if cerbot is run through systemd.
So I just edited /lib/systemd/system/certbot.service to add the '--deploy-hook "/usr/local/lsws/bin/lswsctrl restart"' option.
 

Cold-Egg

Administrator
#7
Hi @gilles and @simii,

Before systemd updates, we can mix up in use with "lswsctrl" and "systemctl" to restart lsws, but after the certain update, it messed up with systemctl. Like if you have a process start with lswsctrl start then systemctl restart/stop won't touch it.

Please run follow commands,
Code:
/usr/local/lsws/bin/lswsctrl stop
systemctl stop lsws
systemctl start lsws
and use hook
Code:
--deploy-hook 'systemctl restart lsws'
that I mentioned earlier, and it should start working properly.

Best,
Eric
 

gilles

Active Member
#8
Thanks @Cold-Egg for this precious information. I totally missed that part of your earlier post.
Wouldn't 'try-restart' (i.e. restart if already running) be better than 'restart'?
 

mcbsys

New Member
#9
Wow, glad I saw this. I thought OpenLiteSpeed would automatically handle the certbot customization since it does the Let's Encrypt setup.

To confirm, what is needed is to edit /usr/lib/systemd/system/certbot.service, changing the ExecStart line to this:
Code:
ExecStart=/usr/bin/certbot -q renew --deploy-hook 'systemctl restart lsws'
Correct?

@gilles, seems like if the web server has stopped, you have bigger problems. try-restart would keep it stopped. Is that what you want?
 
Last edited:

gilles

Active Member
#10
@mcbsys: But that's what I think is best. I do not want certbot to restart the server if I stopped purposefully for whatever reason. So in my opinion, certbot should only restart the server if it is already running.
 

Cold-Egg

Administrator
#11
oh, I see. Currently, not many cases that users use OpenLiteSpeed with other webservers on the same server, but free to use try-restart if you want. :)
 

Colcol

New Member
#12
Hi @simii,

I remember Let's Encrypt should has auto setup a cronjob on the system, you might need to add the hook for server restart
Edit /etc/cron.d/certbot , and add "--deploy-hook 'systemctl restart lsws' " hook to the end of the default certbot command
Would be very helpful if someone can clarify whether a Let's Encrypt renewal always requires an OLS restart for the renewal to become properly effective. Nothing is mentioned in the documentation (e.g. https://openlitespeed.org/kb/lets-encrypt-ssl-on-openlitespeed/?seq_no=2)

The official certbot documentation (https://certbot.eff.org/docs/using.html?highlight=hooks#renewing-certificates) advises "You can also specify hooks by placing files in subdirectories of Certbot’s configuration directory", which seems like an alternative option to editing the files mentioned in this thread.
 

jcm

New Member
#14
the certificates should auto renewal according to the documentation but it does not for my install on a VM on GCP.

This is what I have in /etc/cron.d/certbot

Code:
# /etc/cron.d/certbot: crontab entries for the certbot package

#

# Upstream recommends attempting renewal twice a day

#

# Eventually, this will be an opportunity to validate certificates

# haven't been revoked, etc.  Renewal will only occur if expiration

# is within 30 days.  --deploy-hook "systemctl restart lsws"

#

# Important Note!  This cronjob will NOT be executed if you are

# running systemd as your init system.  If you are running systemd,

# the cronjob.timer function takes precedence over this cronjob.  For

# more details, see the systemd.timer manpage, or use systemctl show

# certbot.timer.

SHELL=/bin/sh

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin



0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' &&>

Do I change the last line to this?

Code:
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew --deploy-hook "systemctl restart lsws"
 

jcm

New Member
#16
@Cold-Egg thanks for the response.. Now figuring out how to do verifications with DNS-01 challenge using a txt record so that it will renew from behind a CDN (Fatstly, Cloudflare etc). but I think can be done with acme-dns-certbot.
 

Cold-Egg

Administrator
#17
If the request passes from the CDN to the server, then it should just work? Or you might want to mimic the challenge request and check the return status code.
 
Top