(Let's Encrypt engineer)

> large organisations (I'm sure there are more than 20 sites run under .mit.edu sites by different teams who wouldn't want to share multi-name certificates);

This is why we've added a form to request rate limit overrides. If mit.edu wants a higher rate limit, all they have to do is ask. We're trying to strike a balance between offering a free service that works for most people, and running the risk of abuse.

Also, even if mit.edu doesn't apply for a rate limit, people can issue certificates for 20 new sites under mit.edu per week, or 1,040 new sites per year. And in fact you can see a number of such sites in the crt.sh logs: https://crt.sh/?q=%25.mit.edu&page=1 (note: loads slowly).

Oh, that's great! I didn't realise, from the rate limit page, that the exemption form exists.

If I wanted to issue certs for a few hundred microservices running in a VPC, assuming I could get them to DNS validate, do you think I'd get approved for a rate limit exemption? Or are exemptions more of a well-you-have-to-have-a-really-good-reason thing?

Are they public microservices? You mentioned VPC, so if they're not, you may be interested in running your own CA internally. Anchor [1] was written pretty much for that purpose, but with even faster certificate cycling by default (days, not months). Of course that's for internal services only - anything internet-facing would need a trusted CA.

[1] https://github.com/openstack/anchor

In your case, why not use multi-name certificates? According to the article, Let's Encrypt lets you request up to 100 names per certificate, so you could cover all your microservices with just a few certs.

For your use case, I'd recommend that you either combine them using SAN certificates, as one commenter suggested, or issue them over the span of a few weeks. Processing rate limit requests is one of the few non-automated tasks we do, and we really try to keep the volume to a minimum so we don't get overwhelmed.

The signing capacity of the HSM (or possibly HSMs, I'm not sure) holding the intermediate certificate is limited. These devices are quite expensive, so it's not that easy to scale this resource. In comparison to that, a pending authorization is just a row in some table, so that doesn't take up too many resources.

For use-cases like Plex (or generally things that require a large number of subdomains), there's now a form you can use to request rate limit adjustments[1].

[1]: https://docs.google.com/forms/d/e/1FAIpQLSfg56b_wLmUN7n-WWhb...

HSM signing capacity is not infinite, and HSMs are expensive, but the real issue is just general DOS attacks. We aren't anywhere near our HSM capacity at the moment.

It's easy to set up tons of subdomains and request gobs of certs, which generally eats into the resources we have (database, bandwidth, HSMs). We need to limit that behavior to make sure legitimate users are getting good service.

Are you able to disclose the speed and/or cost? I know people working on cheaper HSM's. They might find the numbers useful as an assessment of how practical their own are.

I don't have any first-hand knowledge, sorry. (Not affiliated with ISRG.)

Based on some public posts, I believe Let's Encrypt is using Gemalto HSMs, though I'm not sure which model or how many of them.

Isn't that an entirely appropriate use case to say "So you'll be wanting to spend a hundred or two dollars on a wildcard cert from a vendor who sells those then"?

Just because my local pub runs a free shuttle bus to the train station, that doesn't mean they are obligated to transport my bulk freight for them.