Hello community,
we are currently running let’s encrypt as a cronjob on our server.
Now we ran into the following issue:
There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for: xyz.com
What can I do now?
How do I increase the limits?
Thanks,
Sebastian
For just renewal, this shouldn’t be happening. Perhaps your certbot has been configured to issue certificates even if the renewal date isn’t due yet. Could you give us the command in your cronjob and the contents of /etc/letsencrypt/cli.ini ?
We are currently hitting one of your rate limits:
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for ssl.domain.com
http-01 challenge for sub.domain1.com
http-01 challenge for sub.domain2.com
http-01 challenge for sub.domain3.com
http-01 challenge for sub.domain4.com
http-01 challenge for sub.domain5.com
http-01 challenge for sub.domain6.com
http-01 challenge for sub.domain7.com
http-01 challenge for sub.domain8.com
http-01 challenge for sub.domain9.com
http-01 challenge for sub.domain0.com
http-01 challenge for sub.domain10.com
http-01 challenge for sub.domain11.com
http-01 challenge for sub.domain12.com
http-01 challenge for sub.domain13.com
http-01 challenge for sub.domain14.com
http-01 challenge for sub.domain15.com
http-01 challenge for sub.domain16.com
http-01 challenge for sub.domain17.com
http-01 challenge for sub.domain18.com
http-01 challenge for sub.domain19.com
http-01 challenge for sub.domain20.com
http-01 challenge for sub.domain21.com
Waiting for verification…
Cleaning up challenges
An unexpected error occurred:
There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for: domain.com
We know that we hit the limit because we issued too many certificates which include the “domain.com” domain. Although we could use your staging system for the tests, the situation on our production system will be the same.
The problem is, that in our service the end users will add and remove domains (with CNAMES pointing to our server) and we always will create a new certificate which includes the current list of domains.
We cannot predict how often new domains will be added.
We believe that we will hit your rate limits again when we go into production and so we would like to ask you to increase the rate limits for our account or give use some hints how we can improve our certificate recreation logic.
NOTE: domain.com == placeholder
If you can’t share your domain name, can you check with https://crt.sh that you didn’t inadvertently created a lot of certificate for that domain?
Please share your real domain name. That will make it much easier to help you.
here are the details.
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for ssl.yumpu.com
http-01 challenge for xtrablatt.krone.de
http-01 challenge for boeden.holzschwab.de
http-01 challenge for tueren.holzschwab.de
http-01 challenge for outdoor.holzschwab.de
http-01 challenge for spezial.holzschwab.de
http-01 challenge for epaper.holzschwab.de
http-01 challenge for webssl.webberz.at
http-01 challenge for sslwebkiosk.webberz.at
http-01 challenge for sslwebkiosk.webberz.ch
http-01 challenge for webssl.webberz.ch
http-01 challenge for webmeb.webberz.ch
http-01 challenge for web6.webberz.ch
http-01 challenge for web7.webberz.ch
http-01 challenge for livekiosk.webberz.ch
http-01 challenge for berliner-zeitung.kiosk.plus
http-01 challenge for kiosk.barnhouse.de
http-01 challenge for web8.webberz.ch
http-01 challenge for web9.webberz.ch
http-01 challenge for kiosk.kueche-co.de
http-01 challenge for magazine.kueche-co.de
http-01 challenge for web10.webberz.ch
http-01 challenge for web1.funbooth.at
Waiting for verification…
Cleaning up challenges
An unexpected error occurred:
There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for: webberz.at
That's a flawed method IMO and the reason why you're hitting a rate limit. Why get a certificate containing all the domains over and over again? Is there a certain reason for that?
Ah, this explains the problem. Yes, this approach will definitely make you hit rate limits frequently. The main reason to take this approach would be if you need to support browsers that don't send ServerNameIndication (SNI) and so you have to have a unique IP address for each certificate you serve. Unfortunately, this model is a little hard to make work with Let's Encrypt.
First, I would suggest issuing a single certificate per registered domain name, if you can.
If you can't, I would suggest getting a handful of extra IP addresses. You can then break up the week into 20 chunks (to match the 20 certificates per registered domain rate limit). When a new customer comes on board, issue them a solo certificate and put them on their own IP address for a little while. Once you hit the next "chunk," you can consolidate that customer onto a shared certificate with a bunch of other customers, and free up that IP address.
But again, I would strongly recommend a single certificate per registered domain if possible. ServerNameIndication is supported by all major browsers. See Server Name Indication - Wikipedia and The HTTPS-Only Standard - Server Name Indication.
We are currently using AWS with an application load balancer.
There we only can have one certificate installed. Therefore we need all domains in one certificate.
I believe AWS Application Load Balancer is built on top of ELB, right? Amazon has their own free certificate authority, Amazon Certificate Manager (ACM), that integrates automatically with ELB. That may wind up being easier to use for your use case.
The problem is that ACM is not the right solution for us. Because all domain hostmasters get informed after a new domain is added in our system. In that case if we have 400 domains all hostmasters need to confirm the email notification and only if that happens the new domain is in that certificate.
As I am not familiar with ACM can you clarify the below (as a workflow)
For example: a client want us to protect x
in order to get a certificate from ACM we need them to confirm so ACM
etc etc
Can you also clarify how the operation of Let's Encrypt is different and more beneficial so others may suggest approaches.
The problem is that ACM is not the right solution for us. Because all domain hostmasters get informed after a new domain is added in our system. In that case if we have 400 domains all hostmasters need to confirm the email notification and only if that happens the new domain is in that certificate.
Having used ACM before, it operates similar to a traditional CA in that it will e-mail the WHOIS contact for each domain and requires them to click a link and approve the certificate issuance. The main difference is that the certificates are available at no charge. This means that when Mr. Moser needs to issue an updated certificate due to packing the domains, all the contacts would get an e-mail and have to individually approve the issuance rather than simply being able to verify via webroot or similar method.
Thanks motoko. That’s correct. I need a solution like let’s encrypt.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.