Automated acquire and renewal of certs - Looking for a optimal solution

I am looking for a set of advice and perhaps a best practice discussion here how to implement LE into my specific needs. I will try to point out my requirement and try to narrow it down as much as possible.


We have a web application and part of it user can whitelabel using their own domain ( or subdomain ). The domain forwarding is done via CNAME to our address ( say ).

Now what I am trying to achieve is to give all of white labeled domain their own certs to make the white labeled part of the app secured.

User will have a SSL settings when turned ON our server will provide SSL for their white label domain.

Server Details

  1. CentOS 6.x
  2. Apache 2
  3. RAM 2GB


We have about 5000 users. Lets have a hypothesis that all of them enabled SSL settings at once now system will try to run 5000 request to LE server. The main concern is for me is server Resource uses ( CPU, RAM ). Ignoring API limits.

Question: Is there any estimation (benchmark) on how much resource certbot takes while acquire and renewing a cert?

My plan for counter this is to create a database table and put user account as “Pending” and have LE script to take predefined amount of domains and send requests and acquiring them separately.

Question: With the above circumstances which method of acquiring cert you think will be optimal.

( I do not know if this types of discussion is allowed here. I am not looking for the exact solution but a discussion which will drive to better understanding for me about LE clients so i can make a decision. )

I’m not aware of any published benchmarks of what you’re looking for. Your plan seems sound - I would probably just tune things along the way, starting with something like 4 worker threads (i.e. up to 4 certs being acquired simultaneously) and gradually increasing that if needed. There’s also the question of how often you should reload your web servers to add new vhosts (domains) - apache supports graceful reloads, but I’m not sure how stable things would be if you were to reload it multiple times a second as new certificates trickle in - I would probably cap that at once every minute or 5 minutes.

Another alternative that might be worth considering would be something like lua-resty-auto-ssl, if you’re willing to add nginx to your stack (I’m not aware of anything like this for apache). It’s a plugin for nginx that automatically acquires certificates as requests come in. It allows you to whitelist domains through a lua function - which could just query your database for valid whitelabel domains. This would avoid having to restart the web server constantly, though it would be a bigger change to your stack, so you’d have to check how much sense this makes.

As for the best method, HTTP-01 (for example via --webroot) would probably win for simplicity, with TLS-SNI-01 a close second. The problem with TLS-SNI-01 (which the apache plugin uses behind the scenes): I’m not sure if it’s intended to be run in parallel, as it (temporarily) modifies the apache configuration and restarts apache multiple times, so there might be a number of race conditions if you attempt to run multiple certbot instances with the apache plugin at the same time. --webroot is probably more robust in that regard.

You might also want to scan the Integration Guide for bits that are relevant to your use-case.

1 Like

Thank you for detailed answer.

The plan for reloading server config is once in an hour by checking database value so server reloads if only necessary.

I wasn’t aware of that Apache plugin restarts apache ( which didn’t seem so when I renew certs for our current site ). From your information it seem using --webroot will be more reliable.

Stepping away from the chartbot I have found another acme client written in PHP. I am more experienced with PHP then Python so I am also checking this out.

Only concern is that we use mod_php so need to carefully sort out amount of php process I need to run.

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