we're introducing a new renewal mechanism called letsencrypt renew (letsencrypt certonly will also continue to work, while letsencrypt-renewer, for those who have noticed it, is being removed). We would really appreciate help testing this to see if people encounter problems or find anything confusing.
As per your other post. You shouldn’t need to stop and restart apache2. I’d just suggest a reload ( which reload’s the config and any updated certs, without stopping apache and braking users connections )
I use this as a crontab entry to run weekly. It tries to renew, if no renew is attempted, fails and quits. If it does attempt, restarts nginx if configtest suceeds. Logs all output to /var/log/letsencrypt-renew.log
Oh, of course, I do use cron, I use it to run my renew script once a week. It's just that I use cron to run a script rather than run letsencrypt directly. My script reloads Postfix and Dovecot as well as Apache (I run my own mail server) and does a few other weekly housekeeping tasks related to certificates.
Having my certificate management in a separate script means I can run everything at once whenever I want, the script can be formatted in a very readable manner, and my crontab is tidier
As cool110 said, it's the S/MIME that Let's Encrypt doesn't support. The certificates work in Postfix and Dovecot just fine. I was using self-signed certificates, but there are several apps (specifically mobile apps) that make using self-signed a pain in the bum.
Apart from the occasional Youtube video, I live a completely google-free life! I don't need some dodgy foreign advertiser using my personal emails to market to me
I have one cert with multiple subdomains making it easier to manage. I run on CentOS 7 and my script has some dependencies such as using systemd (systemctl reload httpd) at the end to get the new cert.
My setup relies on using the apache authenticator. This could be generalized more with config variables, but I don’t have time to expand right now.
One hack, and it might just be becuase of my lack of research/understanding, I had to make a symlink in /etc/letsencrypt/live/[mydomain] to what I found letsencrypt generates on renewal (i.e. /etc/letsencrypt/live/[mydomain]-0001). In doing so, the updater script requires no human intervention, does not stop the webserver, and is self sustaining.
Well I did a small write up, available via Let's Encrypt Fast where you are able to test/generate/renew certificates easily.
Especially the renew process is painless if included to a cron job!
The actual renew command is something like this:
80 days ago, I installed letsencrypt on debian jessie:
ii letsencrypt 0.4.1-1 all Let's Encrypt main client
While nginx was not running and port 80 was available, I did letsencrypt certonly -d mydomain.com and followed the instructions.
Today I needed to renew my soon to expire domains, so I issued this command:
service nginx stop; letsencrypt renew; service nginx start
Stop Nginx
renew certs
Start nxing
(domain names removed)
Processing /etc/letsencrypt/renewal/.us.conf
new certificate deployed without reload, fullchain is /etc/letsencrypt/live/.us/fullchain.pem
Processing /etc/letsencrypt/renewal/.me.conf
new certificate deployed without reload, fullchain is /etc/letsencrypt/live/.me/fullchain.pem
Processing /etc/letsencrypt/renewal/.net.conf
new certificate deployed without reload, fullchain is /etc/letsencrypt/live/.net/fullchain.pem
Processing /etc/letsencrypt/renewal/.club.conf
new certificate deployed without reload, fullchain is /etc/letsencrypt/live/.club/fullchain.pem
Processing /etc/letsencrypt/renewal/news..net.conf
Processing /etc/letsencrypt/renewal/radio..com.conf
Processing /etc/letsencrypt/renewal/.ru.conf
new certificate deployed without reload, fullchain is /etc/letsencrypt/live/.ru/fullchain.pem
Processing /etc/letsencrypt/renewal/.news.conf
new certificate deployed without reload, fullchain is /etc/letsencrypt/live/.news/fullchain.pem
Processing /etc/letsencrypt/renewal/.io.conf
new certificate deployed without reload, fullchain is /etc/letsencrypt/live/.io/fullchain.pem
Processing /etc/letsencrypt/renewal/.com.conf
new certificate deployed without reload, fullchain is /etc/letsencrypt/live/.com/fullchain.pem
Processing /etc/letsencrypt/renewal/.com.conf
new certificate deployed without reload, fullchain is /etc/letsencrypt/live/.com/fullchain.pem
Processing /etc/letsencrypt/renewal/deals..net.conf
The following certs are not due for renewal yet:
/etc/letsencrypt/live/news..net/fullchain.pem (skipped)
/etc/letsencrypt/live/radio..com/fullchain.pem (skipped)
/etc/letsencrypt/live/deals..net/fullchain.pem (skipped)
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/.us/fullchain.pem (success)
/etc/letsencrypt/live/.me/fullchain.pem (success)
/etc/letsencrypt/live/.net/fullchain.pem (success)
/etc/letsencrypt/live/.club/fullchain.pem (success)
/etc/letsencrypt/live/.ru/fullchain.pem (success)
/etc/letsencrypt/live/.news/fullchain.pem (success)
/etc/letsencrypt/live/.io/fullchain.pem (success)
/etc/letsencrypt/live/.com/fullchain.pem (success)
/etc/letsencrypt/live/.com/fullchain.pem (success)
I did not have to do anything. I didn’t have to concoct any config files. I did not have to write any scripts.
I’m not sure if this is a new feature or something, but just crontab this monthly. Whatever needs to be renewed, will be taken care of automatically.
I’m glad that the renewal feature worked so well for you, @HashBorgir.
In fact, letsencrypt renew (modern suggested form: certbot renew) is a longtime feature. It is intended to be run from cronevery day rather than every month, because it only tries to renew those certificates that are less than 30 days away from expiring. (If you run it every month, you could potentially get unlucky and have it attempt to renew only 1 day before a certificate’s expiry, or even later, depending on the length of the individual months.
Renewal attempts that take place very soon before a certificate’s expiry are, in any case, a bit risky, because if the renewal fails for some reason, they leave very little time for human intervention to investigate and fix the problem. We would certainly rather have people on this forum saying “my renewal failed for some reason and my certificate is expiring in 28 days from now, please help!” as opposed to “my renewal failed for some reason and my certificate is expiring later today, please help!”.)
It is true that it might not be a good idea in case you use standalone for some certificates because in that case you may have to stop your web server, which you may not want to do every day. For other authentication methods, it should be possible to run every day, and some Certbot operating system packages even configure this by default as part of the package. There are also --pre-hook, --post-hook, and --renew-hook options in case you want to run commands (e.g., reloading the web server configuration) before or after the command runs, or in response to a successful renewal.
If you could use the webroot authenticator, rather than standalone, you wouldn't need to do this, because your existing web server would serve the challenge response. Certbot would need to be able to write a small file that your web server would serve as http://$YOUR_FQDN/.well-known/acme-challenge/longrandomfilename.