ISPConfig Inaccessible After SSL Certificate Expiry

Hey there,

My ISPConfig was working perfectly, but now when I try to access the admin panel at:

https mydomain at 8080

The admin interface won’t load, and I can’t access anything on the server anymore, including the ISPConfig admin, websites, SSH, email, etc. It feels like I’m getting blocked by the firewall. After some time, access is restored automatically.

I suspect the issue might be related to an expired SSL certificate. I tried forcing an update on ISPConfig by running:

Code:

ispconfig_update.sh --force

I requested the creation of a new SSL certificate, and everything seemed to go smoothly. However, I’m still facing the same issue when trying to access the admin panel.

Does anyone know what might be going on?

Thanks!

 

Thanks so much for your response, till!

I’m getting the browser error saying the SSL certificate is invalid, but I can’t say for sure that this is what’s causing the block.

I was thinking maybe it’s a common issue related to some security feature handled by ISPConfig.

I’ll look into how Fail2Ban works and see if I can sort out the problem. I’ll post an update if I find anything.

 

I still have no clue about the exact cause of the problem, but I'm fairly certain it's related to the SSL certificate.

Whenever I try to connect remotely using:

Code:

openssl s_client -connect server.mydomain.com:8080

my connection gets blocked. However, when I run the same command locally on the server, it works fine.

I've already tried disabling Fail2Ban with:

Code:

systemctl stop fail2ban

but the block keeps happening regardless.

I’ve gone through all the logs with recent changes in /var/log, but none of them show anything related to the connection being blocked

Any ideas on what else might be causing this?

 

My signature has link to Fail2Ban tutorial.

 

Taleman, thanks for pointing me to your Fail2Ban tutorial — I learned a lot from it!

It turns out the issue is actually related to the SSL certificate. For some reason, when trying to connect to the server to validate the certificate, the handshake is interrupted, which is why the ISPConfig admin panel isn’t loading.

The problem doesn’t seem to be with ISPConfig or the 'Perfect Server' setup. So, I think this thread doesn’t really apply here and can be deleted.

Thanks again for your help! I’ll keep investigating the SSL issue on my end.

 

What Plesk has got anything to do with ISPConfig? ISPConfig does not support wildcard certificate out of box yet though one may use it at one's own "costs" and there are already several threads discussed on how to achieve that on an ISPConfig server.

 

Sounds frustrating! Have you checked if any recent updates or changes could’ve impacted your firewall settings?

 

I did have a similar problem once, but as “till” said, fail2ban was blocking my ip due to the fact that I was repeatedly sending the wrong password to the server.

So, may I ask Paloma Nunes, has the problem been solved? I'm curious about this.

 

Hey Dy-2024! Thanks a lot for the tip and for sharing your experience.

Unfortunately, I’ve already ruled out fail2ban as the cause. I ran several tests with fail2ban completely disabled, and the issue still persists. I also checked all recent logs in /var/log, but there’s nothing there that gives any clue about what might be causing this.

Still no solution on my end, sadly.

 

If that's the case you should look into what is interrupting the handshake.
It could very well be a firewall in front of your server. If not your own maybe your ISP?

 

I'm trying to figure that out myself.

I've tested the validation from multiple connections, even from different countries, and the issue remains the same. So I think it's safe to rule out any problem with my ISP.

The validation only goes through when the request is made from a terminal within the same network as my server.

Yeah, I’m pretty sure the issue lies with the network where my server is hosted. I’ve reached out to their support team, but they insisted there are no restrictions or blocks on their end.

I have 'replica' servers running in other datacenters, all set up exactly the same way. The two I have in this specific datacenter both show the same issue, while the others work perfectly fine.

 

Default answer To be read as "uhhh .... what??" responce

That pretty much tells you your hoster is causing it.

 

Once again, I've read through this whole thread...
Is it possible that you are using the same PC for all these tests?
I mean is it possible that it's something routine and insignificant? I seem to have a similar one, I started with Google Chrome and Microsoft Edge, but then switched to Firefox and everything worked fine again, didn't really bother to find out exactly why at the time since it was an initial test, and then reinstalled the system afterward, and that seems to be my experience.

 

Yeah, that’s almost certain at this point. Now I’m just trying to figure out if there’s anything I can do to work around this issue.

For instance, with AWS, to get the quota system working, I need to install an additional package called linux-modules-extra-aws. Plus, I have to adjust the Passive Port Range to connect to FTP successfully.

I've run tests both on my local browsers and through remote terminals (like AWS, Digital Ocean, etc.), and I'm encountering failures across the board. I even asked a few colleagues to test from different networks, and I’m still getting the same error every time.

 

Extra kernel modules (to enable quota among other things) have nothing to do handshakes.

 

Exactly! My point is that having servers with identical configurations doesn’t always guarantee they’ll run smoothly in every environment. I mentioned two specific requirements that are unique to AWS as an example.