Nginx auto renewal

Server
1

Hi Let’s Encrypt community!

I started using LE quite near from the beginning, so the LE client (not yet called certbot at this time) wasn’t stable enough to renew without manual assistance with an nginx server.

I’m still renewing my certs manually typing systemctl nginx stop && certbot renew && systemctl nginx start once every three months. I can’t stop my server twice a day, so I wonder if there is a more automatic way of doing that now? (I don’t have .well-known/acme-challenge file in my web roots, could it be something like that that would help automatize the renewal?)

Thanks!

2

Yeah, there are a couple of more automatic ways now. The one most nginx users seem to prefer is the webroot plugin: first obtain a new cert using something like:

certbot certonly --webroot -w /path/to/your/webroot -d example.com --post-hook="service nginx reload"

(or whatever the systemd equivalent is), then set up a cron job to run certbot renew once or twice a day; it will only run the post-hook when it actually renews the certificate. You can also use --pre-hook if you prefer to stop nginx to run certbot in standalone mode.

There’s also a full nginx plugin, which you can activate with --nginx. It’s still being tested, so experiment at your own risk and report any bugs.

2 Likes
3

My website https://wiki.findrbot.com/100-free-ssl-certificate-your-server shows you how to configure with Virtualmin and NGiNX, but just so you don’t have to leave the site, it’s simple:

For letsencrypt executable: As root, run *echo "00 00 01 /2 * /usr/bin/letsencrypt renew ; service nginx restart #LETS ENCRYPT RENEW ALL DOMAINS" >> /etc/crontab

Sorry the above doesn’t actually use certbot… But you can modify the command to run the certbot command…

Change it to *echo "00 00 01 /2 * /usr/bin/mycommand --myargs=blah #LETS ENCRYPT RENEW ALL DOMAINS" >> /etc/crontab

where /usr/bin/mycommand --myargs=blah is the command to run. This runs every 2 months…

If using the command from jmorahan above, either gedit, leafpad, nano or vi the file and paste the line in *00 00 01 /2 * certbot certonly --webroot -w /path/to/your/webroot -d example.com --post-hook=“service nginx reload” #LETS ENCRYPT CERTBOT RENEW ALL DOMAINS

4

Running letsencrypt renew only once every two months is a bad idea. For starters, consider what happens when the certificate is renewed on the 1st of February. It’s valid for 90 days; the next renewal attempt is on the 1st of April, which (in non-leap years) is 59 days later, so the cert has 31 days remaining. The 'letsencrypt renew` command won’t renew it until it’s 30 days from expiry, so the cron job will ignore it. It will expire on the 2nd of May and the cron job won’t even try to renew it again until the 1st of June.

Even if you force the renewal to run every time by using --force-renewal, you still have the problem that sometimes renewals can fail for any reason (you changed your configuration, or LE had a temporary outage, or …) and in the event of a failure, you don’t try again until long after your certificate has expired.

What you should do is what I recommended above: run letsencrypt renew or certbot renew from cron once or twice a day, and use --post-hook to ensure you’re not needlessly restarting your web server, as the post-hook only runs when a renewal is actually attempted. You can also use service nginx reload instead of restart for even less downtime.

(Also… /etc/crontab requires a username in addition to the usual time-and-date fields; and the certbot certonly command in your last line doesn’t renew all domains, only the one specified in the command)

5

Running letsencrypt renew only once every two months is a bad idea.

Tell that to Let's Encrypt. They suggest you can renew it every 2 months in their own documentation.

Even if you force the renewal to run every time by using --force-renewal, you still have the problem that sometimes renewals can fail for any reason (you changed your configuration, or LE had a temporary outage, or ...) and in the event of a failure, you don't try again until long after your certificate has expired.

Is that not what Server Admin's are for? When the automatic scripts fail, the Admin steps in to fix the issue... They even say in the documentation that you must still monitor the server even though it is automated... What admin would ignore a single server? Show me one, and I'll show you a bad Admin :slight_smile: All of the above problems would be experienced renewing in 1, 2,10,30,60, and 90 days, so whats the difference?

