Best option for issuing certificates for custom domains


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 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 (*, 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 will point to 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:

  1. To add our domain to the Public Suffix List.
  2. To fill this form, which would allow us to go beyond the limit. This option should be faster then Option 1.

Have I understood everything correct? Are these really the best options?


Hi @joahim,

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 IN CNAME

then you need a certificate that covers in order to support If instead you have an HTTP 301 redirect from to, you’ll need a certificate that covers

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, you may need a rate limit exemption. However, if you have a wildcard certificate from another CA for *, 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?

1 Like

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., * will work for, but not for Compare this with the wildcard certificate *, which will work for and other subdomains of

1 Like

Hi @schoen,

Sorry for the confusion, I will try to clarify now.

My understanding was that we would have to generate certificates for "" to cover the scenario when user types "" in the browser and if the user types "" we would be covered by the "wildcard" certificate.
About the redirect from to, I also imagined that we would be covered by the "wildcard" certificate. Please correct me if I misunderstood something.

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.

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 using Letsencrypt too. However, I got confused/lost with the limits under 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 to be covered by the *

Hi @joahim,

If the custom domains are really separate and independent domain names ( vs. vs. vs., there is no limit to the number of certs you can get from Let’s Encrypt for them.

For the 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.)

1 Like

Hi @schoen,

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:

  1. We would need some time to change the way we generate links ( vs, so we won’t be able to use the option with * immediately and we may have to use Let’s Encrypt only, at least in the beginning.
  2. The customers may try to generate certificates for sub-domains of their custom domains (,, etc.).

In both cases we may hit the limit. If we do, what would be the option for us? To fill this form, to add us to the Public Suffix List or both?


Hi @joahim,

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.

Thank you very much for the help, @schoen!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.