Restart Apache 2.4 in crontab after renewing letsencrypt certs with acme.sh?

Hello everyone,

Is it possible to restart www/apache24 from crontab after successfully renewing letsencrypt certs with security/acme.sh?

This is what I have now (run each night 03:00):

Code:
* 3 * * * /usr/local/sbin/acme.sh --cron >> /var/log/acme.cron.log

Thank you,
 
look for reloadcmd and point to your .sh script that will reload or restart all services that are using certificate.

I personally use certboot with -posthook with the same .sh script for reloading postfix/apache/dovecot etc.

For apache and dovecot you need restart (not reload) for postfix you can use reload to refresh the certificate.
 
I do it through pre and post hooks as recommended by certbot, this is for my mail server, but you get the idea.

Code:
30 1 * * 7 /usr/local/bin/certbot renew -q --rsa-key-size 4096 --pre-hook '/usr/sbin/service postfix stop && /usr/sbin/service dovecot stop' --post-hook '/usr/sbin/service postfix start && /usr/sbin/service dovecot start'

Just noticed, you're using acme, my bad :S
 
Everything is working as expected, except the restart of Apache 2.4.

This is what I have right now:

Code:
0 03 * * * /usr/local/sbin/acme.sh --cron --reloadcmd "service apache24 restart" >> /var/log/acme.cron.log

Can't find any "resume" in Apache logs when a certificate is renewed.

Any ideas?
Thanks,
 
Don't put the reloadcmd in the cronjob! configure the command specifically for that certificate in the corresponding ~/.acme.sh/<domain>/<domain>.conf file if you didn't already specified --reloadcmd at first cert creation. But beware - the entry is usually base64 encoded!
The easiest and safest way to update configs would be to --force a recreation of the cert (and config). This way you will immediately know if it works, not in a few weeks when the cert runs out because you botched something in the config...

Instead of directly issuing certs via command line (if you don't use configmanagement/orchestration already), write a small script for it, so you can easily re-issue, extend or change the certificate and its options later. I usually name those scripts after the service or jail they are destined for, and put them inside the .acme.sh folder. E.g. one of my nginx.sh scripts from one of my mailservers:
Code:
#!/bin/sh
export DO_API_KEY="<secretkey>"
acme.sh --force --issue --dns dns_dgon --dnssleep 20 -d nginx1.<mymailserverdomain> -d <mymailserverdomain> --keylength ec-384 \
--cert-file "/iocell/jails/b157ed8a-9b9d-11e8-a0d3-3d48bcff2e2c/root/usr/local/etc/nginx/ssl/cert" \
--key-file "/iocell/jails/b157ed8a-9b9d-11e8-a0d3-3d48bcff2e2c/root/usr/local/etc/nginx/ssl/key" \
--fullchain-file "/iocell/jails/b157ed8a-9b9d-11e8-a0d3-3d48bcff2e2c/root/usr/local/etc/nginx/ssl/fullchain" \
--reloadcmd "service -j ioc-b157ed8a-9b9d-11e8-a0d3-3d48bcff2e2c nginx restart"
Instead of '--force' you might want to use '--test' to check if the reloadcmd works. '--test' will run the command against the LE testing servers and not count against the rate limit.
Only use '--force' against the actual letsencrypt servers if you have to re-issue the cert earlier than the usual ~90 day period (e.g. to change parameters like domains or keylenght) and you've already '--test'ed the command works, otherwise you might hit the rate limit and have to wait up to 24h to get a working certificate.

The crontab for acme.sh entry only contains a single call to acme.sh with the --cron parameter, which automatically goes through all acme.sh configs and does the right thing™:
Code:
@daily               /usr/local/sbin/acme.sh --cron --home "/root/.acme.sh" > /dev/null
The 'reloadcmd' doesn't belong in the crontab! If it is interpreted at all (never tried that...), it would be executed for _all_ cert renewals, not only the apache related cert!
 
Back
Top