What you should do is what I recommended above: run letsencrypt renew or certbot renew from cron once or twice a day, and use --post-hook to ensure you're not needlessly restarting your web server, as the post-hook only runs when a renewal is actually attempted. You can also use service nginx reload instead of restart for even less downtime.

What one should and shouldn't do is vague. What you think one should do is simply an opinion. Yes, using the post-hook is a better option, I'll give you that - I did not know about that cli argument. What downtime? You mean the split second that it takes for NGiNX to restart? I can put a page on auto refresh, every 1 second, restart NGiNX and have 0 "page not displayed" errors... The time NGiNX takes to restart is only a fraction of a second (unless there are config errors of course) In fact, I perceive that as an insult towards NGiNX, considering it's efficiency.

(Also... /etc/crontab requires a username in addition to the usual time-and-date fields; and the certbot certonly command in your last line doesn't renew all domains, only the one specified in the command) <

No, no it does not. Not if you are editing the system crontab, and not even if you are editing a users crontab. The way it is set up in Debian 8 at least, is each user has their own crontabs. Therefore there is absolutely 0 need to specify a username. You can if you want though.

The crontab entry I suggested adding as root, making it a system wide crontab (more accurately a crontab owned by root) Alternatively, you could instead of SU to root, stay as a regular user (as long as its the user of the website requesting the cert)

Furthermore if someone sees "www.example.com" or a domain where their domain should be, and they dont see a way to add multiple domains, they kind of figure out to just repeat the same steps for each domain...

6

Apart from the issue about running this only every two months, there is a big difference between certbot certonly and certbot renew. certbot renew considers renewing every certificate that you have, while certbot certonly renews one single specified certificate.

certbot certonly may also try to prompt interactively, which is not a great idea for a cron job. Although you can force it to run noninteractively (and can also specify --keep-until-expiring), it's still not exactly designed for this use case.

7

As I mentioned in the post just above - you must have been composing yours - there is no issue with requesting a new certificate every 2 months.

The issues you would face would be exactly the same issues you would face had you renewed it on the 1st month, or the 3rd month… The cert renew could still fail!

Please don’t convince people they can ignore their server with your method, that’s just ignorant and bad server admin practices. Server admin’s should have eyes on all of their servers, 24/7.

Once again, there are absolutely 0 problems with running renewal every 2 months according to Let’s Encrypt’s own documentation.

8

Hi @findrbot_admin,

If you could point me to the documentation in question, I would like to update it because the way you understood it is not what we intended!

We recommend that each certificate be renewed every two months, but we intended to recommend that the command certbot renew be run twice a day in order to accomplish this. That's because certbot renew checks the expiry time of each installed certificate and doesn't renew any certificates unless they are less than 30 days away from expiring. Therefore, it should usually be safe to run it very frequently.

I personally wrote this functionality in Certbot since I was originally responsible for the implementation of the letsencrypt renew command.

Indeed, because of this behavior, running certbot renew every two months (without --force-renew, which overrides the behavior and forces a renewal of every certificate) will miss some necessary renewals. @jmorahan's description above correctly describes why (if the certificate is 1.5 months from expiry on the first run, it won't be renewed at all because it's not <30 days away from expiry; then the next run won't occur until the certificate has already been expired for 0.5 months).

[quote="findrbot_admin, post:5, topic:30894"]
No, no it does not. Not if you are editing the system crontab, and not even if you are editing a users crontab. The way it is set up in Debian 8 at least, is each user has their own crontabs.[/quote]

The crontab(5) man page for Debian Jessie says:

The system crontab (/etc/crontab) uses the same format, except that the username for the command is specified after the time and date fields and before the command.

https://manpages.debian.org/jessie/cron/crontab.5.en.html

It seems to distinguish between root's crontab and the systemwide crontab.

1 Like
9

One thing I failed to notice, this is the LE website bahaha ~ Of course I'll run into a LE dev. My apologies.

