[Solved] Rate limit increase didn't seem to take

Help
1

My domain is: a.ayende.dbs.local.ravendb.net

I’m using Certes (https://github.com/fszlin/certes) to generate certificates.

We asked for (and got) and increase of the weekly certificates that we are generating for subdomains.
However, it doesn’t seem to take.
We generated about 20 of these so far, and we started getting 429 rate limits errors.

The error is:

Error creating new cert :: too many certificates already issued for: ravendb.net (429)

What is interesting here is that the domain is “ravendb.net” and not “dbs.local.ravendb.net”

I think that this may be related to the fact that I’m using two subdomains, so “a.ayende” instead of just “ayende”.

Could this be related? Is it checking just the root subdomain and not the whole thing?

2

Rate limits are imposed on domain names - how many subdomains you use doesn’t matter.
See https://crt.sh/?q=%.ravendb.net for list of FQDNs that were successful.

3

Which domain was the rate limit exemption supposed to be granted for? Do you know how big an exemption it was supposed to be?

4

It was 5000, and it was for dbs.local.ravendb.net

We have customers that will use that and then we define a SAN certificate with:

So we want to use that as a child subdomain of the dbs.local.ravendb.net, which we got the rate increase for.

5

Okay, I just tested this again, and there seems to be no difference.
a-ayende.dbs.local.ravendb.net will also error for us.

So my initial assumption that this was about the nested subdomain seems to be in error.

The rate increase just didn’t take, even though we got an email saying that the rate limit was increased?

6

@cpu, could you double check what the rate limit status is for this domain?

7

@schoen Just to verify. If I have a rate limit on “dbs.local.ravendb.net”, does that apply to domains and subdomains, or just to the first subdomain?

In other words, can I use: “a.ayende.dbs.local.ravendb.net” and that would apply to “dbs.local.ravendb.net”, or would only the first level “a-ayende.dbs.local.ravendb.net” apply?

8

I don’t know how it’s implemented, but I would expect it to apply to all levels of subdomains.

9

That would have been my expectation as well, the rate limit really threw us off here, and that was the only thing that made sense. If this is indeed the case (any level) that would be wonderful once we sort out the rate limit issue.

10

I'll inquire with our operations team about this thread.

Edit: checking the entry it looks like this was a mistake on our end. It was added as dbs.local.ravendb.net when it should have been ravendb.net for this rate limit. I've let our operations team know, they will investigate.

11

If the rate limit exemption was for the "Certificates per registered domain" rate limit it would need to be added for "ravendb.net". It applies to the eTLD+1.

12

Another question, the raised limit is for the domain, right? It is not tied to a specific account key.
The reason I’m asking is that I don’t believe that there has been any key that I specified that would get the rate limit increase, so I assume that any request to the domain would enjoy the raised limit.

13

Is there a reason not to use an account ID in this case @ayende? In general we prefer to rate limit off of account if at all possible.

That said, this rate limit was not set for an account ID, only the domain name. As has been already stated, there was some internal confusion as to whether we could specify subdomains. The rate limit on certificates per name can only be set for a TLD+1, so this would need to be for ravendb.net, which, if you don’t control all of ravendb.net, will mean others could issue certs eating into that rate limit.

14

I’m controlling all of ravendb.net, so that is not an issue.

Here is the full story. I’m build a database that want to use HTTPS, but it is usually deployed inside local networks, without being able to expose them externally.

In order to save the trouble of the admin the trouble of managing certificates manually, we take that on ourselves.
The end user will start the challenge process, and then call to us with a request to reserve a particular subdomain on our end.
The is effectively the username for that particular user and is reserved just for them. Then they can place nodes (a.ayende, b.ayende, etc) under that.

The local server at the customer site then call to our website with the LE DNS details and let the local server know that.
The local server then complete the LE challenge and get the certificate.

The idea is that the certificate itself never hit our servers and is completely within the customer’s own network.

That means, of course, that each local server is going to be using its own key.

We could change things so the central server will handle the entire process and hand the certificate back to the user from the central location, but I would rather avoid it unless this is required.

15

As an aside, thank you for the quick responses. As you can imagine, this has been a spanner in the works for us and I really appreciate your support.

I have to say though that I’m not following what is going on. The rate limit was applied, I understand, but both x.y.dbs.local.ravendb.net and x-y.dbs.local.ravendb.net seem to have hit the rate limit.

Is there current a domain name pattern that I can use that will use the apply to the rate limit?

16

The rate limit was set as dbs.local.ravendb.net in the rate policy.
Boulder ignores this as it is expecting only a TLD+1.
What should be in the policy is ravendb.net.

At this point there is effectively no rate limit increase in place since Boulder ignored the unexpected entry with subdomains.

17

We’re making some internal adjustments to processes and I expect there will be a new push to rate limits within the next 24 hours to correct this.

18

Okay, that make more sense. Is it possible to move the rate limit increase to “ravendb.net” and generate the nested domains as we want to?
I don’t have an issue with having the limit on a higher level.

19

Hi @ayende, that's exactly what @isk is working on :slight_smile: They will provide an update once the rate limit for ravendb.net is in place, allowing issuance for the nested domains.

20

The limits have been fixed and you should be able to issue as expected @ayende