Cron Task Running Certbot Renewals Generates Too Many Certificates and Causes Rate Limit to Be Hit


Dear Sirs,

I have this setup : Digitaocean droplet + server pilot

During testing i successfully generated certificates for my domain and sub domains,,,

Cron job successfully ran for two month without problem

Now i am in production, on the first of this month the cron job failed so i tried to run the command manually i got
Failed authorization procedure

Then i modified the command and didn’t include the sub domains an it was successful but the generated certificates got in 0001 folder so it didn’t replace the current certificate

I tried renaming the folders the old ones with 0002 and the new without 000 i restarted Nginx but i got error

Dear sirs , for my setup it is enough to get the main domain certificates i dont need the old sub domain
so pleas help fixing the Failed authorization procedure or replacing the new certificates from folder 0001 so taht they will be active certificates

Pleas help


Hi @2an4,

What is the command you used?.

You shouldn’t do that manually. What is the error?.

You don’t say what is the client you are using to get your certificates but certbot client has the option –cert-name (since certbot 10.0.0) to issue a cert and replace the old one (to avoid the problem you get about the -000x directory). Anyway, there is no problem if you have a new dir yourdomain-0001, all you need to do is configure your web server to use the new path to the certificate.

To resolve the failed authorization procedure, the first thing you should do is to create the dirs .well-known/acme-challenge/ on your site Document Root. For example, if the document root (the dir that you have configured on your web server) for your domain is /var/www/public_html/yourdomain/ add the dirs to that path so you get /var/www/public_html/yourdomain/.well-known/acme-challenge/.

Once you have the dirs created put a simple test file there:

echo "this is a test" > /var/www/public_html/yourdomain/.well-known/acme-challenge/test

and try to reach it using your browser:


You should see the text “this is a test”, if you get another thing then there is an issue with your conf that should be reviewed. Till you can’t see the text, Let’s Encrypt couldn’t too so you will get the failed authorization message.

Anyway, you said that you were able to issue the cert (no failed authorization error) but then you rename the dirs and now you get this error… are you sure that your web server starts when you renamed the dirs?.

Anyway, you should provide more info about the commands you used, the errors, your web server conf… if you want some help from the community ;).



First, thank you for your reply

the command i use is:

./letsencrypt/letsencrypt-auto certonly --renew-by-default --webroot -w /srv/users/serverpilot/apps/APPNAME/public -d -d -d -d

using this command i get authorization procedure error, even though it was successful in the past in two month

But since i do not need the certificates for the sub domains, the following command successfully generates new certificates but in 0001 directory

./letsencrypt/letsencrypt-auto certonly --renew-by-default --webroot -w /srv/users/serverpilot/apps/APPNAME/public -d -d

Should i remove the subdomains form the current active certificate then generate new certificate? will it replace the current one in the root directory?

How can i reconfigure the server to use the new dir 0001 instead ? i use Apache with nginx


In order to avoid making a completely new certificate with -0001, -0002, etc., you need to either

  • specify all the existing names, plus any new ones (not leaving out or removing any names), or

  • specify the cert name of the certificate lineage you wish to modify, using --cert-name

The first option is not really applicable because you do, in fact, want to remove some names from an existing cert. This can only be done by specifying a --cert-name.

You can find out the cert names by running certbot certificates.

You might also want to delete any unwanted certificates with certbot delete.


If your letsencrypt-auto version is 10.0.0 or above ( you can check the version with command ./letsencrypt/letsencrypt-auto --version ) you could use the following command to replace your current certificate.

./letsencrypt/letsencrypt-auto certonly --renew-by-default --cert-name --webroot -w /srv/users/serverpilot/apps/APPNAME/public -d -d

I’ve only added --cert-name where should be the domain part (without -0001)

Let’s try first to replace your certs.



Ok, finaly i got this working using that command, but now when i wanted to update the cron job to only include -d -d, i tried this

./letsencrypt/letsencrypt-auto certonly --renew-by-default --webroot -w /srv/users/serverpilot/apps/APPNAME/public -d -d

i got this error :
There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for exact set of domains

I guess that this is normal ? will this remedy it self after few days ?


You should not use that command in any cron job or every time it executes the command, a new cert will be issued and that is not what you want, instead you should use letsencrypt-auto renew. This command will check your cert and if the current cert will expire in less than 30 days it will try to renew it with the same options you used to get it. If your cert is not expiring in less than 30 days it will do nothing.

The error you are receiving is because you issued 20 certs in last 7 days. You should wait a few days to issue again a cert for your domain/subdomain.

