There were too many requests of a given type :: Error creating new order ** shared domain **

Help
1

I am writing to seek your assistance with an issue I have been encountering over the past two months while attempting to obtain a certificate for the subdomain "*.crm.cloud.sap".

When I try to create the order, I receive the error: "There were too many requests of a given type :: Error creating new order :: too many certificates already issued for 'example.com'".

I have reviewed the Let's Encrypt rate limits and understand that there is a limit of five certificates per registered domain within a seven-day window. However, I can assure you that I have only attempted to create this certificate once per day for the past two months.

Given that our company shares the base domain "cloud.sap" with several other business units, it is possible that another team may be inadvertently exceeding the rate limit, affecting my attempts to obtain the certificate for "*.crm.example.com".

I would be extremely grateful if you could please help me to:

  1. Investigate the reason behind the "too many requests" error for "cloud.sap". and check if there have been excessive certificate issuance attempts for this domain recently, and if so, if they can be identified and potentially attributed to other internal teams?
  2. Suggest potential solutions to obtain the certificate for "*.crm.cloud.sap". Would it be possible to increase the rate limit for our specific use case, or are there alternative methods to proceed (e.g., requesting a wildcard certificate)?

Thanks in advance.

Raul

2

Using the public Certificate Transparency (CT) logs I see 600 certs issued for that root domain in the past week. I used This Tool and searched for crm.cloud.sap

I would guess that Let's Encrypt has previously granted a rate limit for that registered domain. The "5 / week" limit is for certs using the exact same names. There is a limit of "50 / week" for certs for the same registered domain (by default).

If you run a search for that name do you see names meaningful to you?

The below page explains requesting rate limit exceptions. Probably should ask other members of your organization's IT staff to best coordinate the limits.

5 Likes
3

What's the actual domain in that error message?

This is probably solved by adding that domain to the public suffix list, but only whoever controls the domain (all of it) should do that.

Another alternative is to use a cname and get a certificate for the cname and the cname alone. IE: cloudsap.yourcompany.example.com

4 Likes
4

Usually rate limit exemptions are coupled to an ACME account, at least, that's the recommendation from Let's Encrypt. When a different account is being used, those rate limits suddenly won't apply (any longer). Might be the case here?

2 Likes
5

Yes, for sure. Was just suspicious that there were exactly 600. They may be using the wrong ACME account and/or the rate limit is maxed out.

In either case they need to work with their org's IT staff to figure out how to proceed. Right?

5 Likes
6

OR
Get some certs from another [free] CA.

3 Likes
7

Here’s a list of other Free ACME Certificate Authorities to choose from:

ACME CA Comparison - Posh-ACME

2 Likes
8

Thanks Mike,

I checked the debug toolkit and sent an email to the biggest certificate usage team but I have a doubt:

Based on this section of the documentation, even if we share the same root domain, shouldn't be a difference, for example, in the quote for crm.cloud.sap and one.cloud.sap?

Thanks again

A certificate is considered a renewal (or a duplicate) of an earlier certificate if it contains the exact same set of hostnames, ignoring capitalization and ordering of hostnames. For instance, if you requested a certificate for the names [www.example.com , example.com ], you could request four more certificates for [www.example.com , example.com ] during the week.

If you changed the set of hostnames by adding [blog.example.com ], you would be able to request additional certificates.

1 Like
9

Yes, that is the Rate Limit for duplicate certs in a week. But, that is not the only Rate Limit. The one that seems operative here is this (from this link)

The main limit is Certificates per Registered Domain (50 per week). A registered domain is, generally speaking, the part of the domain you purchased from your domain name registrar. For instance, in the name www.example.com , the registered domain is example.com . In new.blog.example.co.uk , the registered domain is example.co.uk . We use the Public Suffix List to calculate the registered domain. Exceeding the Certificates Per Registered Domain limit is reported with the error message too many certificates already issued , possibly with additional details.

Because there are obviously far more than 50 for that registered domain it seems there is already a granted exception by Let's Encrypt. I looked at the Public Suffix List and that domain was not there. The instructions for requesting exceptions to rate limits is on that rate limit page.

Are you the registered owner of that root domain? This seems like a service and perhaps that service provider needs to request a higher limit.

3 Likes
10

Hey Mike, thanks for your help on this issue.

I've continued working with the tool and I see several of my existing certs being renewed even with the high number of request from other teams but as 10 min ago I still create create NEW certs, specifically for *.vlab.demo.crm.cloud.sap

Serial/crt.sh link Issued Domain List
CFC3F61B3FAACERTIFICATE 25 Jan 2024 04:36:21 UTC *.br1.demo.crm.cloud.sap
CB62E201E2D8CERTIFICATE 22 Jan 2024 12:49:49 UTC au.crm.cloud.sap
297C0DEF533ACERTIFICATE 20 Jan 2024 01:59:12 UTC *.au1.demo.crm.cloud.sap
4377EEA7E953CERTIFICATE 20 Jan 2024 01:45:02 UTC *.de1.demo.crm.cloud.sap
47AE9E4759C5CERTIFICATE 19 Jan 2024 05:49:56 UTC us.crm.cloud.sap
D6C13CCDCA6FCERTIFICATE 31 Jan 2024 09:06:49 UTC de.vlab.crm.cloud.sap
9B5151CAD917CERTIFICATE 30 Jan 2024 16:49:37 UTC *.vlab.crm.cloud.sap
1A5CAAD6119BCERTIFICATE 30 Jan 2024 16:45:02 UTC *.vlab.crm.cloud.sap
3B77FDD687ADCERTIFICATE 30 Jan 2024 16:43:27 UTC *.vlab.crm.cloud.sap
C2BD5633EAC5CERTIFICATE 30 Jan 2024 14:53:25 UTC *.vlab.crm.cloud.sap
780EB9C52A51CERTIFICATE 30 Jan 2024 14:37:25 UTC *.vlab.crm.cloud.sap
CFC3F61B3FAACERTIFICATE 25 Jan 2024 04:36:21 UTC *.br1.demo.crm.cloud.sap

My understanding is that renewals and new certs don't get into the same rate limit, if so, why can I renew my certs and cannot order new ones?

Is there a way to get a list of just new created certs? I cannot find a way to differentiate them with the tool

Thanks again.

Raul

1 Like
11

Renewals do not count against the rate limit for "certificates per domain". New certificates do. A renewal is subject to duplicate certificate limit.

The rate limits are on rolling windows, so you can sometimes get something through on sheer luck of timing.

If you have a partition of domains that are dedicated to clients, it may be worth getting a namespace placed on the Public Suffix List. That would remove the rate limits with LetsEncrypt and instruct several browsers to treat the domains as independent of each other when it comes to browser sandboxing rules.

It looks like your domains are all for internal usage though. IMHO, the right approach for this would be to have your IT department use a CAA record to lock LetsEncrypt usage onto a single account and then use an internal system to coordinate and throttle requests so your company can centrally prioritize their needs. You're probably dealing with the pain of multiple departments competing for this finite resource. It is very common with academic universities, but some large companies fight with it too.

Another option would be using a commercial CA. SAP is a giant tech company and can easily afford an enterprise account.

No. That tool is an independent third party tool that uses the public data on crt.sh which is another independent third party tool. Only ISRG/LetsEncrypt has access to the underlying data.

6 Likes
12

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