I’m trying to find a way to dynamically provision SSL certificates for my SaaS platform and I want to use Let’s Encrypt. However the rate limits imposed by Let’s Encrypt are far too restrictive for our use case. Has anyone faces problems with the rate limits before and how did you solve it? I’m happy to pay money for a solution, there just doesn’t seem like there’s many out there.
I’m exploring ZeroSSL.com, but I’ve seen some not so stellar reviews on them which makes me hesitant. But they also seem to be the only solution out there for this. Would love to know what others have done for this.
Looking through the rate limit docs, it seems like we would hit the limits on new certificate requests. In most other platforms Wildcard certs would be used to solve this problem, however we can’t use wildcards because each customer managers their own private key.
Certificates per Registered Domain (50 per week).
We provision a subdomain for each customer and some certificates are ephemeral. So we could be issuing a couple hundred certificates a day or more.
300 New Orders per account per 3 hours.
It’s possible we could hit this one as well, given what I mentioned above.
I thought we would hit the Account limit too, but re-reading the docs I see it’s possible (and recommended) to use a single account for all certs for large hosting providers. So that one should be ok.
You could think of my platform as private VPS hosting in which an application runs that encrypts everything to a user’s password. Our platform is noncustodial by design and therefore a TLS private key can’t be accessed by us. Because of that, I can’t use wildcards.
Provisioning a certificate for each customer is the only solution
I’ve had absolutely no problem with the rate limits and I work on SAAS/PAAS. What are your rate-limit concerns? The only one I can imagine would be subdomains, but that can be addressed with wildcard certs or purchasing additional domains.
Please read above. I can’t use wildcards and have to provision multiple certs per subdomain for each customer. So I would hit to 50 certs a week limit because I could need upwards of several hundred certs a day.
Considering that each subdomain counts as a separate domain for certification purposes, I am wondering why you would possibly need in excess of 50 certificates per week per customer.
Theoretically each customer would have their own Let's Encrypt account credentials that you could manage (or have them manage via scripting/config you prepare), so you should never hit this limit.
The limit is on the TLD not the subdomain according to the docs:
A registered domain is, generally speaking, the part of the domain you purchased from your domain name registrar. For instance, in the name www.example.com , the registered domain is example.com . In new.blog.example.co.uk , the registered domain is example.co.uk . We use the Public Suffix List to calculate the registered domain. Exceeding the Certificates Per Registered Domain limit is reported with the error message too many certificates already issued , possibly with additional details.
If it was on the subdomain I would likely be in the clear, but since it's on the TLD that means I could only have a few customers a week sign up. Which is not going to work, haha.
If I created an account per customer I'm limited to 10 accounts per IP address in 3 hours. Given infrastructure is all private with NATing, outbound internet traffic is only on a few IPs, so I could then hit this limit. Albeit, this limit is probably do-able.
At the end of the day, I don't want to have to write a bunch of code and business logic to deal with these limits and backoffs, etc. That's why zerossl.com was appealing is because they don't have limits.
You can create a maximum of 10 Accounts per IP Address per 3 hours. You can create a maximum of 500 Accounts per IP Range within an IPv6 /48 per 3 hours.
I could see where these limits could pose a problem. It might be possible to stagger it, but that would create some complexity in management.
You could have customers issue their certificates externally, meaning generate the certificate private keys and certificate signing requests on your server space then use the CSR with only public information to get the certificate outside your ip range. Granted it's not the friendliest process to fully automate, but it is scalable up to basically infinity as far as the account limitation.
Alternatively, I run a web-based ACME Let's Encrypt client (which is highly taboo here to many), but that type of solution would certainly fit your model if you provided something similar. You can use a central set of rotating accounts to overcome the 300 pending account limit. Since they're your customers on your space, you probably wouldn't receive the grief that I do for using my account for certifying domains I don't control.
I guess I see it as:
First, decentralize the domains by having each customer with a separate domain alias to your system. This provides them with some control and a sense of individuality while still being part of your world.
Then, either:
Hand customers a process to certify themselves.
Provide them with a centralized tool to do the certification through you. The benefit of this solution is keeping it in-house and possibly automating the process if you have access to their certificate installation paths.
Can your customers CNAME/A a subdomain onto your platform, instead of using your subdomain?
In terms of NewOrders… given the isolation levels you have, you should probably assign a new account/account-key to each customer, which would eliminate that concern.
Some people have purchased multiple domains in the past, pre-provision the subdomains and certificates, and then allocate those to customers instead of on-demand.
In any event…
There is a rate-limit exception form, and you may qualify for it. Personally I would pursue this option, because it sounds like you need both an Account and Domain exception
There is also the public-suffix list, which may also be worth looking into.
You read my mind. I was wondering why each customer can't just have their own domain name (at minimal cost) then just alias to his system, much like WordPress allows.
Yeah, that's technically possible and customers could do it, but I don't really want to require them to. I'd like to support HTTPS on the subdomain that I provider and if they want to go do their own they certainly can.
In terms of NewOrders… given the isolation levels you have, you should probably assign a new account/account-key to each customer, which would eliminate that concern.
Yeah I think you're right about that. I need to keep the accounts separate since the keys needs to be too.
Pre-provisioning sounds interesting, but would require a decent architecture overhaul. I'll consider that more, but I'd love to get my existing infrastructure working.
Do you have a link or a doc about the exception form? I'd love to read up on that as well. Thank you!
There has always been a weekly limit for NEW certificates on the REGISTERED domain. Renewals do not count against this.
Before wildcards support, one of the common workarounds was been to pre-allocate 50 certificates a week, each with 100 subdomains. That would give a platform without rate-limiting exceptions or a public-suffix 5000 new domains each week.
A link to the exception form is hidden on the rate-limits doc:
Assuming you are doing something like {CUSTOMER}.{PRODUCT}.{DOMAIN}, you can issue a PR to the public-suffix list for {PRODUCT}.{DOMAIN} -- then follow up with LetsEncrypt to see when Boulder (their ACME server) updates their copy of the PSL
