Mass-creating certificates for different domains


Our company runs an online shop platform where some shop owners use their own domains. Since we take care of the servers, we would like to mass-create certificates for around 6,000 different domains on our behalf.

I’ve consulted the docs about the rate limits (, but could not understand what the limits are in a particular situation where an entity requests such a large number of certs at once.

So, the questions are:

  1. Is it OK for a single entity to request certificates for thousands of domains owned by its customers? (In our case, we don’t profit from this feature)
  2. How long does it take to complete the cert issuance for 6k unique domains?
  3. (Related to 2.) What is the most efficient way for an entity to create thousands of certificates?

Similar topic: Does let’s encrypt has limitation on the number of certificates that can be issued for one server?
The difference from the aforementioned topic is that the original poster wanted to know about the rate limits regarding renewals, my topic is about the mass-“creation” of certs.


Definitely! Commercial use would be fine too.

That mostly depends on how you intent to solve the domain ownership challenge (and how fast that is for each domain). Roughly speaking, it'll be 6000 * (time you need to finish the process for one certificate), as there's no throttling involved or anything like that, but you could run things in parallel and get it done even faster if you want to. If I'm reading this Squarespace article correctly, they got >50,000 certificates per hour.

That's hard to answer in general, without knowing more about your environment. Solutions like lua-resty-auto-ssl, where certificates are obtained on the fly, are often a good fit for such use-cases (this particular one is for nginx). If your existing web server configuration is rather complex, you might also opt for a more low-level library for ACME and implement things yourself. The client list has a lot of options for various languages and web servers. Happy to suggest something more concrete if you can provide more details about your environment.

Regarding the rate limits, you probably don't need to worry about any of the domain-related ones since those seem to be customer-provided domains rather than subdomains of the same domain (which would be rate-limited). The other rate limits apply to accounts registered per IP address, which doesn't affect you if you simply use one ACME account for all your certificates (which is probably a good idea for this use-case), and the limit of pending authorizations per account, which just means your implementation should not request more than 300 authorizations (domain challenges) at the same time before solving them. In the future, a new rate limit on failed authorizations per hostname and account and hour will be introduced - that one would affect the time you take between retrying failed domain challenges. The most important recommendation regarding the rate limits would be to use the staging environment for testing, which has higher rate limits that are separate from the production environment.

Finally, the Integration Guide has a lot of useful information for the type of integration you're planning.


Hello pfg,

Thank you very much for your quick response!

Here’s how I understood the conditions:

  1. Our use case is legal, valid, and welcome.
  2. Concurrent requests may work. I’m thinking that this involves sharing the same ACME account ID between several IP addresses. Am I correct here?
  3. Since we handle unique domains (not sub-domains but say,,, etc.) the API rate is limitless as long as we use a single ACME account.
  4. It’s best to first make use of the staging environment to test it out.

I’d very appreciate your answer to my additional question.

Correct on all accounts.

To elaborate a bit on 2:
It would technically be possible to use per-server ACME accounts, but I would say this would be more complex to implement.

Many big integrations also perform the certificate issuance and validation from separate servers, keeping the account keys off of the regular web servers. The web servers would have access to some kind of internal service that gives them the private key and certificate chain as needed (that’s roughly the storage adapter from lua-resty-auto-ssl).

Awesome! It is now very clear how we can achieve it!

Thank you very much for your support! I appreciate it very much.



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