# Rate Limit Increase

**URL:** <https://community.letsencrypt.org/t/rate-limit-increase/169997>\
**Category:** Issuance Tech\
**Created:** [January 19, 2022, 7:19am UTC](https://community.letsencrypt.org/t/rate-limit-increase/169997 "2022-01-19T07:19:00Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![ido-vcita](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ido-vcita/32/57589_2.png) [@ido-vcita](https://community.letsencrypt.org/u/ido-vcita)\
**Post date:** [January 19, 2022, 7:19am UTC](https://community.letsencrypt.org/t/rate-limit-increase/169997/1 "2022-01-19T07:19:00Z")

</div>

Hello,

We have started to issue more certificates for our wildcard since we have consumers.  
It appears to be that we have reached our rate limit according to this tool: [https://tools.letsdebug.net/cert-search?m=domain&q=vchost.co&d=168](https://tools.letsdebug.net/cert-search?m=domain&q=vchost.co&d=168)

Would it be possible to increase the rate limit there? If not, are there any workarounds?

---

<div class="post-metadata">

**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\
**Post date:** [January 19, 2022, 8:53am UTC](https://community.letsencrypt.org/t/rate-limit-increase/169997/2 "2022-01-19T08:53:49Z")

</div>

Hi @ido-vcita,

The rate limit that you're reaching here (for duplicate certificates) is not one that Let's Encrypt typically grants an increase for; in fact, I'm not sure whether software tools have even been created to allow that on the certificate authority side.

The people operating the certificate authority would probably prefer for you to pursue a different issuance strategy whereby the names in the certificates are not exact duplicates. Also, if the devices to which these certificates are issued are directly controlled by the customers, that may not be appropriate because the customers could use the certificates to impersonate one another's sites. If the devices are controlled by you rather than by the customers, you might be able to re-use the same certificate on multiple servers or devices.

There is a rate limit increase form that you can fill out to describe your situation

> **[Let's Encrypt Rate Limit Adjustment Request Form](https://docs.google.com/forms/d/e/1FAIpQLSetFLqcyPrnnrom2Kw802ZjukDVex67dOM2g4O8jEbfWFs3dA/viewform?usp=send_form)**
>
> Depending on the availability of our team, we look at form responses daily and move the adjustments to production once weekly. We will do our best to consider your application in a timely manner but we cannot guarantee acceptance or any form of...

but, again, I think the most likely response would be that the certificates per registered domain limit can be increased when you are hosting many separate customers or entities' sites under a single registered domain, while the duplicate certificate rate limit (for certificates issued during the same week that cover exactly the same set of names) cannot be increased.

---

<div class="post-metadata">

**Author:** ![ido-vcita](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ido-vcita/32/57589_2.png) [@ido-vcita](https://community.letsencrypt.org/u/ido-vcita)\
**Post date:** [January 19, 2022, 9:37am UTC](https://community.letsencrypt.org/t/rate-limit-increase/169997/3 "2022-01-19T09:37:38Z")

</div>

@schoen the consumers are not end users. It's our developers.  
We are making a clone of our production with selected services in a new K8S namespace.

This feature is now more widely used. If we request certificate to a specific domain (rather than a wildcard), would that solve our issue?  
What do you mean by different issuance strategy? What other issuance strategies can be suited to our use case?

---

<div class="post-metadata">

**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\
**Post date:** [January 19, 2022, 9:48am UTC](https://community.letsencrypt.org/t/rate-limit-increase/169997/4 "2022-01-19T09:48:52Z")

</div>

If the instances are all under your control, you could copy a single wildcard certificate between them. A single certificate can be used by multiple devices or services, as long as they're accessed under names that are matched by that certificate.

If that doesn't seem practical or doesn't appeal to you, then:

> [@ido-vcita](#):
>
> This feature is now more widely used. If we request certificate to a specific domain (rather than a wildcard), would that solve our issue?

It would probably be an improvement from the Let's Encrypt rate limit point of view. First, a different rate limit would apply compared to the one that you're currently reaching. The other rate limit that would apply is much more lenient than the one you're being limited by, permitting a much greater volume of certificate issuance. Second, if you do eventually need to request a rate limit increase anyway, it would be easier for Let's Encrypt to approve that request within its existing policy and technical framework if the certificates are getting issued for individual subdomains used for distinct customers' services.

---

<div class="post-metadata">

**Author:** ![ido-vcita](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ido-vcita/32/57589_2.png) [@ido-vcita](https://community.letsencrypt.org/u/ido-vcita)\
**Post date:** [January 19, 2022, 10:24am UTC](https://community.letsencrypt.org/t/rate-limit-increase/169997/5 "2022-01-19T10:24:56Z")

</div>

@schoen  
I have just tried to request a certificate for [ido-test-cert-ido-test.external.int-eks.vchost.co](http://ido-test-cert-ido-test.external.int-eks.vchost.co) and it is stuck in pending for some reason. It is not a wildcard, so what's the issue now?

---

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [January 19, 2022, 12:12pm UTC](https://community.letsencrypt.org/t/rate-limit-increase/169997/6 "2022-01-19T12:12:48Z")

</div>

> [@ido-vcita](#):
>
> We are making a clone of our production with selected services in a new K8S namespace.

I have no idea what "selected services" or "K8S namespace" is (it already sounds terrible), but isn't it possible to have the certificate(s) available on all instances on a _shared_ location?

> [@ido-vcita](#):
>
> so what's the issue now?

Without _any_ information we cannot say.

---

<div class="post-metadata">

**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\
**Post date:** [January 19, 2022, 4:06pm UTC](https://community.letsencrypt.org/t/rate-limit-increase/169997/7 "2022-01-19T16:06:39Z")

</div>

> [@Osiris](#):
>
> K8S namespace

K8S is Kubernates. Namespaces are used for partitioning of resources.

> [@ido-vcita](#):
>
> It is not a wildcard, so what's the issue now?

No one here has access to LetsEncrypt's infrastructure. You need to share detailed info about your errors.

> [@ido-vcita](#):
>
> We are making a clone of our production with selected services in a new K8S namespace.

The proper solution for your situation is to recycle/share your certificates. Your scaling/deployment strategy for Certificates exhibits a common anti-pattern. Common fixes include, but are not limited to:

- Store certificates in the cloud; read on startup/cron
- Store certificates on a shared volume; read on startup/cron
- Have one node responsible for Certificates, and other nodes pull/copy the certs on startup/cron
- Have one node responsible for Certificates, and push to nodes on new procurement

---

<div class="post-metadata">

**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\
**Post date:** [January 19, 2022, 6:13pm UTC](https://community.letsencrypt.org/t/rate-limit-increase/169997/8 "2022-01-19T18:13:36Z")

</div>

> [@ido-vcita](#):
>
> It is not a wildcard, so what's the issue now?

```nohighlight
Name: af65d5f47e81311e9af3b06cb2255b9b-363470606.eu-central-1.elb.amazonaws.com
Addresses: 3.120.90.238
           35.157.5.133
           3.66.135.162
Aliases: ido-test-cert-ido-test.external.int-eks.vchost.co

```

Multiple IPs might have something to do with the failure.

If you tried issuing it via `DNS-01` authentication (as were the wildcards), this should be no problem.

---

<div class="post-metadata">

**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\
**Post date:** [January 19, 2022, 6:27pm UTC](https://community.letsencrypt.org/t/rate-limit-increase/169997/9 "2022-01-19T18:27:12Z")

</div>

@ido-vcita for context for @rg305's point, see

> **[Challenge Types - Let's Encrypt](https://letsencrypt.org/docs/challenge-types/)**
>
> When you get a certificate from Let’s Encrypt, our servers validate that you control the domain names in that certificate using “challenges,” as defined by the ACME standard. Most of the time, this validation is handled automatically by your ACME...

Note that HTTP-01 connects to your web server, while DNS-01 checks a DNS record.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [February 18, 2022, 6:27pm UTC](https://community.letsencrypt.org/t/rate-limit-increase/169997/10 "2022-02-18T18:27:22Z")

</div>

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