Rate Limited / Renewals taking place too early

Client dev
1

I’ve been using LE certs since inception, my first certificate ever issued on 2016-06-15 and I’ve never hit a rate limit in almost 5 years :thinking:

Now, this week while writing a new script for a client, I have managed to hit a rate limit on 2 test machines.

The problem is when I have been testing the renewal script, it is renewing certificates that have just been issued and not even nearly close to expiry. So as a result a simple renew command is getting a new certificate regardless that it was issued an hour ago. When did this change ???

I run certbot on multiple servers of my own, they all use the same certbot version 1.2.0 as I am using on the clients test machines, YET when my renewal scripts run on my servers (daily on 5 servers) does not renew anything that is not due for renewal or nearing expiry and I get my daily emails I configured which gives sends me the renewal log with the usual simple run down of what was renewed and what was not The following certs are not due for renewal yet: and The following certs were successfully renewed.

Day in and day out I don’t even check these emails off my own 5 servers that much (maybe once a month) as nothing ever goes wrong and I’ve never had a certificate not renew or renew too early.

The very same script on these two client test servers however just haphazardly renews a certificate each and every single time regardless and using the same renewal command. Certificates issued on my servers and the clients servers are done using the very same command line, the same authenticator and their renewal.conf files are all identical barre the domain names.

On my own servers all my renewal.conf files have # renew_before_expiry = 30 days at the top of every renewal.conf file. The very same on the clients test servers.

I have checked through everything, there is no duplicate certs or any other problems of that nature merely the fact I can renew these certs on the clients test server within minutes of them being issued.

I am rather lost now, I really know my way around certbot in and out, so this truly has me stumped. @schoen

1 Like
2

That’s not supposed to be happening.

What are the domains?

What does “sudo certbot certificates” output?

What does “sudo ls -alR /etc/letsencrypt/{archive,live,renewal}” output?

Do you have a copy of the output from certbot renew?

The --force-renewal option (previously called --renew-by-default) hasn’t snuck into the configuration, has it?

2 Likes
3

OK thanks @mnordhoff none of my servers have a cli.ini file, never have and still do not.

The clients test servers DO have a cli.ini file with renew-by-default = True

So for now renew-by-default = False should resolve this behavior ??

How then is this setting in a cli.ini file so radically different than when I have actually set --renew-by-default in a certificate request? Something I have been doing and still do since day one?

In other words why is this certonly --webroot --webroot-path /whatever --agree-tos --rsa-key-size 4096 -m me@my.com -d whatever.com --renew-by-default ie. the correct way of requesting certificates not doing the same thing as what is essentially the same parameter yet from a cli.ini file ???

Do we even need a cli.ini file it seems to create problems that I have never seen in 5 years.

1 Like
4

Yes, or you can just remove the setting.

(If you do keep it, you might as well change it to its newer name, force-renewal.)

I don't know. Maybe running certbot certonly or certbot run with --force-renewal doesn't save it in the renewal configuration file.

