Let's Encrypt in numbers - limits, restrictions, features

Hi all,

We struggled to find a single place with all the information we needed to know about Let’s Encrypt. At the end we decided to write down all the restrictions, limits and also short texts about what Let’s Encrypt can and can’t provide.

Let’s Encrypt - numbers to know
or follow the “Stories” link from https://keychest.net.

Topics include: supported algorithms, number of requests, multi-domain/SAN certificates, window for limits enforcement, renewals v new certificates, failed authorizations, velocity limits, email remainder, …

Here’s a few selected points:

  • Do you know that Let’s Encrypt now issues 80% of all publicly trusted certificates globally?
  • Do you know that your Let’s encrypt certificate is in fact valid only 89 days and 23 hours?
  • Do you know that you are only allowed to request only 2,000 OCSP requests per second from each of your servers?
  • Do you know that in one week you can request 20 new certificates followed by 1,000 renewals, but if you do it the other way round the requests for new certificates will be rejected?
  • Do you know that if you regularly request a certificate every 8 hours and 25 minutes, some of your requests will start being rejected in less than 90 days (after your first renewal)?
  • Do you know that you can create only 10 new accounts in 3 hours from one IPv4 address, but you are allowed 500 registrations from IPv6/48 range?

If you find anything missing, please comment here and we will amend.

Update 30 June, 11:24am CET - a lot of changes suggested by @schoen included now.

Update 30 June, 17:28pm CET - comments from @cpu included now (inc. authorizations valid for 30 days only)

Update 7 July, 21:00p CET - added a section about IPv6 preference


Hi @DanCvrcek,

Here are my questions and concerns about this:

Let’s Encrypt is now the largest certificate provider for publicly facing internet servers.

I’m not sure if we’ve been able to substantiate this yet, although I think it’s plausible.

It does not issue the most secure certificates (i.e., EV, or extended validation certificates), but its certificates provide a very good level of security for most of us.

From a site operator’s point of view, there isn’t necessarily anything more secure about an EV certificate. There might be from a user’s point of view (because it indicates that additional information about the site operator’s identity was verified), but in particular it doesn’t make the connection more confidential or private.

Exact means that if you get your certificate at 8:31am, it will expire 90 days later at 8:31am.

I think it will actually expire at 7:31 because certificates are back-dated by 1 hour to avoid validation failures with slightly inaccurate clients’ clocks.

I’m not sure [automation] quite works yet

Well, it depends on what kind of client you’re using.

These are basically server names, unless you are happy to

I didn’t understand the “unless” here. Does this mean that they can be something other than server names if the subscriber is happy to do these things, or that more than 100 names can be used if the subscriber is happy to do these things, or something else?

Technically, it is implemented as one main “subject" name and 99 alternative names.

This is not correct. All of the names are expected by standards to be listed as subject alternative names. A Let’s Encrypt certificate that covers 100 domain names will include 100 SANs. It does also include the subject CN field, but that might change in the future.

The name listed in the subject CN field is also listed as a SAN.

Wildcard and DV (domain validation) certificates are not available. This relates to similar restrictions on EV (extended validation) certificates.

All Let’s Encrypt certificates are DV certificates. It’s not correct that DV certificates are not available from Let’s Encrypt.

I don’t think that the reasons that Let’s Encrypt doesn’t issue wildcard certificates are closely parallel to the reasons that we don’t issue EV certificates, and I think this comparison could be confusing.

RSA keys, with lengths from 2048b to 4096b;

It might be clearer to spell out “bits”. I believe that the only allowed sizes are 2048, 3072, or 4096 bits, and not other sizes in between.

Renewals, i.e., repeated certification requests, which contain exactly the same set of domains are not counted into this limit, even if the existing certificate already expired.

A lot of people have been confused about this. They are currently counted against that limit, but they are not restricted by it. They can prevent other non-renewal certificates from being issued, but not vice versa.

Note: We are not sure if there is a limitation on how long the existing certificate has been expired.

I didn’t understand this. The rate limits do not consider expiry time or expiry status at all.

(I don’t know if there are any limits in the staging environment, but we haven’t hit any yet.)

There are some, but they are fewer and higher.

Does revocation of a certificate reset limit counters?

While you’re talking about revocation, it might be good to add that revocation is not required or expected merely because you take a service offline or merely because you replace the old certificate with a new or updated one. Revocation is intended to be used when you have reason to believe that a private key was compromised or when you are aware that a certificate is no longer accurate (for example, because you no longer control a domain name that’s covered by it).

There is a limit on the maximum number of certificate renewals. This is currently 5 per week.

That’s 5 per week per certificate, not 5 per week per user or 5 per week per site. If you have one certificate for www.example.com and another certificate for www2.example.com, you can renew each of them 5 times per week.

Let’s say that you have been doing some testing and requested 5 certificates for “www.keychest.net” in one day (you reached the domain renewal limit) and you know these were the only request in the last 7 days. A few hours later you realize that it would be much better to add this domain name to another certificate you already have on your server (e.g., containing “mx.keychest.net”, and “ssh.keychet.net”). If you now request a new certificate with all three domains (in my example here), the request will be rejected. The reason is the limit per domain renewals for “www.keychest.net”.

