Let’s Encrypt Numbers to Know

Let's
Encrypt is now the largest certificate provider for internet facing servers
(combining a Frost&Sullivan report on SSL/TLS certificates from 2016 and actual data from
Let's Encrypt, LE currently issues around 80% of all browser-trusted certificates). It does not
issue the "most secure" certificates (i.e., EV, or extended validation certificates, which
require manual validation of the address and legal status of the web service owner), but its
certificates provide a very good level of security for most of us.

When we started using
Let's Encrypt (LE), we slowly learnt about various limitations imposed on users. There is not
any single place where you can find all important information in one place so here's the first
attempt. We will amend it as we learn more directly, or from your feedback.

Update 30 June: a big thank you to schoen for his feedback, which has been now included in the text.

Business restrictions

Restrictions on certificate use

Use of certificates is limited by their profile. LE offers just one certificate
profile and there is no flexibility in this. The main goal is to automate certificate issuance
and this is an acceptable restriction. Certificates limit the use for digital signatures and
"key encipherment". From our point of view, they can be used only for:1. server
authentication; and2. client authentication.

The good news is, you can use it for any
of your internet servers - web, email, SSH, web apps, and so on.

Time validity

This is a property people talk about a lot. Certificates are valid for 90 days exactly. Exact
means that if you get your certificate at 8:31am, it will expire 90 days later at 7:31am
(certificates are backdated by 1 hour, so that servers/computers with a slightly out-of-sync
clock can validate them immediately).

LE says the main reason is to encourage automation
on our side. I'm not sure it quite works yet, but we are trying to chip in with some services
here.

Multi-domain aka SAN Certificates

You can request a certificate, which will contain up to 100 domain names. The domain names map
directly into names of servers, as sub-domain wildcards are not allowed.

The limit here is 100 domain names per certificate. Technically, it is implemented as one main
“subject" distinguished name and 100 alternative names, which include the one in the subject DN.

Note: The subject distinguished name (DN) only contains a common name (CN), which is
your domain name, e.g. "www.keychest.net".

Wildcard certificates

Wildcard certificates are available from March 2018. They can only be requested with DNS validation as it is the only
validation strong enough to show that you can control the whole domain.

Supported algorithms

Operations restrictions and requirements

Max certificate requests

If you start building a bigger network infrastructure and assign servers a public name within
your company domain (e.g., keychest.net), you should be aware that you can't get more than 50
certificates per week per registered domain.

If you think about a cloud service with
subdomains per customer, this may be a serious problem. LE offers an opportunity to request an
increase of this limit but they don't guarantee positive response or any response at all.
Here's the address of the Rate Limiting form, you want to try it.

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.

Note 1: Staging/test environment has the limit of 30,000 certificates per domain per
week.Note 2: We are not sure if there is a limitation on how long the existing certificate can
be expired for a relevant request being counted as a renewal.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.

Preference of IPv6 (and failures of misconfigured clients)

At the end of May 2017, Let's Encrypt changed the handling of
IPv4 and IPv6 - IPv6 became the preferred protocol. This change has been causing sudden
malfunctions of clients as
domain validation started failing if there was a problem with IPv6 configuration.

Previously, Let's Encrypt preferred IPv4, which is still the protocol you are likely
to configure and test your web browser with first. You may need to update network configuration
on
your servers so that IPv6 requests reach your server and the web server recognizes
IPv6 addresses as belonging to existing (virtual) hosts.

Some users of Let's Encrypt, however, were caught by surprise, as IPv6 issues were
not due to their servers' configuration, but errors in network traffic routing
provided by their internet provider.

Max registrations per end-point (IPv4, IPv6)

Let's Encrypt limits the number of registrations (i.e., creation of account keys) per end point.
The values are:

IPv4 - exact IP address - 10 registrations per 3 hours; and

IPv6 - /48 range and is 500 per 3 hours.

Note 1: these limits are the same for production as well as staging environment.

Note 2: re-use of an account key - the key created during registration is not allowed. Each
account needs its own key.

Staging environment

Do use "--dry-run" or an available alternative when you test your integration. Certificate
issuance works exactly the same except for the certificate being only for testing, i.e., not
trusted.

If you don't do that, you will run out of your weekly quota of certificates very
quickly. It's not the end of all day, you just have to wait a week to request a new production
LE certificate. Meantime, you can still test with the LE staging environment.

When testing, use "--dry-run" or an equivalent to avoid quota-based restrictions.

Floating window for limits

LE enforces several "velocity" limits, i.e., how many requests you can submit to its
certification authority. These are currently based on a floating window of 7 days, i.e., 168
hours. Your "allowance" is recomputed at the time of each new certification request using logs
of the last 168 hours.

Does revocation of a certificate reset limit counters?

No.

Maximum number of renewals

There is a limit on the maximum number of certificate renewals. This is currently 5 per week per
certificate. A request for a certificate is counted as a renewal, if it contains exactly the
same set of domain names. Mind the following two friendly rules:

domain names are case insensitive (KeyChest.net and keychest.net are equal); and

domains can be in any order.

Note: the staging/test environment has a limit of 50,000 renewals per account per week. (The
number is correct, it is not clear, whether it is per account.)

Adding a domain name to an existing certificate

If you change the set of domain names - add at least one, or remove at least one, the subsequent
request is counted as a new certificate. It will count towards the "Max certificate requests"
limit above.

Combination of renewals and new certificate requests

As there are two separate rules limiting the number of requests, be aware that if
you reach any of them, the request will be rejected.

Example 1

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, aka "duplicate certificate" limit).

