Is that domain actually yours? Because it is a valid domain name owned by someone.
We don't want to spend effort debugging that until we know your actual name. Please use example.com otherwise which is an industry standard. We can update your post once you let us know. Thanks
No one here can offer much in the way of useful assistance without knowing the real domain name where you are encountering difficulty.
So pick one and work through it. If you are lucky, it will be the same issue on all of your domains.
You should have been presented a template when you made you initial post. We need the answers to the questions it contains for anyone here to be able to offer any effective assistance.
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
Yes, the log file is scrolling for each domain that is good or expired.
We have always used the apache plugin: "The Apache plugin will take care of reconfiguring Apache and reloading the configuration whenever necessary." If I remember correctly it stopped from Apache from reloading after every cert renewal but maybe I am wrong on that.
Normally, you use certbot --apache to get and configure the initial cert. It creates a renewal profile in the /etc/letsencrypt/renewal folder
After that a certbot renew will get new certs (renew them) when close to expiry (within 30 days of expiry for 90 day certs). It uses the renewal profile conf file to know how to request that (including reload Apache if needed). It scans all the conf files in that ../renewal/ folder so acts on all previous successful certs.
A certbot renew is usually run by a systemd timer or cronjob setup when you installed Certbot.
Frankly, with the large number (hundreds) of certs the --apache plugin is probably not optimal choice. But, that's for a different day
Not that this helps sort out what is happening here but thought it worth saying.
BACK TO THE PROBLEM ... is there one Certificate Name from that list that you can share. I'd like to suggest some commands to isolate this problem.
Sorry, you are correct. I just took this project over. They are using certbot --apache to get and configure the initial cert. And the cron for renewals.
I just added a new domain for you to test and tried to create a cert for it and it hung just like the others and it just hangs during creation as well.
sudo certbot --apache --agree-tos -d OpenHousePermit.com -d OpenHousePermit.com
Good news bad news. The --webroot method does not require Certbot to parse your Apache config or to even reload it. It simply writes the challenge token to the -w path and then tells Let's Encrypt to validate it. The LE servers send HTTP requests to validate and if it works Certbot proceeds to get the new cert. We often add a --deploy-hook to reload the server when a new cert is acquired.
The --apache option interacts with your Apache server and config directly. It parses entire Apache config and modifies the VirtualHost for the domain by adding some statements to handle the challenge. It then does a graceful reload of Apache to make that effective. It signals the LE Server to perform the challenge. Certbot gets the new cert if successful. It then removes the lines it just added to your VirtualHost and gracefully reloads Apache again which both effectively removes those lines and has Apache pickup the new cert.
Really, with very large Apache systems the --webroot is more efficient. The bad news is converting "hundreds" of certs is no trivial task.
I am not sure how to further debug the "hang". This probably needs the Certbot dev team to be involved. Or a different volunteer here with internal knowledge of Certbot.
I don't have any other good ideas. Maybe adding -vv to that renew --dry-run will output further info that might point to where it is hanging.
Posting at the Certbot github is probably next best option. I can describe the easiest commands to convert your existing cert profiles to use --webroot rather than --apache. That seems like a lot of work and github may get you an easier way forward. Make sure you say that --weboot works, --apache hangs, and you have a very large number of existing certs.
At the github they may want you to try the most recent Certbot version first. Your v2.1 is roughly two years old. I am guessing it is the most recent from apt (or whatever packager you used). In which case you may need to follow the snap install instructions (or pip venv if you are experienced with such things).
For snap instructions, follow each step carefully.
