Too many certificates already issued

I took 4 certificates for sub domains in the same domain.

I could renew certificates of, and but when I tried to renew certificate of, it showed the following error.

An unexpected error occurred:
There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for:
Please see the logfiles in /var/log/letsencrypt for more details.

I need certificate so I tried to renew certificate after I revoked certificate but it shows the same error message again.

What should I do to renew certificate?

1 Like

There are rate limits in effect, including the amount of certificates issued per domain per time slot. Guess you’ll have to wait.

But you do know you can add multiple (sub)domains to a single certificate?

1 Like

I also have this rate limit problem. Osiris thank you for mentioning something that could help… but I am not sure how. could you elaborate on your hint?

If I understand correctly one can give multiple domain names as argument to the CLI client of Letsencrypt like so:

./letsencrypt-auto -d -d

Is this how SAN certificates are created? If that is the case I am still wondering why I get the same error:

There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for:

Yes, you're correct: by using multiple -d switches, you'll get one certificate with multiple domains. I believe the first -d switch will be the CommonName (CN) domain. And all domains are added to the SAN list. But even so, if you've hit the rate limit, that limit doesn't suddenly vanish :wink:

Perhaps you can experiment first by using the --server option. That way you can try the client and receive certificates (which won't work online, 'cause they'll be signed by some "Happy hacker" CA in stead of Let's Encrypt Intermediate X1) and the staging server doesn't have such strict rate limits.

Well I am a happy developer right now :wink: Thank you for the reply!

The one certificate you mention, for the multiple domains… how is this reflected in the directory structure here: /etc/letsencrypt/ if you might know?

The reason I ask is; I have issued cert(s) from Letsencrypt with multiple “-d” arguments and I see a directory for every (sub)domain with a corresponding certificate file.

But perhaps my first steps where:
./letsencrypt-auto -d
./letsencrypt-auto -d

And after that I tried:
./letsencrypt-auto -d -d

Revocation doesn’t affect the rate limit and doesn’t give you new certificates to issue. You’ll have to wait 7 days (currently 5 certificates / 7 days).


Thank you for reply, all three of you!
I did not know that there are rate limits, I can add multiple sub-domain to one domain and the revocation can not remove the rate limit.
I tried “./letsencrypt-auto certonly --renew-by-default --standalone -d -d -d --debug” but it shows the same error… looks like I have still the rate limit.
Maybe I have to wait for a week…
Am I able to recreate revoked certificate?

No, revocation doesn't reset limits.

This is a bit problematic because right now is blocked:

Error creating new cert :: Too many certificates already issued for:

So pretty much no one using at the moment is able to create new a certificate until this lets up, even though none of us actually “own” but are restricted to our subdomains (i.e.

You have to ask the owner of to add it to the public suffix list.

Is there an ETA when this limit will be increased?


Yes please give us more certificates per day. I am writing an howto for hiawatha server as reverse proxy and alas after testing 5 times hit the limit.
I had just deleted the /etc/letsencrypt/renewal and live dir because I had errors and BAM hit the limit.

1 Like

Hi, wish I had know you had such and environment. I copied the code from some website on hiawatha.

Perhaps you could echo
"please be advised to use our testing servers if you are testing to use this server xxxx"

when the script is run:
./letsencrypt-auto certonly -a webroot --webroot-path $WEBROOT -d $i --server


I just didn’t know.

1 Like

And in some countries the manual of the microwave warns the user you shouldn’t put your cat in the microwave in order to dry it… And expect it to live afterwards… :unamused:


I have the same issue but the point in my case is … I have one domain distributed over multiple ip’s/location’s how can i handle that the best way?

Thx :slight_smile:
BR cyball

If you can change your DNS through an API, then you can use the DNS challenge ( as that just uses DNS and doesn’t need to do anything on each server). Alternatively use getssl which is a bash script written for automating certs on remote servers ( as long as you have SSH access to the various remote servers using keys ) getssl will also perform the DNS challenge method if you wanted to do it that way.

You can redirect all traffic to /.well-known/acme-challenge/* to a host having only a single IP that handles your issuance.

@serverco, @kelunik,

thx for the info the getssl solution seems very good, I will give it a try :slight_smile:

BR cyball :slight_smile:

I have what I assume will be a common use case. I have VMs in Azure that I am attempting to make certs for, when the rate limit is calculated it apparently uses the top level domain e.g., and not my sub-domain of the machines in my subscription. IMHO this is a bug…

Submit-ACMECertificate : Error creating new cert :: Too many certificates already issued for:
At line:1 char:2
+  Submit-ACMECertificate cert01
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceBusy: (ACMESharp.Vault.Model.CertificateInfo:CertificateInfo) [Submit-ACMECertif
   icate], AcmeWebException
    + FullyQualifiedErrorId : urn:acme:error:rateLimited (429),ACMESharp.POSH.SubmitCertificate

Is there a work-around for this use case? I assume this will happen in AWS and GOOGLE clouds too.