(Apologies for yet another rate limit question, but this one is slightly different.)
My company (1000+ employees) sells devices (think: linux computer-ish home appliance) that provide a local web interface to manage them. We’d like to provide proper HTTPS-support using Let’s Encrypt via our own DDNS provider a la client123.myblablabla.com (e.g. resolves to 192.168.1.2).
We have not started development (or even registered the “myblablabla.com”-type domain) yet, but given that we currently have over 50k devices, we’d like to get clarity on the rate limit exemptions and potentially associated cost.
Is the solution explained above feasible with Let’s Encrypt?
Will the rate limit exemption be granted for something like this?
Sounds like myblablabla.com could be added to the PSL (as an alternative to a Let’s Encrypt rate-limit exclusion). This is the approach used by a number of DDNS providers, device vendors, etc. This doesn’t have any cost and the exact rules and procedures can be found here: https://github.com/publicsuffix/list/wiki/Guidelines
Thanks for the fast response. So if I understand correctly, this would make client1.myblablabla.com and client2.myblablabla.com different Registered Domains (as per Let’s Encrypt lingo), so technically each of these domains could register 20 certs (not that this is needed). Correct?
So the approach would be to add myblablabla.com to the PSL (get PR merged, prove that domain is ours)
and then we could start generating certs for all 50k devices; – without a rate exemption?
Yes, that seems right. I think Let’s Encrypt only periodically merges the PSL into its own code base, so there may be some delay between the PSL merge and it taking effect in Let’s Encrypt.
I’m not sure whether it would take more or less time than getting a Let’s Encrypt rate limit exemption, but it looks like either option could potentially drag on for months, which is something to keep in mind in your planning.
@jsha, you’ve talked to some other manufacturers in threads about this kind of thing before, I believe—do you happen to have a link to any of those prior discussions?
Note: you'll have to use the dns-01 challenge to prove ownership of the FQDN, as Let's Encrypt can't connect to private IP's if the http-01 would have been used.
Using the DNS challenge is not a problem. It’s in fact much, much easier for us since we have a custom DDNS service for our customers anyway.
Are there any benefits one way or the other with regards to the PSL approach over the rate limit exemption approach? Would it be wrong to do both? My gut tells me it’d be better to get a formal okay from Let’s Encrypt themselves over just adding the domain to the suffix list.
Most notably, web browsers restrict cookies between different subdomains of a public suffix to prevent mutually untrusted sites from attacking each other, same as how example-a.com and example-b.com are separate.
For your situation, that could be an important security improvement (users can’t attack each other) or completely impossible (it would break your single sign-on service, or something).