Worked first time - but there was something wrong with it so tried again. I now get this error:
urn:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for exact set of domains: tbaker.org,www.tbaker.org
Which would be fine, but looking at any of the other certificates there is nothing with a date of July, nothing else has updated…has the limits been changed? Certainly one domain (www + domain) shouldn’t trip the rate limit?
I’ve found this before, rate limits reporting as exceeded but nothing in /archive/ or /live/ suggesting any certs have actually updated? There’s only 5 domains using LE on the box, anyway. I run the renew command twice daily, as suggested. I didn’t have --keep-until-expiring on it (I do now) but as I said, no sign of any new directories or certs in the folders?
Looking through the logs, it’s been complaining about the same thing “urn:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for exact set of domains: tbaker.org,www.tbaker.org” since the 5th - just on that domain?
So why is one domain, and one domain only keep renewing every day? The other domains don’t - checked them with that tool, all the others are updating after 2 months, as expected. I suspect this is a bug with the tool? I’ve removed the renewal so it shouldn’t renew, and waiting for the limit to lapse.
(the combine script is unrelated, it’s to combine the keys for a different cert, not this one) - as I said I’ve added the --keep-until-expiring but even without the other domains haven’t been renewing every day!
It’s not impossible for this to be a bug in certbot. But I must say it’s more likely you have some other software issuing certificates for this pair of names (tbaker.org and www.tbaker.org) periodically and then not using them.
If you share administration for tbaker.org with anybody else this’d be a great time to check with them. Also if you have any old jobs or scripts related to certificates you think you shut off but actually maybe you didn’t, it’d be a good time to make really sure.
As @tialaramex says, could you double check all possible avenues of issuance? Maybe check the notBefore dates on the issued certificates in crt.sh to see if they line up with any other cron job (note: they are backdated by an hour).
I’m the only one, and no other cron jobs re: LE are running.
I have been using LE since a few months after launch, and used to use the Apache plugin - now use nginx and webroot but I thought that the old plugin only ran via cron? Checked all crons, root and user, nothing there should run apart from the one line I put above.
Also just checked the cron.d, cron.daily, cron.hourly folders. Nothing obviously LE based in there.
Oh you mean the link above? Yes I assume the first one is me doing it manually but they are firing at 15:21 and 3:21, oddly. My server is on British time, so right minutes, not sure it’s 2 hours behind, daylight savings?
Yes just checked, server is on BST. So that’s as expected. It is firing at the times in the cron. As I said above, checked all other crons…nothing. Wouldn’t fire anyway because the old ones would be looking for the old LE script, not the new certbot one.
Dunno why this one domain is ‘stuck’ though? Could it be something to do with webroot and permissions?
Permissions could be relevant. Is it possible that certbot gets Let’s Encrypt to issue a certificate successfully, but when it tries to write that out as a PEM file it finds it doesn’t have permission and exits? In this case the certificate is issued, as far as Let’s Encrypt is concerned, and so it goes in the logs and eventually appears in the crt.sh monitor, but your computer never has a copy because it couldn’t be written to disk.
Can you try to crank up the verbosity (-v on the command line, maybe three times like -v -v -v would do it?) and keep the full output from your renewal step ? You might need to wait a few days to “cool off” the limits first so that it doesn’t just run into the limit and fail then.
Wouldn’t that be the case with the other domains though? They write fine? Same script, same options.
I’ve altered the .well-known folder perms in tbaker’s webroot to match the others. It’s the only thing I can think of which is individual to the domain apart from the renewal script.
I am running into a very similar problem. I've had LetsEncrypt since very early on, and recently upgraded to the Debian certbot package, which installs its own crontab entry (specifically, /etc/cron.d/certbot). By default, it tries to run certbot -q renew twice daily, at 12:00 and 24:00, with some random offset.
This is well and good, except that I constantly get this message, twice daily:
There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for exact set of domains
I'm not sure why, or what exactly is going on, but I think there has to be some problem with the upgrade path from old versions of LE to certbot, which have resulted in certificates being constantly renewed.
I've checked and it doesn't seem as though I have any other competing cron jobs. I'm going to basically try and disable everything that might be causing automatic renewals and see if that stops things... but it's kind of a problem that this happens at all.
@kadin2048, what do you see if you run certbot renew yourself from the command line rather than from cron? Does it attempt to renew something for what you regard as no good reason? Is there any information in the Certbot log file that might help explain what it tried to renew and why?
