All certs on my v3.2.12p1 system update and all sites on normal :443 seem to get the new keys. In June, Acme issued the ISPConfig dashboard itself on 8080 a cert update, but the dashboard site was still using the old cert, so now it's not accessible. In April, I migrated this system from 3.1 to 3.2. The 000-ispconfig.vhost file shows: SSLCertificateFile /usr/local/ispconfig/interface/ssl/ispserver.crt SSLCertificateKeyFile /usr/local/ispconfig/interface/ssl/ispserver.key #SSLCACertificateFile /usr/local/ispconfig/interface/ssl/ispserver.bundle These are the files in /usr/local/ispconfig/interface/ssl: -rwxr-x--- 1 root root 768 Apr 27 10:52 dhparam4096.pem* -rwxr-x--- 1 root root 45 Apr 27 10:52 empty.dir* -rwxr-x--- 1 root root 3985 Apr 27 10:52 ispserver.crt* -rwxr-x--- 1 root root 3247 Apr 27 10:52 ispserver.key* -rw------- 1 root root 7232 Jun 25 12:08 ispserver.pem -rwxr-x--- 1 root root 7232 Apr 27 10:52 ispserver.pem-250625120832.bak* So the cert was issued in April, a new .pem was generated in June, but the .crt and .key files weren't replaced. In /var/www/domain.tld/ssl all of the certs for the domain have a .crt and .key issued in June. Should I update to v3.3 to fix this? Might deleting the existing .crt and .key files above allow the acme processing to write to that ssl folder? What steps should be taken to get this back in order? Thanks!!
You should update to v3.3 regardless. I think there has been a problem renewing the certificate but the renewal hook script has been run nontheless. That's the only explanation why the pem file seems to be new. But I bet you its content is exactly the same as the old crt and key files. You should check the logs for renewal errors.
You do not use the regular ISPConfig server certificate for the dashboard if you have cert files in /var/www/domain.tld/ssl. So you do not have an issue with ssl cert renewal, you have an issue with the way you build the .pem file outside of ISPConfig. You should check the script or method that you have built yourself to do that, as that#s what failed here.
Oops, missed that part. This is exactly the reason why you should NEVER create a website and certificate with the exact same name as the system's hostname. I do am a bit surprised the renewal hook script for the system certificate seems to have been run though.
I guess he has an alternate script in place that copied the certs, so the renewal hook did not do this. Maybe something like this, but without working .pem file creation: https://www.howtoforge.com/securing...server-with-a-valid-lets-encrypt-certificate/
Alternate script that does exactly what the renewal hook does among maybe other stuff? (move old pem to pem-date-bak and copy key and crt into new pem. Not very likely I would think. But only @TonyG can clear that up.
I don't have anything custom - I'm not competent with acme or LE interfaces to do that yet. I used the migration tool, upgraded to 3.2.12. This is completely vanilla. @till said > You do not use the regular ISPConfig server certificate for the dashboard if you have cert files in /var/www/domain.tld/ssl. The server was updated to v3.2.12 in April. In June, see above, the cron process auto-generated ispserver.pem into /usr/local/ispconfig/interface/ssl. Whatever it was using was valid until the cert just expired. Yes, there are .crt and .key files in /var/www/hostname.domain.tld/ssl. Those are there because there is a hostname.domain.tld:443 site in addition to the hostname.domain.tld:8080 site. I'll gladly delete the 443 site if that conflicts with the 8080 site. I don't recall why it's there but it was new with the migration and I believe a part of the Perfect Server installation process. @till said > you have an issue with the way you build the .pem file outside of ISPConfig I don't know what process is creating that .pem file (that's just a concatenation of .crt and .key, right?). From my perspective this is all vanilla. I've been positioning this inquiry as an opportunity to maybe find an issue with the migration tool or instructions. But maybe this is just an opportunity for me to do some housekeeping. Will this fix things? : Clear all of the /var/www/*/ssl folders Clear all of the site folders under /root/.acme.sh Clear all of the files in /usr/local/ispconfig/ssl Update to 3.3.0 Thanks again.
I'm not aware of such a rule. Can you explain that? In /root/.acme.sh there is a folder for hostname.domain.tld which is a virtual host created (manually?) in initial installation during a ISPConfig migration. This is the URI with :8080 for the ISPConfig dashboard. The server domain.tld also has a website with a cert. I had the same config for my previous production ISPConfig server and it was never an issue.
Every ISPC install has (or at least tries to get) a system certificate for the system's hostname. When using acme.sh for certificates it will be stored in /root/.acme.sh/<hostname> and copied to /usr/local/ispconfig/interface/ssl/ispserver.key and .crt. Also a .pem file is created containing both its content. A renewal hook script is attached to it that backs up the .pem file and creates a new one on renewal, after which several services using the system certificate are being reloaded. When you create a website with the same hostname and check letsencrypt it will clash with above. The certificate's config file gets rewritten and as a result the key and crt files are copied to /var/www/<hostname>/ssl instead of /usr/local/ispconfig/interface/ssl. Apparently the renewal hook remains, but it realy doesn't do much anymore as the certificate in /usr/local/ispconfig/interface/ssl isn't renewed anymore.
I'm quite sure you did not have the same config on previous ISPConfig installations as you now use acme.sh and have previously certbot, that's a completely different system setup regarding SSL certs. All the issues you describe are caused by you switching from Certbot to acme.sh Let's Encrypt client during migration, which is not supported and should not be done, as both work very differently. If your old system used certbot, then the new one must use it as well; if you do not obey this rule, your system will end up broken with SSL cert renewal, remaining symlinks, etc., as you described in various posts. So we can
@till wrote > I'm quite sure you did not have the same config on previous ISPConfig installations as you now use acme.sh and have previously certbot Sigh. I thought the migration toolkit would migrate/update the cert manager assets to the current default. This is a new OS, not a file-system copy, so there's no /etc/letsencrypt, no certbot or python3-certbot-apache package. I didn't use the --use-certbot option. On install, the system installed acme.sh, issued certs, it all worked. That was in April, new certs were issued in June, it all looked fine. > If your old system used certbot, then the new one must use it as well; if you do not obey this rule, your system will end up broken Your message got cut off, please continue - "so we can...?" As noted earlier, I'm fine with clearing all the old cert files from /root/.acme.sh and /var/www/*/ssl, and re-issuing for all sites and the control panel. Is that all that's necessary?
The Migration Tool showed you a warning that you are using an incompatible LE client and that LE certs will not get migrated, and paused. That's the point where it would have been good to fix the target setup. As you can't redo the migration with the correct LE client, you will have to live with the situation as it is. The certs in /root/.acme.sh/ are fine; there is nothing that needs to be changed. You will just have to live with remnants of the old setup or clean it up manually, and you must ensure that you have a proper build script in place for the central system certificate. I posted a link to a guide that shows how to set it up correctly in post #5.
I think this is simpler than it seems. I'm sure I haven't communicated properly. I'm no longer running mail services. Certbot was never installed or run on this system. The cron process is already setup by ISPConfig to run acme.sh. There is no custom script. Since the cert is no longer valid I can also no longer access the control panel - I need to fix this quickly from the CLI. It looks like I need to: - clear old junk from /var/www/*/ssl - ensure there is a good .crt and .key for the servername.domain.tld - symlink from ispconfig/interface/ssl to the above - create the ispserver.pem (for monit) - check perms If it is all working, using a --force for new certs, followed by checking folders, should verify that everything is current and working for the next cycle. Are there any other actions that need to be taken to fix this condition? What other cruft needs to be fixed? It sounds like there is some mysterious "it's permanently broken" condition what exactly does that mean in terms of data and code? But what about using servername.domain.tld:8080? @remkoh says this isn't valid, but I've been doing that for years without issue, and the Perfect Server instructions have always told us to do exactly that. Monit uses that FQDN too. So is he mistaken? Is it better to move to another dedicated FQDN? Thanks.
I had to move forward. That surgery seems to have worked. The questions remain about whether that was correct and about the FQDN.
Port 8080 or 8081? If what you mean is ISPC's apps vhost, that's running on port 8081. That too is using the system's default certificate in /usr/local/ispconfig/interface/ssl As is monit. By creating a website and certificate in ISPC with the same fqdn you screw up the system's default certificate as you have noticed. Looks to be correct.
Oh wait, nevermind. Port 8080 is the default panel port (I'm running it on a different port so forgot) Same story as apps and monit. All use the certificate in /usr/local/ispconfig/interface/ssl which is the system's default and got screwed up.
@remkoh How do you reconcile your position that serverhostname in the control panel FQDN is invalid when that is the configuration that's always been in the Perfect Server docs? It's OK to say you were thinking about something else, but if you're onto something important I'd like to know. ................................. Thanks
Nowhere in the docs it says you need to create a website and certificate in the ISPC panel after installation for server's fqdn. When you did that it altered the certificate's settings that where created during the install of te server and ISPC. And 2 month later the server's certificate didn't renew properly anymore. And another month later it expired.
Fair enough. The vhost subdomain was created to avoid a condition where visting the FQDN:80 or :443 would return a configuration error. Since there's no explicit `<VirtualHost *:8080>` block in the .vhost file, requests to 80, 443, and 8080 seem completely independent. If the cert is renewed through :80, and that's symlinked to /usr/local/ispconfig/interface/ssl, then it looks like any acme renewal for the domain resolves to the same cert files. I don't have any content served from the FQDN:443 so I don't care if there's a site there or not (but I need to check for that Apache issue). Given that it seems that I've fixed the situation and certs are now renewing correctly (we'll see what happens in 3 months) do you see any reason to mess with it anymore?
