The problem is simple, I’ve start to issuing certificates for one of our company domains using acme.sh and aws-dns integrated API so domain verification was automated. After the rate limit for the domain was hit I realize that it actually has one. Too naive from my side, but it was honest mistake, no to read all the documentation. Now I’m facing the expiration of the old certificate for the domain on the 9th of Feb and no way of fixing this problem.
What I have tried:
Issue, reissue certificate for the last valid domain with SAN for the rest over the limit.
Delete the last single domain that was issued and trying to create new certificate with SAN.
Can I contact the Let’s Encrypt team in order to ask them to delete the certificates for the domain, with the promise of issuing one new certificate for all sub-domains that I need ?
Are there any ways to work around this, any suggestions ?
Here is the message that I’m getting, while I’m trying to issue new certificate:
[Tue Feb 6 13:06:28 UTC 2018] Verify finished, start to sign.
[Tue Feb 6 13:06:30 UTC 2018] Sign failed: “detail”:"Error creating new cert :: too many certificates already issued for: *******.com: see https://letsencrypt.org/docs/rate-limits/"
I prefer the actual domain to stay hidden from the public community, if it’s needed I can share it over a private message.
Thank you for the swift reply!
I'm not positive whether you reached the identical certificates rate limit (many certificates covering exactly the same set of names) or the certificate per registered domain rate limit (many certificates each mentioning subdomains of example.com). I guess it's probably the second one.
However, there are no available tools to delete certificates with effect on the rate limits or to temporarily reset the rate limits.
As explained on the rate limit page, you can always reissue an existing expiring certificate without regard to the rate limits. This is a built-in exception. However, you must use the exact same set of domains that were covered by the previous certificate in order for your new issuance to qualify for that exception. (There is a limit to how many certificates with identical coverage you can get at a time, but if the only existing Let's Encrypt certificate with that particular combination of domains is now close to expiring, the rate limits will never stop you from getting a new certificate with that same combination.)
Apart from telling us what the domain is, you could also use lectl to learn about the exact rate limit status for your domain:
Thank you for the reply, I’ve hit the limit for a domain. It seems that this situation will stick to me and I’ll find another solution for it. The problem is that I have more certificates to be issued for this domain and this situation - of me not hitting the documents hard enough, will stop me to issue all the needed certificates on them (before the end of this week).
In short:
I’ve issued for subdomain1 … subdomain20.example.com and still in need to issue around 20 more certificates for subdomains in example.com domain zone.
Thank you once again for the you informative answer, besides my little information that I’ve provide.
In the documents the limit reset mechanism is little bit unclear for me, can you tell me this:
In the start of the week, say Monday, the limit is reset at full or as they was consumed during the last week?
So, please keep in mind that a certificate can cover more than one name, and the rate limits are always calculated in terms of certificates issued, not in terms of names covered. Let's Encrypt allows a single certificate to cover up to 100 names, which means that you can cover 2,000 new subdomains of a single domain per week by issuing 20 new certificates which each cover 100 subdomains.
I realize that this then requires every device using that certificate to share the same private key, which might not be a good fit with some security models. If the subdomains are used by or on behalf of separate people or entities (e.g., separate customers of a hosting provider), you might qualify for a rate limit exception, although this takes several weeks to approve. If they're used by different parts or projects of the same organization, a rate limit exception isn't usually available.
The rate limit always looks at the past 7 days (168 hours). So if it's Tuesday, the rate limit considers all of the issuance since the previous Tuesday. There isn't a particular day when it's reset. The lectl tool can calculate the status accurately and tell when you can issue the next new certificate.
Thank you @schoen, for the detailed explanation, it is very helpful especially the script.
Just checked with the script and it seems that everything is as expected. One little exception - last week while I was testing, I’ve issued a certificate for the same domain on Friday. Yet yesterday I was able to issue another 20 certificates, which leads me to believe that the count is resetting on the end (or start) of the week. So in my case I should be able to issue certificate as early as Monday next week and yet the scripts shows that the next certificate can be issued on Tue 13.Feb. This confuses me, please see the attached picture.
Sorry, I can’t help unless @AleksMM provides the domain names. @AleksMM, all of your domain names are publicly available through certificate transparency logs at https://crt.sh/, so there is no advantage in hiding them.
Hello @schoen , I’ve shared the domain name in private message to @jsha . And it seems that there is no workaround for my problem so from now it seems that is just a case study with different then expected behavior of the script or the Let’s Encrypt authority.
Thank you all for the answers and I’ll watch this topic for the development.
One situation that can cause this: If you issue for 20 different subdomains, hitting the rate limit, you can still early-renew each of those subdomains under the Renewal Exemption, up to the duplicate certificate limit. So in theory you could issue 20 certificates, then 20 renewals, then 20 renewals, then 20 renewals, then 20 renewals. Of course, there would be no reason to do this and it would be a bit of a waste of resources.
