I've had this issue since I started with ISPConfig 3 back in Feb/March. A SSL Cert will expire and unless I'm checking or the client calls, a domain can go like that for a few days before I'm made aware. I found some websites that let you check your SSL Cert for free, and one of them alerted me to 2 sites that has expired/bad SSL certs and I was able to quickly redo them quickly a few days go. Today a different client emailed me saying his site was insecure. My fix is to go into Sites > click on the domain name -> uncheck SSL and Let's Encrypt SSL and Save. Once that is finished I go back into the domain, recheck SSL and Let's Encrypt SSL and Save and this resolves the issue. I have Auto-Subdomain drop-down set to www. The domain doesn't have www in front of it in the "Domain" field, and the Dependent sub-/aliasdomains don't have www. in front of them either. Today I took a look at the expired/bad cert before fixing it. It had today's date & time as the issued date, but I noticed it said it was issued to www.domain.com (for example). So after I did my trick of remove/add I went back to inspect the script and this time the issued date was pretty close to the previous issued date but it shows issued to domain.com (not www.domain.com like previously). Is this a bug?
No, there is no such bug. You seem to run a second service or cronjob that renews the LE certs instead of letting ISPConfig do this, which causes the webserver to not restart after SSL cert renewal. You must stop and disable that other service.
That's what I was wondering. When I looked through the Let's Encrypt log, it showed the initial cert renewal and there was a line about restarting apache. On the second renewal I forced, there were much less lines in the logfile but it did show apache was restarted at the end as well. I personally didn't tinker with Let's Encrypt on these servers (3 of them). I just followed the instructions on the perfect server for debian 12. Here's a snippet from the log file on the ending of the first cert renewal: [Thu Nov 7 10:35:55 AM EST 2024] Running reload cmd: systemctl force-reload apache2.service [Thu Nov 7 10:35:55 AM EST 2024] Reload successful [Thu Nov 7 10:35:55 AM EST 2024] _on_issue_success [Thu Nov 7 10:35:55 AM EST 2024] '/usr/local/ispconfig/interface/acme' does not contain 'dns' [Thu Nov 7 10:35:55 AM EST 2024] Return code: 0 and when I manually unchecked/rechecked it shows this at the very end: [Thu Nov 7 03:02:02 PM EST 2024] Running reload cmd: systemctl force-reload apache2.service [Thu Nov 7 03:02:02 PM EST 2024] Reload successful Without those extra 3 lines from the first try... does that help narrow down my issue?
Which log file did you look at? As I said, I guess you run a service or cronjob that renews the cert instead of letting ISPConfig renew it and this causes Apache not to be restarted.
Good question! I was actually viewing the log file from within ISPConfig. Monitor -> Pick Server -> Let's Encrypt Log. From what I can see that resolves to /var/log/ispconfig/acme.log
a crontab -e on this server shows: 33 10 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null * * * * * /usr/local/ispconfig/server/server.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done * * * * * /usr/local/ispconfig/server/cron.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
That depends on if certbot or acme.sh is being used. With acme.sh there's a cronjob (which is shown in the previous post) that handles renewals and ISPConfig itself doesn't do much. @Gerry F what happens when you run this command manually? Code: "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" Does it give you any errors? It should if there are any problems.
I changed directory to /root and then ran acme.sh --cron --home /root/.acme.sh No errors. It skipped everything as expected. Strangely enough the last 3 domains had www.theirdomain.ext as "renewing" (while all the others are just domain.ext) And it broke one of the sites with the leading www. I just did a systemctl force-reload apache2.service to see if that would resolve the cert issue but it didn't so I had to jump into ISPConfig 3 again and uncheck and then recheck the items I've mentioned above and now it's fine. I had to go through all the other sites to ensure they weren't broken (the rest were ok).
That's not strange. Every name needs to be authenticated when renewed. You will have set auto-subdomain to "www." for those 3 domains/websites.
Hmmm, ok?!? Every domain/certificate has it's own folder in /root/.acme.sh/ Are there separate folders for domain.tld and www.domain.tld for those three?
Awe! You may onto something! On the 3 domains I mentioned that show up as "renewing www.domain.tld" there is indeed 2 directories.... one as domain.tld and a second as www.domain.tld All the others just use domain.tld
I assume I can just delete the www. directories? Which is another issue... I had the occasion to delete 2 separate clients... everything went fine except it didn't delete the directories for the domain in /root/.acme.sh/ so I deleted them manually....
Question is why www and non-www got separated. Check the conf file in the non-www folder for the existance of www.domain.tld besides domain.tld (Le_Domain or Le_Alt). If it exists deleting the www folders should be safe. Yes, cleanup needs to be done manually (at least for now).
Yep, the www.domain.tld existed in the conf file. I have deleted the extra www.domain.tld directories and we'll see if this issue returns or is finally put to rest! Thank you so much!!
