Caused ISPConfig interface to not respond on Port 8080

I am in the process of setting up ISPConfig 3.2. I had it working on a subdomain: e.g., subdomain.example.com, on port 8080 with LE SSL.
I wanted to create a site also serving that subdomain, but on the regular port 443. I went to the Sites page, and created the site.
I forgot to check SSL and LE SSL, though. So, when I saved, I could no longer access the ISPConfig admin site on port 8080. Also, I think redirect to HTTPS is working to prevent my accessing the admin panel via regular HTTP.
I think that by adding that site with SSL unchecked, I also managed to disable SSL for port 8080. Are there data files for ISPConfig stored anywhere I could edit to change this, or is it all in the database? If so, where?

 

You can get to the admin panel via its IP address xxx.xxx.xxx.xxx:8080 as an alternative if you did enable HSTS and it was your only problem.

This is unlikely but I am not sure what is your problem.

Additional note: If you are using acme.sh as LE Client which is default if you set it up using ISPConfig Auto Installer, you should know that you cannot create a site using the same FQDN as you server as it will not renew your server LE Certs as it will then be installed (copied) to that site and be renewed only to it also. This may not be your problem but just a reminder of what would fail in the future if you did so since the site and your server admin panel should still be accessible about 90 days if that was the case.

 

Accessing the IP address on Port 80 also failed. On visiting the console and runnning ipconfig_update.sh --force, I saw that there was a syntax error in the .vhost file in /etc/apache2/sites-enabled/ created by my boneheaded site configuration. I deleted that .vhost file, rebooted the system, and regained access to the panel where I straightaway removed the bad site, replacing it with a proper one.

 

It seems your apache2 failed to restart due to bad vhost and to remove it is the right move. To my note, normally newly created site vhost does not cause this behaviour because default vhost should work just fine.