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 (https://letsencrypt.org/docs/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:
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)
How long does it take to complete the cert issuance for 6k unique domains?
(Related to 2.) What is the most efficient way for an entity to create thousands of certificates?
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.
Concurrent requests may work. I’m thinking that this involves sharing the same ACME account ID between several IP addresses. Am I correct here?
Since we handle unique domains (not sub-domains but say example-a.com, example-b.org, example-c.net, etc.) the API rate is limitless as long as we use a single ACME account.
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.
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).