@ShotaMegre: Sorry for the late answer here. Fixed it on github.
As noted in
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.
I just created this script :
=====
#!/bin/bash /etc/init.d/apache2 stop /root/bin/letsencrypt-auto renew /etc/init.d/apache2 start=====
And then call it from the weekly cron - done.
Hopefully someone will find this useful.
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 )
Hi hsuf, serverco is right, you just need to reload.
I'm running FreeBSD, so my script location is different, but I can simply call:
/usr/local/etc/rc,d/apache24 reload
Try running:
/etc/init.d/apache2 reload
from your command line and see what happens. If it works, you need only reload at the end of the script, not shutdown Apache at the beginning.
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
15 0 * * 7 /opt/letsencrypt/letsencrypt-auto renew | tee --append /var/log/letsencrypt-renew.log | /bin/grep -q 'No renewals were attempted.' && { /usr/sbin/nginx -t 2> /dev/null && { echo '\n\nRenew Attempted - reloading nginx\n'$(date)'\n\n' >> /var/log/letsencrypt-renew.log ; /usr/sbin/nginx -s reload; }; }
With this output at the end if 'No renewals were attempted.' doesnāt appear in the output
Renew Attempted - reloading nginx Mon Apr 18 21:19:40 PDT 2016
Shouldnāt that be || rather than &&, as in
... /bin/grep -q 'No renewals were attempted.' || { /usr/sbin/nginx ...
The grep will succeed only if there was no renewals done, so only restart nginx when it isnāt needed.
Crontab is the easiest and simple of it (using Ubuntu Server whit LAMP)
I check mine every Mondays at 1:30 AM.
30 1 * * 1 /opt/letsencrypt/letsencrypt-auto renew >> /var/log/le-renew.log && service apache2 restart
1 Like
My only comment is I do a āreloadā rather than ārestartā of apache, since that gives zero downtime
true enough, but its easier due i have some other configs that need a restart of apache on that server, however you right mate 
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 
nice, but let encrypt doesnāt support email certificate yet?
Iāll always use google apps instead for emails services because hosting it myself always is a pain in the a**
By email certs they mean for client S/MIME, not mail servers which are TLS as with webservers.
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 use the following to update my certs.
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:
./le.sh domain www.domain.com,domain.com /path/to/webdomain/files/ -r
This line can go to crontab along with
/usr/sbin/nginx -s reload
or
service nginx reload
I hope this helps!
A post was split to a new topic: What is webroot?
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 donāt understand this magic, but it works.
Shazam!
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 cron every 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.
Thank you very much!
I would like for this to run daily as you suggested, however I canāt afford to restart my httpd everytime.
The reason I have to stop my httpd is because port 80 is in use, so letsencrypt fails. I must make port 80 available.
Is there a workaround, where I can cron this daily, and not have to stop my httpd? Or perhaps letsencrypt can use a custom port number?