[pfg]

That's correct, however there are rather aggressive rate limits in place right now that would make this hard for your typical SaaS-on-a-subdomain deployment if you have more than ~5 new signups per week. Plus, if SAN support is a concern, wildcards are preferable too.

[jrochkind1]

The rate limits[1] I see documented are 500 registrations per 3 hours. That's a lot more than ~5 new signups per week. More like ~16800 new signups per week, no?

[1] https://community.letsencrypt.org/t/rate-limits-for-lets-enc...

[pfg]

Certificates/Domain is the one that would affect this use-case the most. It's set to 5 certificates per domain per week. More specifically, it's certificates per TLD+1, so one certificate for customer1.example.com and one for customer2.example.com would put your rate limit for example.com at 2, thus limiting you to 5 signups per week unless you spread your SaaS over multiple TLD+1's.

[zaroth]

Wildcards are important and LE should support them, but it will take perhaps some more work on the validation rules. Dynamic subdomains are powerful stuff, and even a real-time automated cert request is a poor substitute for just having the wildcard. If you're doing sub-domain per customer, the wildcard cert is definitely preferred particularly if you're proper multi-tenant all the way down the stack.

[jrochkind1]

Ah, I didn't catch that this limit was applied to the TLD+1.

Weird, why allow a generous 500 registrations per 3 hours, while limiting certs per domain like this? Anyone have a link to anywhere that letsencrypt explains what they are trying to do here?

[pfg]

Registrations don't cause a lot of load. They're essentially just one row in a table.

Certificates have to be signed by a Hardware Security Module with limited capacity. OCSP messages have to be signed every couple of days for the lifetime of a cert by the same HSM. This is significantly harder (and more expensive) to scale.

[derefr]

How do they define a TLD? What's, for example, .co.uk to them?

[pfg]

They use the Public Suffix List[1].

[1]: https://publicsuffix.org/

[jrochkind1]

Hmm, are you sure they do? Including the "PRIVATE" section? Any docs from them saying this, and clarifying whether this includes the PRIVATE section?

Because if so, that would seem to make the certs-per-domain limits not so much of a problem. If you own example.com, and have customers using sub-domains at a.example.com, b.example.com, etc -- that would seem to make example.com suitable for inclusion on the "PRIVATE" section of the list.

No?

"owners of privately-registered domains who themselves issue subdomains to mutually-untrusting parties may wish to be added to the PRIVATE section of the list... Requests for changes to the PRIVATE section must come from the domain owner."

https://publicsuffix.org/submit/

And indeed there are a few dozen random .com, .net, etc domains in the PRIVATE section. For instance `github.io` is listed there.

If that's the way for SaaS providers to get free certs from letsencrypt for their customers at customername.provider.com, I'd expect to see the listings in the PRIVATE section skyrocket.

[pfg]

Yes, private suffixes are included. It has already caused a spike in new PSL submissions[1].

You're right about this being rather easy to bypass, but the main goal is probably not to mitigate against abuse but rather prevent buggy automation scripts stuck in some kind of infinite loop from DDoSing them.

[1]: https://community.letsencrypt.org/t/dyndns-no-ip-managed-dns...

[tokenizerrr]

A TLD. They define domain as anything the average user can purchase.

[asddubs]

Oh that's a bummer, I was just looking into using this for a free service I made a while ago. Hopefully they'll bake in support at some point

[finnn]

Note that that's the current limits, but they have stated that they plan to raise them greatly in the future

[x0]

5 certs per domain name per week. I'm currently rate limited, I should be able to get my www covered in 6 days.