This is the expected behavior for running certbot renew with --force-renewal, though. (Which is why it shouldn't be done!)

You should never need to use --force-renewal in the normal course of events. Its purpose is to unnecessarily renew good certificates. If you're creating a new certificate, or adding or removing names, it's not applicable.

(It is useful when doing something like changing the key size, or changing the configuration.)

(Also, for what it's worth, --agree-tos and -m are only used when registering a new account. It's not harmful to specify them every time you run Certbot, but it's not needed either.)

I'm not sure. But putting it in cli.ini means it also applies to certbot renew (probably).

There's usually no reason to have a cli.ini file. The default settings are fine in most situations.

In your case, it might be useful to specify rsa-key-size there, though.

3 Likes
5

Ok thanks. So --renew-by-default which many of were taught from day one to use in certificate requests can be dropped when requesting a certificate now? Clearly it’s not doing the same thing as what is essentially the same setting but contained inside a cli.ini file.

I can confirm 100% when requesting a certificate using --renew-by-default it is not setting anything of that nature in any renewal.conf files never has and still does not.

So to confirm 100% going forward the parameter --renew-by-default is no longer required when requesting certs?

I will make sure my script for the client checks any cli.ini files and removes them. We use a template server which is cloned to create new servers so this cli.ini crept in from the newer versions of the Vicibox ISO he is using.

The way I request certs (as above) specifies key size, email, domain and everything else needed to get a certificate and makes sure it renews as expected so I will drop having any cli.ini files hanging around to complicate things :grinning:

6

--force-renewal/--renew-by-default is not required except when it is -- the particular situation where you want to force Certbot to issue a certificate even though you already have a certificate with the same names and it isn't going to expire soon.

4 Likes
7

Awesome thanks @mnordhoff all fixed now and tested on 2 servers .... bye bye cli (hey that rhymes) :rofl:

My setup script for the clients servers now sorts this all out to avoid any issues on any of the clone machines and --force-renewal / --renew-by-default dropped from the command line when we request a new cert.

2 Likes
8

Nobody should have been taught to use that as a normal part of certificate requests. It was put there to cover unusual situations (specifically, where you needed to get a new cert even though you had plenty of life left on the current cert), and even though the name of the option has changed, its purpose hasn't. Anything that said to use that option for routine cert requests was bad advice.

4 Likes
9

Clearly it was bad advice. What’s troubling though is that for 5 years (still today) specifying --renew-by-default in the command line when requesting a new certificate has had NO effect whatsoever, no effect getting the new cert, no effect in setting it in the renewal.conf and no effect on renewals taking place the way they should normally take place. Only the presence of a cli.ini has raised this problem for the very first time in 5 years.

10

limit is 5 per week, I guess you just haven’t noticed until now.

you can check on crt.sh how many certs have been issued for your domains.

1 Like
11

I am aware of the rate limits, as you can see I’ve never hit it once in 5 years with hundreds of certs, only now due to the cli.ini forcing a renewal every time.

12

@mnordhoff @schoen

Just ran a test to show how both --renew-by-default and --force-renewal have no effect (never have and still dont). Nothing is set in the renewal.conf files created and renewals work as they should. Now you can see why passing this parameter for 5 years has never ever raised its ugly head until the presence of a cli.ini file and of course the default for certbot is By default no cli.ini file is created.

certbot --version
certbot 1.2.0

TEST1: (requesting a certificate with --renew-by-default)

COMMAND LINE:

certbot certonly --webroot --webroot-path /var/www/port80 --agree-tos --rsa-key-size 4096 -m dnsadmin@allover.co.za -d test1.allover.co.za --renew-by-default
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for test1.allover.co.za
Using the webroot path /var/www/port80 for all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/test1.allover.co.za/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/test1.allover.co.za/privkey.pem
   Your cert will expire on 2020-05-30. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

RENEWAL.CONF CREATED

# renew_before_expiry = 30 days
version = 1.2.0
archive_dir = /etc/letsencrypt/archive/test1.allover.co.za
cert = /etc/letsencrypt/live/test1.allover.co.za/cert.pem
privkey = /etc/letsencrypt/live/test1.allover.co.za/privkey.pem
chain = /etc/letsencrypt/live/test1.allover.co.za/chain.pem
fullchain = /etc/letsencrypt/live/test1.allover.co.za/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = fc2b312de0a4a28fdf590b97d3e5ba7d
rsa_key_size = 4096
authenticator = webroot
webroot_path = /var/www/port80,
server = https://acme-v02.api.letsencrypt.org/directory
[[webroot_map]]
test1.allover.co.za = /var/www/port80

TEST THE RENEWAL

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Processing /etc/letsencrypt/renewal/test1.allover.co.za.conf
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Cert not yet due for renewal

TEST2: (requesting a certificate with --force-renewal)

COMMAND LINE:

certbot certonly --webroot --webroot-path /var/www/port80 --agree-tos --rsa-key-size 4096 -m dnsadmin@allover.co.za -d test2.allover.co.za --force-renewal
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for test2.allover.co.za
Using the webroot path /var/www/port80 for all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/test2.allover.co.za/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/test2.allover.co.za/privkey.pem
   Your cert will expire on 2020-05-30. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

RENEWAL.CONF CREATED

# renew_before_expiry = 30 days
version = 1.2.0
archive_dir = /etc/letsencrypt/archive/test2.allover.co.za
cert = /etc/letsencrypt/live/test2.allover.co.za/cert.pem
privkey = /etc/letsencrypt/live/test2.allover.co.za/privkey.pem
chain = /etc/letsencrypt/live/test2.allover.co.za/chain.pem
fullchain = /etc/letsencrypt/live/test2.allover.co.za/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = fc2b312de0a4a28fdf590b97d3e5ba7d
rsa_key_size = 4096
authenticator = webroot
webroot_path = /var/www/port80,
server = https://acme-v02.api.letsencrypt.org/directory
[[webroot_map]]
test2.allover.co.za = /var/www/port80

TEST THE RENEWAL:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/test2.allover.co.za.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not yet due for renewal
1 Like
13

These options are synonyms in the Certbot code. I came up with the old name, --renew-by-default, and I regret that choice because its common interpretation isn't close to what it actually does.

It's rare that this option is beneficial or relevant.

2 Likes
14

Here's what I think the explanation is:

renew-by-default is a misleadingly-named option and it might, if present in cli.ini (I haven't checked how these code paths work) cause every invocation of even certbot renew to cause a renewal attempt to take place.

If specified on a command line, like with certbot certonly --renew-by-default, it will also cause a renewal attempt whenever that command line is run. However, you might have a user-created cron job (or habit) which runs this command line infrequently. If you used an officially-recommended way of installing Certbot, you will also have a systemwide cron job or a systemd timer that runs certbot renew -q twice per day. Without a cli.ini, this very-frequently-run task will not have a reason to run with --renew-by-default (which is now called --force-renewal). But with this option set in cli.ini, it may pick up that option and skip the check for the certificate's expiry window, and "renew by default" under all circumstances, because the cli.ini may apply to every way of running Certbot, including those automated renewal processes that were created by the installation method.

Conclusion: I'm still sorry that I originally called it --renew-by-default; it doesn't do what you expect, so please do not specify this option anywhere; please call it by its new name --force-renewal and only use it if you specifically want to override Certbot's normal renewal checks for some reason (in order to renew a certificate earlier than Certbot thinks is appropriate).

4 Likes
15

Thanks so much for the clarity. I think this parameter was misunderstood by many in the very early days (me included) when this all began. I’ve dropped it from future new certificate requests but now at least fully understand the correct purpose of the flag and --force-renewal is now most definitely much clearer. :wink:

1 Like
16

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