Hi, unfortunately, the ssl cert for the domain, I am using to access the IPConfig Panel, has not been automatically renewed. Now, I cannot acces ISPConfig anymore, because the browser is denying any access due to a security issue "HTTP Strict Transport Security (HSTS)". I´ve configured ispconfig to run on an subdomain named ispconfig.mydomain.tld (e.g.) What I found out, there´s two different ssl sets for the domain. Pls. find the list of the files at the end. As you can see, the "-le" stuff is outdatred whike the others have been updated on a regular basis by acme.sh -rw-r--r-- 1 root root 2130 May 7 09:29 /root/.acme.sh/ispconfig.mydomain.tld/ispconfig.mydomain.tld.cer -rw-r--r-- 1 root root 982 Aug 6 00:57 /root/.acme.sh/ispconfig.mydomain.tld/ispconfig.mydomain.tld.conf -rw-r--r-- 1 root root 1712 Aug 6 00:57 /root/.acme.sh/ispconfig.mydomain.tld/ispconfig.mydomain.tld.csr -rw-r--r-- 1 root root 194 Aug 6 00:57 /root/.acme.sh/ispconfig.mydomain.tld/ispconfig.mydomain.tld.csr.conf -rw------- 1 root root 3243 Aug 6 00:57 /root/.acme.sh/ispconfig.mydomain.tld/ispconfig.mydomain.tld.key -rw------- 1 root root 3243 Aug 6 00:57 /root/.acme.sh/ispconfig.mydomain.tld/ispconfig.mydomain.tld.key.next -rw-r--r-- 1 root root 3957 May 7 09:29 /var/www/clients/client2/web15/ssl/ispconfig.mydomain.tld-le.crt -rw------- 1 root root 3243 May 7 09:29 /var/www/clients/client2/web15/ssl/ispconfig.mydomain.tld-le.key
It seems as if you created a website for the hostname; this must fail on acme.sh systems, as you will either get an SSL cert for the website or for ISPConfig then. You likely have the correct SSL cert in /usr/local/ispconfig/interface/ssl/ folder, right? In this case, replace /var/www/clients/client2/web15/ssl/ispconfig.mydomain.tld-le.crt with a symlink to the ispserver.crt in /usr/local/ispconfig/interface/ssl/ and replace /var/www/clients/client2/web15/ssl/ispconfig.mydomain.tld-le.key with a symlink to the ispserver.key file in /usr/local/ispconfig/interface/ssl/ folder and then restart the web server (apache or nginx).
Hmm, just followed your instruction ... no luck and yes, apache2 was restaed. root@vserver:~# ls -al /var/www/clients/client2/web15/ssl/ lrwxrwxrwx 1 root root 48 Aug 6 15:38 ispconfig.mydomain.tld-le.crt -> /usr/local/ispconfig/interface/ssl/ispserver.crt lrwxrwxrwx 1 root root 48 Aug 6 15:39 ispconfig.mydomain.tld-le.key -> /usr/local/ispconfig/interface/ssl/ispserver.key root@vserver:~# ls -al /usr/local/ispconfig/interface/ssl -rwxr-x--- 1 root root 768 Aug 6 07:31 dhparam4096.pem -rwxr-x--- 1 root root 3928 Aug 6 07:31 ispserver.crt -rwxr-x--- 1 root root 3243 Aug 6 07:31 ispserver.key -rwxr-x--- 1 root root 7171 Aug 6 07:31 ispserver.pem
You said you altered the ispconfig vhost to access ISPConfig by domain name. Who did you do that exactly?
As far as I can remeber, I followed the instructions from here: https://znil.net/index.php/ISPConfi...e_als_Subdomain_auf_Port_443_https_einrichten
Ok, these instructions are indeed completely nuts. This guy has no idea how ISPConfig works. The first thing to know is to never manually edit a vhost file of an ISPConfig website. If you do what he wrote there, your setup must break sooner or later. So what you see now is to be expected with using this guide. The right thing would have been to customize the ISPConfig vhost and make it update-safe by storing it as a custom install template, or to simply use a proxy snippet in Apache directives field of a website as shown here: https://forum.howtoforge.com/thread...e-at-subdomain-on-port-443.75712/#post-356870 Basically you can just try to manage things manually now as you can not use ISPConfig anymore for anything related to that site. You must check what certs are used in the files you created and continue to adjust things manually. Also, he seems to use a cert that is not the system SSL cert, so you might keep using that. You can try to set symlinks from /var/www/clients/client2/web15/ssl/ to the cert files in /root/.acme.sh/ispconfig.mydomain.tld/ directly.
Hmm, sounds weird. Is there a comfortable/easy way to revert to the opriginal ISPConfig settings/behavoir?
This site can’t be reached mydomain.net refused to connect. Ups, while checking the 8080 access, I tried again to reach ispconfig via ispconfig.mydomain.net using another browser (chrome instead of ff) et voilà, it´s accessible.
Ok, fine. So, we fixed it by altering the symlinks in the first place. One important thing to note is to never open and edit this website that you use for access to ISPConfig in ISPConfig; you will lose the manually edited config if you do that.
Nope, https still does not work. I have to bypass the brwoser notification about the insecure site. This was impossible with FF
Ok, during some further investigation, I stumbled over this behavior: ISPConfig (System-) Server: sub.mydomain.net (is providing https w. valid cert!) Redirects to: sub.mydomain.net/login/ which is our ISPConfig login page. Is this the intent or a side effect of my (stupid) changes?
If you go to the ISPConfig UI but are not logged in, you get redirected to the login URL so that you can log in first. The Login URL is /login/. So when you get redirected to /login/, this just means you are currently not logged into ISPConfig. If this causes issues, then this is likely caused by your setup, as you replaced the way the ISPConfig Ui is delivered with your own configuration, which can have all kind of side effects.
Hmm, just found in my records: https://forum.howtoforge.com/threads/webinterface-via-https-as-sub-domain.92432/#post-456913 this is the instruction, I used!
So, those are the same instructions from that other site you mentioned here, which caused the issue. As I explained in the other thread as well that a correct way of doing this would have been to create a custom ISPConfig vhost template instead.
Is there some thread or tutorial to read the proper way to use a subdomain for ISPC using a custom template?
Please see post #6 in this thread, it contains a link on how to achieve this using a website. Alternatively, you can create a custom template for the ispconfig.vhost.
