Hi, guys. I have a question about Let’s Encrypt Rate Limits.
Current, I have a Landing Page builder where my clients can build Landing Pages and publish it with your domain, in a subdomain (e.g contents.example.com/lp-a). Current, I have ~9.000 individual clients and receiving ~600 new clients per month. So, I have to issue 9.000 certificates at once and 600 per month and growing!
As I read at Rate Limits documentation, I saw that I only can get 20 Certificates per week. So, Let’s Encrypt is not the best solution for me, right? Have I misunderstood something wrong or have a workaround to solve this?
Note that each certificate that you issue from Let’s Encrypt is allowed to cover 100 different names, so the rate limit that you referred to will still permit you to add certificate coverage for 2000 new names per week, without an exemption, as long as you’re willing to have different clients share the same certificate. (There is also an existing rule where, if you perform new issuances before certificate renewals, the renewals will still be permitted regardless of the rate limit. This is to ensure that you can always renew your old certificates and that getting new certificates doesn’t prevent that.)
Yes, in that case there should be no problem with the rate limits.
You can also choose to combine them this way, but it isn’t required. You can combine up to 100 names into one certificate.
One thing that other hosting providers have found challenging in your situation is that a customer can choose to stop pointing its domain at your service, for example
because the customer stopped using your service without telling you
because the customer’s nameservers broke
because the customer’s domain expired
because the customer sold the domain name to somebody else
In that case, you can no longer renew the certificate because you can no longer complete the proof of domain control process. But you wouldn’t have any reason to anticipate this!
For some hosting providers, this is an argument in favor of not combining the names into a single large certificate, because if you try to renew using the built-in renew feature in a tool like Certbot, you have a high probability that the renewal fails for a reason that’s outside of your control. (Certbot in particular does have an option called --allow-subset-of-names, which will continue with the renewal process even if some names failed to renew, but this is kind of dangerous because it has no way to distinguish between temporary and permanent failures, and no way to try to re-add failed names in the future.) The most annoying thing about this is that it’s a way that one customer can affect the reliability of the service that you provide to other customers!
In any case, you probably want to build some kind of monitoring tool to check frequently whether names appear to still be correctly pointed at your service, so that you won’t try to renew names that are likely to fail, or so that you can contact those customers to ask them to solve the problem, or temporarily deactivate their service, or whatever course of action you prefer.
@cpu Hm. Can you help me if Let’s Encrypt will fit in my scenario?
I have clients leaving our solution too, around 40 clients per month. So, I have current around 10.000 clients, around 900 new clients per month and around 40 clients leaving per month. Supposing that I have a lot of certificates with 100 subdomains each, and I have to update/renew/new certificates, rate limit will be a problem?
I’m questioning this because if I have a client that stop to pointing their subdomain to our server we have to update a certificate removing this subdomain and when I want to enable HTTP’s to a new client I have to update a certificate too. As it’s count as a new certificate issued I would hit the rate limit quickly.
I agree that this kind of churn could conceivably get you close to a rate limit quickly, although it’s not guaranteed to happen and doesn’t necessarily seem likely to happen.
This sounds like a good argument in principle for issuing each customer’s certificate separately. Then, no customer can cause you to hit a rate limit on behalf of a different customer. If you combine separate customers’ certificates in a single certificate, it is theoretically possible that customers quitting can force a pattern of reissuances that leads to hitting a rate limit.
You could also try simulating it with software or based on actual data about what would have happened in the historical operation of your service.