We are planning to start a service, which will allow people to host their applications on our cloud. In a nutshell, a developer would upload a directory (containing his application) and a domain will be generated for him, for example http://app.124erert34.example.com. These projects will be created on the fly by the developers, i.e. we don’t have a list of sub-domains in advance.
After reading the rate limit documentation and reading different topics in this forum, I got to the conclusion that the best option for us would be to buy a “wildcard” certificate (*.example.com), so all the subdomains will be covered. Please correct me if there is a better option.
Now, here is my question and the problem I’m struggling with:
The service will allow people to assign custom domains to these project, so http://myawesomeprg.com will point to http://app.124erert34.example.com using CNAME. The point is that it looks like in this case we will hit the limit very easily. I understood there are two possible solutions:
I didn’t quite understand the combination of features and options that you’re thinking of.
When using a CNAME, as opposed to HTTP redirect, the name that the user originally typed is the name that will be checked on the certificate. If you have a DNS record
myawesomeprg.com IN CNAME app.124erert34.example.com
Let’s Encrypt can issue lots of certificates covering the custom domains without any need for a rate limit exemption. To issue lots of certificates under example.com, you may need a rate limit exemption. However, if you have a wildcard certificate from another CA for *.example.com, you might already be covered without needing the rate limit exemption. Were you thinking that you would have both? How were you envisioning that the redirection or aliasing would work?
Do note that a wildcard in such a certificate will only be valid for the label on which level the wildcard is specified. I.e., *.example.com will work for foo.example.com, but not for foo.bar.example.com. Compare this with the wildcard certificate *.bar.example.com, which will work for foo.bar.example.com and other subdomains of bar.example.com.
This is what I didn't get from the documentation - what are the limits for issuing certificates for custom domains? What exactly "lots of" means? I was afraid that not only the certificates might be a lot (hundreds or thousands), but even a typo in the domain name, as written by the developer would "help" to reach the limit.
P.S.
I don't really want to use the "wildcard" certificates and it is not question of money - they aren't that expensive. I like the idea of Letsencrypt; we will have a free plan, of course and I would prefer to issue certificates under example.com using Letsencrypt too. However, I got confused/lost with the limits under example.com and that's why I thought about the "wildcard" certificates.
Ah, thanks a lot, @Osiris, you are completely right! Hm, this means we will have to change the way we generate project’s links and make them look like http://app-124erert34.example.com to be covered by the *.example.com.
If the custom domains are really separate and independent domain names (example1.com vs. example2.com vs. example3.net vs. example4.de), there is no limit to the number of certs you can get from Let’s Encrypt for them.
For the app-1234erert34.example.com case (@Osiris is right to caution you on the scope of the wildcard), you can get one wildcard cert from a single CA that offers them. As I think you discussed, Let’s Encrypt does not offer these, but you can of course mix Let’s Encrypt and non-Let’s Encrypt certs on the same server infrastructure at the same time.
Hopefully your web server can then be configured to always retrieve and serve the appropriate cert in response to whatever site the user’s browser is requesting via SNI. (That is normal behavior in servers like nginx and is probably only an issue if you encounter scaling problems or are developing a customer web server.)
Thanks, the mix between Let’s Encrypt and non-Let’s Encrypt certificates looked like the best option for me from the beginning too.
If we go in this direction and following @Osiris’s hint about the scope of the wildcard, here is what may happen:
We would need some time to change the way we generate links (app-1234erert34.example.com vs app.1234erert34.example.com), so we won’t be able to use the option with *.example.com immediately and we may have to use Let’s Encrypt only, at least in the beginning.
Filling in the rate limit exemption form is the best option.
For the second problem, if you carefully generate the subdomains on the users’ behalf and you’re careful about how you do it, you might be able to prevent the customers from running into problems. In any case, I think there is no rate limit exemption available for “any domain of any customer of hosting company X”; the rate limit exemptions apply to the existing rate limits. So if you get an exemption, it will help with the first problem and not really with the second problem.
If the customers independently try to go out and use Let’s Encrypt on their own without your involvement, hopefully they will appreciate that there are limitations that are imposed by the CA and that in any case these limitations are not your fault.