Keep in mind that every time your cert is renewed you should restart/reload your web server so the new certificate is used by them. You can automate this restart/reload on your letsencrypt-auto renew command using --pre-hook and --post-hook option. Take a look to the doc.



Excuse me again, so the recommended command in cron tab should be:

@monthly letsencrypt-auto renew --pre-hook “service nginx stop” --post-hook “service nginx start”


You don’t need to stop nginx, indeed if you do that you won’t renew your cert because Let’s Encrypt boulder won’t be able to reach your domain so in your case, you should run the command daily and just reload nginx using post-hook.

@daily letsencrypt-auto renew --post-hook "service nginx reload"

Note: I don’t know if the correct way in your system to execute the cron job daily is @daily. Also, keep in mind that letsencrypt-auto should be in the path used by cron, if it isn’t you should specify the full path to letsencrypt-auto.

@daily /full/path/to/letsencrypt-auto renew --post-hook "service nginx reload"



Ok, i will use this command
@daily ./letsencrypt/letsencrypt-auto renew --post-hook "service nginx reload"
I will post my result for future reference
thank you



Just one more thing, I don’t know how your cron works but it usually sends a mail, if you don’t want to receive a mail every day you could use the --quiet option.

@daily /full/path/to/letsencrypt-auto renew --quiet --post-hook "service nginx reload"

With this --quiet option you only will be informed by mail if something goes wrong.

Good luck.


Hi @sahsanu

As I don’t use cron and it would be good for understanding of the community, can you clarify your suggestion above please.

According to certbot docs

How does this stop cron sending emails. I have had a look at a few articles on how to stop sending emails with cron but usually they do something extra to send errors only.



Because cron ordinarily send the output of its jobs to the user who scheduled the job. If there is no output, there’s no email.


Hi @ahaw021,

@danb35 is correct, cron send mails if the executed command has an output, in this case the --quiet parameter doesn’t allow to certbot to produce an output if the command has no errors.

By default, cron sends the mail to the owner of the cron job, if the owner is root it will send a mail to root… you can override this using in the cron job the variable MAILTO=whatever@domain.tld and it will send the mail to whatever@domain.tld.

The problem using the certbot --quiet option is that it produces no output… even when it renews the certs. It should be good to have an option like --almost-quiet :wink: to inform only on errors and when the certs are renewed, till that option is available you could use this approach to simulate this behavior using --renew-hook option and redirecting its output to the stderr, something like:

17 */6 * * * /path/to/certbot renew --quiet --no-self-upgrade --renew-hook 'echo "\nI have renewed the cert located in ${RENEWED_LINEAGE} and this cert contains the following domains ${RENEWED_DOMAINS}\n\n" >&2' --post-hook "service apache2 reload; service stunnel reload; service dovecot reload"

With the above command you will receive an email only if the command has an error and when your certs have been renewed, not twice everyday that is the schedule of that cron job. The command also will reload several services when the certs are renewed.



thank you muchly gentlemen


Sometimes Letsencrypt returns… cryptic messages which don’t seem correct.

I know this is nebulous.

Here’s by backup procedure for when things go south.

Following sequence meant for Ubuntu LAMP. Other OSes + Webservers, you’ll likely have to issue different commands.

  1. a2dissite domain or host

  2. service apache2 reload

At this point, the site will be returning your Apache default page, usually /var/www/html so…

  1. remove all /etc/letsencrypt files related to domain or host being renewed

  2. request a new certificate… something like…

certbot-auto certonly --no-self-upgrade --non-interactive --rsa-key-size 4096 --email you-addr --agree-tos --webroot -w /var/www/html -d -d

  1. a2ensite domain or host

  2. service apache2 reload

Be aware… On Ubuntu anyway, the certbot/letsencrypt clients tend to be old.

For example, Zesty (latest) provides v0.10.2-1 of the clients.

Latest from git is v0.14.0 so before you start, I strongly suggest using latest git version.

Many strange Letsencrypt problems tend to be fixed by using the latest client code.


Looking over first post in this thread…

If you’re correctly referencing the live/… cert files + you’re using latest certbot-auto (from git) + you’re renewing a cert (rather than generating a new one from scratch), all should work correctly.

Older clients, especially the v0.8.x series seem to sometimes fail incorrectly or they fail + produce incorrect messages, like the inability to write to some directly… when the client is run as root.

Be sure you’re running latest certbot-auto code (v0.14.0 as of today).

v0.14.0 adds locking to only allow a single certbot client to run at one time. This may resolve your problem, if your renewal process is somehow spawning multiple certbot instances.


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