Nope. I know the Limits of Let's Encrypt regarding certificates per hour and I am very careful not to overstep them. Also, it produces a different error message would that have been the case.
Hi Taleman, this is a standard redirection one of my colleagues probably needed for some long dead project. I'll talk to my colleague and ask him if anything breaks if I delete it. But I am sure I did not ask for www, I dont need one for a dedicated mailserver. hostname mail1 hostname -f mail1.consulting1x1.info Yours sincerely Stefan
You can try steps mentioned in here where @chief used nightly build and get LE certs for his server: https://www.howtoforge.com/community/threads/debian-10-multiserver-setup.86639/page-5#post-426157
That does work, I have been following in Chiefs foot steps with regard to his issue. Installer fails LE cert > self signed created > force update using nightly build > yes to new cert. My concern, and I have raised an issue for it. If the updater can create the cert then the installer must be doing something slightly differently to get a fail. What I do not know, but the problem is reproducible.
Good to know. The developers know what they did to fix the updater may be they missed similar code in the installer. Was just merely guessing as it could be other problems or issues related.
I am not sure how but it seems that acme.sh is not configured correctly in the installer, but for the updater it is. I have the new acme.sh log and have created an issue, I will add it to it.
Did you find anything useful in the logs e.g. apache2 cannot be started, as I don't recall any report on nginx server for the same was ever raised. May be you can try on nginx server to see if there is any difference, that is if you have a spare server to do the test?
Here is the issue I submitted. https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/6216 I attached the log file t a reply to it. I will run an install using Nginx this evening. The good thing about local VM's They cost nothing to set up, just a little time. I had not considered testing Nginx but I will be happy to.
The installer and updater are using the exact same code. The difference is that the services were restarted at the end of the installation. I've added a draft for changes to reload apache and nginx in between. But we have to check if this does not break other things. https://git.ispconfig.org/ispconfig/ispconfig3/-/merge_requests/1508/diffs
Ok, so here is the final solution to the issue. It was not a problem with the reload, the source of the problem and the reason why it popped up out of the blue without having released a new ISPConfig update that might have introduced a new a bug is this: "Starting from August-1st 2021 , acme.sh will release v3. 0, in which the default CA will use ZeroSSL instead." Zerossl requires a registration upfront, while LE does not require that. ISPConfig changes the acme.sh default CA to LE already when it downloads acme.sh itself and it also changes it at the end of the installation process. But in the case of using the auto-installer, the auto-installer has already downloaded acme.sh, but it has not switched it from ZeroSSL to LE. In this edge case, ISPConfig does not run its own routine to switch to LE before it tries to issue the cert, but issuing the cert fails now due to the missing ZeroSSL registration. At the end of the installation, the acme.sh config switches to LE, that's why it finally works on a new update. To use the branch which contains this fix, add the option: --channel=dev to the autoinstaller command. Example: Code: wget -O - https://get.ispconfig.org | sh -s -- --use-ftp-ports=40110-40210 --unattended-upgrades --channel=dev
I have updated my answer on that thread too including the update part. Hopefully with it being in a few locations on the thread and now prominently highlighted people should see the two fix paths to take.
