maybe I do have an odd question, but I cannot find a clear answer so far:
When exactly is an order considered to be a "renewal"? Will say: Afaik a "renew" is technically the request of a duplicate certificate, thus, there must have been an "original" certificate on what the duplicate is based on. How old can such an "origial" certificate be? Does this "original" still have to be valid when placing the order for a duplicate? What happens if the "original" has been revoked and I order a duplicate? In other words: How long and with what conditions does the ratelimit logic look back in time to check if an order can be considered to be a "renew"?
The API itself does not distinct between "issue" and "renewal" (everything is just an "order"), but in case of ratelimits, it would matter if an order is a new issuance or if it is a renewal.
If anyone could give me a hint, I would appreciate that.
Yes, but since a while, there are differences between a "new issue" and a "renew" when it comes to calculate the ratelimit values. Thats why my question.
When I request a duplicate certificate after its "original" became invalid (e.g. after 90 days), is it still not counting against the domain relevant rate limit?
Background of these questions is: Even if the main ratelimit has been exceeded (50 new certs per week), one could still request "renewals" if those orders are duplicates of a previous issued certificate. But is there any condition on that previous certificate? Or can that even be older then 90 days or revoked?
The above answers sound like there are no special conditions. Every order can bee seen as a "renewal" (and thus, it does NOT count against the main rate limit) if there ever was a previous identical cert - even if that was a LONG time ago. Is that really true?
The next 7 days I cannot order cert number 51 (host51.example.com) for that domain as I would hit the main ratelimit (50 certs max), so far so good.
Now, 8 weeks later, I renew these 50 certs from 1), so far so good.
In this week, can I order a NEW cert number 51 for that domain (host51.example.com)? Or did the 50 "renews" in 3) also affect the main ratelimit for that domain?
The above scenario is NOT about "I can do renewals even if the main ratelimit for new certificates is exceeded", that is explained it the doku.
My question is about the other way around: Can I get NEW certs for a domain in case I did 50 renewals in that domain-scope already in that week?
By the documentation when you renew after 8 weeks all your 50 certificates, they do not count into the new certificate rate limit, so you should have no problem getting the 51th certificate.
If you read very carefully the document, there is no mentioning of time limit constraint of the ACME server to remember; is it already issued a certificate for a given set of domain names or not? From that, we can clearly deduce that the ACME server remembers forever the set of domain names it already issued certificate.
For example, you have 1000 different certificates host000.example.com through host999.example.com (you accumulate all those during 20 weeks due to 50/week new cert rate limit). Then, you do not renew them for 10 years at all.
Suddenly, after 10 years you decide to renew all of them in one shoot, no rate limit issue, no surprise.
func (ra *RegistrationAuthorityImpl) checkCertificatesPerNameLimit(ctx context.Context, names []string, limit ratelimit.RateLimitPolicy, regID int64) error {
// check if there is already an existing certificate for
// the exact name set we are issuing for. If so bypass the
// the certificatesPerName limit.
exists, err := ra.SA.FQDNSetExists(ctx, names)
if err != nil {
return fmt.Errorf("checking renewal exemption for %q: %s", names, err)
}
func (ssa *SQLStorageAuthority) checkFQDNSetExists(selector oneSelectorFunc, names []string) (bool, error) {
var count int64
err := selector(
&count,
`SELECT COUNT(1) FROM fqdnSets
WHERE setHash = ?
LIMIT 1`,
hashNames(names),
)
return count > 0, err
}
so it doesn't care about how old 'old' certificate was, if it remember it issued.
(unless if something major happens and LE choose or had to drop database or purge old record(can they?)
Perfect! And combining all the answers together, this should be the outcome:
If someone collects hundreds of certificates over time (all for the same domain), and the certificate management tool (whatever that might be) has a hickup and attempts a renew of all these certificates at the same time (bad thing, yes), this is what happens then:
All the renews will be successful as there is no main ratelimit preventing you from ordering duplicates for many (>50) different certs (up to the duplicate ratelimit, of course).
Even after all these (>50) same-time renewals, in that week, one can still order 1..50 NEW certificate(s) for that domain (max 50).
This massive order-request in 1) will still be treated as a big bunch of renewals (for the rate limit logic), regardless of how old the original certs were. They could have been issued >90 days ago, they could have been revoked or otherwise invalid, the orders in 1) will still be seen as renews.
I recently drafted an overhaul of the rate limits page to clarify many things that is awaiting final review. I'm going to post the current text of that draft below. As for renewals, one line in particular is of pertinence.
A renewal certificate is a duplicate certificate that has been acquired to replace a certificate near expiry.
Foreword
Although Let's Encrypt offers SSL/TLS certificates free of charge, unfortunately those certificates are not free to produce. Considerable resources are needed to operate, maintain, and improve the hardware and software necessary to satisfy growing demand. As a non-profit, we greatly appreciate the generous support and donations that enable us to continue fulfilling our mission of furthering a secure and privacy-respecting Web for everyone. To that end, we endeavor to ensure that we leverage the resources with which we have been blessed as best we can.
To ensure fair usage, Let's Encrypt enforces rate limits that we believe to be reasonable for most scenarios. Our rate limits were designed to facilitate unhampered certificate renewals and increasing certificate usage by growing organizations. If you are integrating Let's Encrypt into your operations, please review our Integration Guide to ensure smooth operation. In particular, we recommend using one ACME account for many customers. If you are developing an ACME client, debugging the usage of one, or configuring an automated system, please take advantage of our staging environment, which is governed by higher rate limits and issues disposable certificates.
We have no way of temporarily overriding the rate limits. For very large providers who are encountering rate limits due to sheer volume, we provide a rate limiting form that can be used to request higher rate limits. Since these requests require strong justification for higher rate limits and can take several weeks to process, the rate limiting form is not suitable for addressing temporary situations that will automatically be resolved when any encountered rate limits no longer apply.
Revoked certificates still count against our rate limits and remain in the public record. All issued certificates can be found using crt.sh, which aggregates public certificate transparency (CT) logs. In general, certificate revocation should only be considered under very particular circumstances, such as the compromise of a certificate's private key or the loss of control over a certified domain name. Revocation of a certificate only invalidates its trust for future use. If an unexpired certificate is no longer needed, securely deleting the certificate's private key is usually sufficient to decommission the certificate.
Rate Limits
Message: too many certificates already issued for exact set of domains
Hitting this limit is often the result of using the following practices that should be avoided:
Deleting valid certificates (and their private keys) when attempting to resolve webserver configuration problems
Spinning-up ephemeral instances or containers that acquire new certificates from the CA rather than utilizing an existing certificate
Having each worker in a load-balancing scheme acquire its own certificate from the CA rather than terminating SSL/TLS at the load-balancer or distributing a common certificate to each worker
Note that there is usually no need (and it is usually inadvisable) to include every FQDN served by the same webserver in a single certificate. Most modern webserver software distributions support SNI to select the correct certificate.
Message: too many new orders recently
Limit: 300 new orders / ACME account / 3 hours
Hitting this limit is often the result of:
Large-scale operations attempting to acquire too many certificates in parallel
A malfunctioning ACME client
If a new order is requested and there already exists a pending order covering the exact same FQDNs, the pending order will be returned and a new order will not be created.
Message: too many currently pending authorizations
Limit: 300 pending authorizations / ACME account
Hitting this limit is usually the result of a malfunctioning ACME client. If you know the URL of a pending authorization of the form /acme/authz/XYZ, which can likely be found in the log of your ACME client, you can trigger a validation attempt for that authorization by submitting a JWS-signed POST request to any of its challenges as described in the ACME specification. Regardless of the outcome of the validation attempt, the authorization will no longer be pending.
Limit: 20 requests / second
Hitting this limit is usually the result of a malfunctioning ACME client. This limit applies collectively to requests for the "new-reg", "new-authz", and "new-cert" ACMEv1 API endpoints and the "new-nonce", "new-account", "new-order", and "revoke-cert" ACMEv2 API endpoints.
Limit: 40 requests / second
Hitting this limit is usually the result of a malfunctioning ACME client. This limit applies collectively to requests for the "/directory" endpoint and the "/acme" directory and subdirectories.
Definitions
Apex Domain Name
An apex domain name is usually the trailing part of an FQDN registered through a registrar. For instance, example.com is the apex domain name of www.example.com. We use the Public Suffix List to determine the apex domain name for any given FQDN.
Duplicate Certificate
A certificate is considered a duplicate if it contains the exact same SANs as another certificate, regardless of order. A renewal certificate is a duplicate certificate that has been acquired to replace a certificate near expiry.
Fully Qualified Domain Name (FQDN)
An FQDN is a complete domain name consisting of any subdomain names and an apex domain name.
Subject Alternative Name (SAN)
Each FQDN that a certificate covers is listed as a SAN in the certificate. A certificate with multiple SANs is sometimes called a unified communications certificate (UCC). Reducing the number of SANs in a certificate reduces the operational complexity associated with using the certificate, resulting in increased performance and reliability.
Server Name Indication (SNI)
Extension to the TLS protocol by which a webserver discerns which certificate to send to a client based on the hostname requested by the client.
Correct, as long as all of those renewal certificates cover a different set of SANs.
Correct, as long as all of those new certificates cover a different set of SANs than the previously-mentioned renewal certificates and each other.
You are correct. The rate limit mentioned below is the only rate limit that distinguishes a "renewal certificate" from a "new certificate", but only because a renewal certificate is, by definition, a duplicate certificate.
A renewal certificate is a duplicate certificate
that has been acquired to replace a certificate near expiry.
The term "near expiry" is not defined because it seemingly has no tangible impact on hitting a rate limit.
Please keep in mind the ACME endpoint rate limits when performing mass acquisitions in short order.
