I'm running ISPConfig Version: 3.2.7p1 and with a single site, and multiple domain names with different TLDs. When first set up, the TLD was .NET. Now I've got the .COM, and trying to make the Certificate stick for that. I've deleted it, using the front-end SSL tab, I've turned off SSL+ LE SSL in the domain tab, saved. Reinstated SSL+ LE SSL, gone back to check 15 minutes later, and the Key/Request/Certificate are all filled in. But the domain still loads with the wrong common name of mydomain.net instead of mydomain.com. I did all the above once again, and checked within the file system, and removing all the files from the SSL directory of the web client (/var/www/<website>/ssl), going through the steps again to recreate the certificate. Still getting the same problem. What am I doing wrong?
I can also see that ACME.SH has something to do with it; and the filesystem under root /root/.acme.sh/acme.sh --revoke --domain mydomain.net will remove the unwanted certificate. Back into the SSL tab from there, the domain chosen is the .com, choose save certificate, the mydomain.net files are back into the acme folder of root...
Doing acme.sh --issue command ( I cannot show you as the forums think I am dumping a URL) looks hopeful, but fails, because even though I am into the server via SSH as root, it will not let me create the .well-known due to permissions error!! How is root not allowed in, when that folder belongs to root?
Using chattr -i I could gain write access to those web folders. But I've not been able to get the right combination of commands for acme to write the challenge in there properly yet.
Are the additional domain names aliases to the original website? Then adding them to the website certificate should work unless you did not turn on the adding box. Do this: https://www.howtoforge.com/community/threads/please-read-before-posting.58408/ It has chapter about failing LE certificate, do read that also.
Yes. So far nothing has worked. Now I am in the position where the GUI's Lets Encrypt SSL fails to activate, there is nothing in the SSL tab, I manually ran acme.sh to get a certificate for the .COM, and have put these into the /var/www/domain.com/ssl folder, then enabled the nginx vhost to choose the CRT and KEY files. Restart nginx, and the certificate applies, with correct domain .com, but still says it's insecure as not vendor signed.
When following this: https://www.howtoforge.com/getting-started-with-acmesh-lets-encrypt-client/ I never get any PEM files referred in the last step.
Your problems are caused by manually running acme.sh so please undo whatever you did manually. To fix your server LE problems there is no other choice but to follow the LE FAQ as referred to by @Taleman closely. Other than that did your server run certbot before or it has been using acme.sh since the beginning? If the former is your case, then revert back to certbot and remove acme.sh totally because a confused server with two LE clients will definitely fail.
It seems to be a problem with LE unable to verify the cert. I've got the CAA in my DNS server, but I'm unsure how to proceed with getting acme or ISPConfig to work with that. It was a new install at beginning of February, so came with just acme.sh. I have followed the link per Taleman, to no avail so far. I have also updated acme.sh in case that was at issue. In order to revert to anything else it will require too much walk-back, I think it may be more appropriate to start again, but still not having any idea why the LE cannot verify doesn't fill me with confidence. Thanks for your reply.
In that link is this link (https://www.howtoforge.com/community/threads/lets-encrypt-error-faq.74179/) so did you follow the LE FAQ as well? It might frustrate you after a start over if the problem is the same so I'd suggest to find and resolve the LE fault.
SOLVED. I had to do it manually, but it now works. acme.sh --issue --dns --domain mydomain.com --webroot /var/www/mydomain.com --yes-I-know-dns-manual-mode-enough-go-ahead-please [Mon Apr 11 02:53:04 UTC 2022] Using CA: https://acme-v02.api.letsencrypt.org/directory [Mon Apr 11 02:53:04 UTC 2022] Creating domain key [Mon Apr 11 02:53:04 UTC 2022] The domain key is here: /root/.acme.sh/mydomain.com/mydomain.com.key [Mon Apr 11 02:53:04 UTC 2022] Single domain='mydomain.com' [Mon Apr 11 02:53:04 UTC 2022] Getting domain auth token for each domain [Mon Apr 11 02:53:05 UTC 2022] Getting webroot for domain='mydomain.com' [Mon Apr 11 02:53:05 UTC 2022] mydomain.com is already verified, skip dns-01. [Mon Apr 11 02:53:05 UTC 2022] Verify finished, start to sign. [Mon Apr 11 02:53:05 UTC 2022] Lets finalize the order. ......
You did not solved the issue, you just broke your system so it will fail in future LE updates and the site may become unmanageable as well. So here again, follow the let#s encrypt FAQ to find out why it fails: https://www.howtoforge.com/community/threads/lets-encrypt-error-faq.74179/ This is a step-by-step checklist, start with the first point and then work your way down until you know what the issue is. and NEVER run certbot or acme.sh manually for a website on an ISPConfig system, it will break your server even though it might seem at the first glance that it may have worked, the failures will occur later.
Thanks, I did go through all of that a number of times. Yet none of those things helped. And that is no fault of the ISPConfig system, as it cannot be expected to be foolproof (the world knows how to build a better fool, i.e. me); I tried to change the domain for the certificate without understanding that it was going to stop everything working. And in the end, something I must have done with the acme challenge is what stopped LE from communicating with the site, so that only the DNS challenge worked. It is a shame that there isn't better logging from their side of things so that we could tell where the fault lay, but that's fine. And yes, I am prepared to fix what breaks at next update or whatever. I've always learned by breaking and fixing. Cheers!
The last step of the FAQ tells you to turn on debugging, if you would have done that and posted the debug result in the forum, then we would have been able to help you solve the issue.
