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.
This kind of complexity definitely caught me by surprise.