Rate Limit Increase

Issuance Tech
1

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

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

2

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

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.

3 Likes
3

@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?

4

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:

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.

4 Likes
5

@schoen
I have just tried to request a certificate for 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?

6

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?

Without any information we cannot say.

3 Likes
7

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

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

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
4 Likes
8 
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.

2 Likes
9

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

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

5 Likes
10

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