Nope! As I explained above, this is a misinterpretation of the renewal rate limit, as I explained above. This issuance would be permitted.

If your automation doesn’t work, or you fail to validate domain ownership (e.g., adding files in your web root folder, or amending your DNS records), there is a limit of 5 failed validations per domain per hour.

There is a subtlety about failed authorization vs. pending authz (an additional limit that you didn’t mention). You have failed to validate domain ownership if your client claimed to have satisfied a challenge but the CA fails to confirm the client’s claim. If your client simply hasn’t done anything and has not claimed to have satisfied the challenge, then you may have a pending authz.

LE servers will create a unique secret, which you receive securely. You have to use it to prove that you control the domain name, for which you requested the certificate.

Not everyone would agree with describing this value as a “secret”; in most threat models, it doesn’t actually have to be kept confidential for security reasons.

Once you’ve done that, you can proceed with step 3 above.

It might be good to emphasize that these steps are normally done by, and intended to be done by, software. Describing these three steps as meant to be done by the individual subscriber might be confusing for the majority of people who use a Let’s Encrypt client application to do all of them, usually in a matter of seconds.

It’s true that the second step can be completed manually by some subscribers and that that could potentially take a long time.

60 days (currently) - to use a valid authorization to get a new certificate.

I believe this period has already been shortened.

If you provide hosting, you may need to create an account per each user, and all that on a dedicated server (a server with one IP address).

“May need to” is a matter of hosting provider practice, not a Let’s Encrypt requirement. Let’s Encrypt permits hosting providers to use a single account for multiple hosting provider customers and also permits an account to be used from multiple IP addresses.

There is a separate validity time limit for authorizations, which is currently 60 days.

Again, I think that was already reduced.

spin a temporary web server - you have to stop any other web server, which is using port 443; or

Only methods like certbot --standalone do that; by contrast, certbot --apache and certbot --nginx can use an existing web server to pass the TLS-SNI-01 challenge, without shutting down the existing server.

Letsencrypt will send you reminders to renew your certificates.

I think it would be worth mentioning that a certificate is not considered renewed for reminder purposes if a replacement certificate does not cover exactly the same names. If you had a certificate for example.com, and then you later got a certificate for www.example.com and example.com, you will still receive an expiration reminder for the first certificate when it’s near expiry, because the second certificate is considered separate.


After you’ve responded to those things, we could also ask Jacob to look at it (attracting his attention by writing an @ followed by jsha). Jacob has personally implemented and managed a lot of the rate limit stuff in Boulder, so he should be able to fix any remaining inaccuracies or ambiguities about rate limit issues.

excellent! I will update it with your comments later today. Cheers

PS: when I combined a Frost&Sullivan market survey from 2016 with LE’s real data, you seem to control 90% of the market with publicly trusted certificates.

Frost&Sullivan market survey 2016 & your real data suggest 80% market share in public SSL certs.

ok - people can argue here:) I’ve amended to make it more accurate.


hmm, probably better to move that into a best-practices text. (done)

yeap, corrected - I don’t think there’s any way to request a particular name to be in the subject DN. Would it be always the first one on the command line?

silly error.



I will add this to a best-practices text.

that’s kind of obvious, but amended.

I’ve added 6 examples - please have a look, keen to hear if I got it right now.

it’s further down in “velocity limits 1” - added a reference.

… will update if I can find the current value.

Hi @jsha, I’ve tried to put all possible rate and number limits of LE into one piece of text. I wonder, if you can have a look whether it’s correct https://keychest.net/content/letsencrypt_numbers_to_know

The Staging environments rate limits as compared to prod are documented here.

It’s correct that this is a matter of provider practice but its also worth pointing out that in our integrator guide we explicitly recommend using a single account for all customers.

Are these the only differences between staging and prod?

In terms of rate limits, yup!

cool - the big picture starts emerging now.

are authorizations still valid 60 days, or less?

They are valid for 30 days at the time of this post.

One other item to note:

Note 3: It gets a bit complicated when you request new certificates as well as renew existing one - not sure if this is definitive but here we go. Renewals (see below) count to the weekly limit, but they are not limited by it. Basically, you can always renew your existing certificates.
A side-effect of that is, however, you will have to be careful and plan well when you get to a threshold of about 240 certificates, as renewals may easily eat out the whole quota for each week. See examples below.

This is due to be fixed shortly, the code has been merged to master but hasn’t been deployed to production or enabled in configuration yet.

There will likely be an API announcement about the change when its enabled. After that point things should be considerably easier in terms of renewals. I think that will resolve the need for the “Combination of renewals and new certificate requests” section.

The sooner the better :slight_smile: This kind of complexity definitely caught me by surprise.

3 posts were split to a new topic: Does Let’s Encrypt require IPv6 and forbid IPv4?

I’m not part of Let’s Encrypt, only a user, and an engineer. Let’s Encrypt states that the reason behind limits is to ensure fair use. It’s all about managing the infrastructure and control the load. As far as I can see, LE is gradually relaxing the limits as they become more confident they can handle the traffic and work load.

I’m not quite sure I understand the rest of your question but I would think the rate limits impact large users, rather than small ones.

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