You know these were the only requests in the last 7 days (the limiting time window).

If you now decide to add this domain name to another certificate you already have on your server
(e.g., containing "mx.keychest.net", and "ssh.keychest.net"). A request for a new certificate
with all three domains will be accepted, as it is not a renewal but a new certificate
request.

Example 2

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).

You have also requested 45 other certificates, which in effect used up all your certificate
allowance for the 7 days' time window, as renewals do count into that limit.

The same request as in Example 1 will now be rejected. The reason being you reached the weekly
limit for new certificates.

Example 3

You have used up all your certificate allowance for the 7 days' time window. Also, you have only
done 4 renewals of the "www.keychest.net" certificate, so you're allowed to do 1 more
renewal.

The same request as in Example 2 will be rejected. The reason is you reached the weekly limit
for new certificates and as the list of domains is different, it is a request for a new
certificate.

Example 4

You haven't done any certification requests in the last 7 days and you need to do 10 renewals
and get 45 new certificates.

You start with 10 renewals of your existing certificates.

If you now request 45 new certificates, you can only get 40 of them. The remaining 5 will have
to wait for seven days.

Example 5

You haven't done any certification requests in the last 7 days and you need to do 10 renewals
and get 45 new certificates (as above).

You start with new certificates and get all of them.

You can now proceed with all 10 renewals, as they count towards the certificate limit, but not
restricted by it.

Example 6

You have a lot of certificates and have been randomly adding them as needed so you have to do 50
renewals over any 7 day window.

If you need even more certificates, you will eventually have to plan in weekly schedules. First,
you will request new certificates you know you need in the next 7 days. Then you renew all that
is needed as quickly as possible afterwards. You can then request new certificates 7 days later.

Limit on failed authorization

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.

Please note there is also a limit on pending validations - see below in "Velocity limits 2".

Note: The staging/test environment has a limit of 60 failed validations per hour per
account.

Completing certification request

LE certificate issuance consists of 3 steps and they have to be completed within 7 days,
although clients usually do them all within a few seconds when fully automated.

LE servers will create a unique random value (a secret or token),
which you receive securely. You have to use it to prove that you control the domain name, for
which you requested the certificate. Once you’ve done that, you can proceed with step 3
above.

All three steps can be done in one go and completed within seconds. However,
step 2 may require manual steps, e.g., to change domain name service (DNS) records. That’s
why LE implemented two different time limits:

7 days - to complete step 2; and

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

Implementation limits

Velocity limits 1

There is a limit of 20 per seconds for your servers (endpoints) related to new certificates or
revocation of certificates. If you use OCSP to verify certificates, there is a limit of 2,000/s
per server.

Velocity limits 2

When you start using LE clients, they will create an LE account for your endpoint. This client
account is used to authorize your requests. Usually, you will have one account per server, but
you can share the account across your servers.

If you provide hosting, you may want to
create an account per each user, and all that on a dedicated server (a server with one IP
address).
There is a limit of 500 new accounts per IP address. Let's
Encrypt Integration Guide also recommends using a single account for all customers.

If you make a mistake somewhere, typically when changing clients, and you don't complete
certificate issuance, it is possible that LE servers will keep "pending authorizations". There
is a limit of 300 pending authorizations per account. If you need to clear them quicker, please
follow instructions here if you get into this situation.

Velocity limits 3

Validity of authorizations

Here it gets very technical, but also interesting. There is a separate validity time limit for
authorizations, which is currently 30 days (as of 30 June 2017). What it means is that if you
request a certificate renewal, your client will not have to request new authorization for 30
days. It means that you need to:

spin a temporary web server - you have to stop any other web server, which is using port
443 (check your LE client and the web server if this can be done without stopping the
web server; e.g., certbot with "--apache" or "--nginx" may work) or

allow creation of temporary verification files in your web root folder - you need to
have access to write into the directory with your web data; or

update DNS records - again, you need to amend your DNS records.

Only once every 30 days. This authorization is per account and per domain name. If you have
"ssh.keychest.net" and "mx.keychest.net" pointing to the same server, but each name has its
own certificate, you will need 2 authorizations.

For an authorization to live for 30
days, you have to successfully verify it within 7 days. Otherwise, it may stay in the "pending"
state and will be removed after 7 days. This limit is particular important if you use DNS
verification, as this is a limit in which you need to amend your DNS records.

Monitoring

Email reminders

Letsencrypt will send you reminders to renew your certificates. These are sent:

20 days before the date of expiry;

10 days before the date of expiry; and

1 day before the expiry.

Note: when you successfully request a certificate with a changed list of domain names, you
will keep receiving reminders as you got a new certificate, instead of a renewal of as the
original one.

The actual time varies and can be a day or even two days later.

These email reminders are
sent to the email address you enter when you create your account key - this is usually the first
certification request on a given server. The email is stored with your letsencrypt account
configuration. You can also set an arbitrary email address with each request, if your Let's
Encrypt client supports it.

Bear in mind that if you unsubscribe from these
notifications, you can't re-subscribe. It may also happen that these emails end up in your spam
/ junk mail box.

Planning

KeyChest is our attempt to give you an enterprise certificate management system for your Let’s
Encrypt certifcates. It is a free service for absolute majority of you, including weekly email
summaries.

If you want to manage other types of certificates you issue internally, or
your internal networks as such, you will need either internal agent, or an instance of KeyChest
installed on one of your own servers. This configuration requires a license.