Yes the docs gave me a clear feeling that renewing every 2 months is ok. And I see no problems with it, as those aforementioned problems of yours would be experienced regardless of when you attempt automatic renewal.

Correct me if I am wrong, but this wouldn't overload or stress your servers since it's my server doing most of the work?

So I could run the letsencrypt renew twice daily then? Am I understanding this right that there is no issue with that?

The manpage may say that, but it is not required. I have never had problems with crontabs not running because I didn't specify a user.

The fact that the system and root crontab are separate, is a small difference. I acknowledged it is more accurately adding the crontab as the root user's crontab.

I will find the doc and link to it, it must just be worded in a weird way...

10

I found it here:
https://letsencrypt.org/docs/faq/

[quote]What is the lifetime for Let’s Encrypt certificates? For how long are they valid?

Our certificates are valid for 90 days. You can read about why here.

There is no way to adjust this, there are no exceptions. We recommend automatically renewing your certificates every 60 days.[/quote]

If you suggest running the cert renewal twice daily, you should update the documentation to show that. Make it say something like “We recommend running the certificate renewal twice daily, but that is no excuse to stop monitoring your server as renewals can fail for various reasons.”

Just a small part that was overlooked. It’s easy when you have so much technical crap to manage :slight_smile:

While I have the attention of someone from LE, thank you thank you thank you thank you thank you thank you thank you thank you thank you thank you thank you thank you! (lol)

You guys saved everyone hundreds of dollars, and thousands in some cases… Small developers need SSL for their websites. I happen to have 8-10 servers of my own that all need SSL certs. Thank you!

This discussion has actually expanded my knowledge more which is always good.

1 Like
11

The main documentation related to this is

https://certbot.eff.org/docs/using.html#renewing-certificates

This command attempts to renew any previously-obtained certificates that expire in less than 30 days. The same plugin and options that were used at the time the certificate was originally issued will be used for the renewal attempt, unless you specify other plugins or options. Unlike certonly, renew acts on multiple certificates and always takes into account whether each one is near expiry. Because of this, renew is suitable (and designed) for automated use, to allow your system to automatically renew each certificate when appropriate. Since renew only renews certificates that are near expiry it can be run as frequently as you want - since it will usually take no action.

It's tricky to think about how to relate Certbot documentation to Let's Encrypt documentation. Let's Encrypt users aren't required to use Certbot (it's just the "recommended client") and so I doubt we would say "run certbot renew" in general Let's Encrypt documentation, given that there are dozens of different clients available. Maybe we could say "Consult the documentation of your client application to figure out how to set up automated renewal"?

12

Maybe we could say "Consult the documentation of your client application to figure out how to set up automated renewal"?

Yes that is better. I think the miscommunication was you thought I was referring to the certbot docs and I thought you thought I was referring to the Let's Encrypt docs... I've never used certbot, so I have never RTFM for that lol...

I guess I mistaken you for a LE dev, your a CertBot dev... Either way, I have mad respect for developers - especially open source developers :smiley:

13

The new name for the client letsencrypt is certbot. It was changed about a year ago to try to reduce confusion between the certificate authority and the client application. Unfortunately, the old name is still in wide use and possibly causing additional confusion. If you run the command letsencrypt on your servers, you do use Certbot!

14

Ahahhaa thanks for pointing that out… Added confusion.

Yeah I have no idea then why Debian still names the binary letsencrypt…

So the docs on the LE site may need rewording… Maybe also mention that using “letsencrypt” is the same as using certbot it’s just the name never updated for some reason with some distros. Maybe even mention some control panels like virtualmin will handle renewal for you, and also suggest adding a crontab - the proper way, according to the Debian documentation.

Mostly what I suggest is what works, which is not always what is proper. I usually try to suggest the proper ways if I know them.

So yeah, that thank you does include you too :slight_smile:

I take it there was a slight hint at a suggestion to now go read the CertBot docs as well within that posing :wink:

EDIT: I was thinking and I think I just figured it out… Debian is a more stable distro, so they don’t always use the latest releases of packages. The packages are “vetted” in a way by other distros first.

15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.