Hi I have a debian installation with ispconfig 3 on an office discrete server (not VM). When trying to install nextcloud on a different machine on the same network, this must have caused a mixup of the SSL certificates for our domain / public IP address. leading to email deliverability issues on the other machine running ispconfig. Firstly the response time of the mail server has become inoperable we have SMTP banner mismatch and the TLS is not working. These are all reports made by mxtoolbox. Please advise how we can revert back our running mail server. Is there a way to fix these SSL certificates without reinstallation?
Sounds more like a firewall screw-up. Something done wrong with nat/portforwarding. No way a different server can cause certificate issues on your ISPC server.
it has messed up two mail servers on the same network each running independently ispconfig, with now very slow response times and transaction times and the problems identified above. The router is performing well with its nat and tried redirecting traffic to each server, with the same problems.
also on update of the ispconfig to attempt to overcome any issues I get ...Server's public ip(s) () not found in A/AAAA records for...[domain] Note that I have made absolutely no changes in the dns records
No clue then what has gone wrong with your 2 mailservers. But it's just impossible that a nextcloud installation on a totally separate server has caused it. Nextcloud doesn't do anything SSL/certifictate related. You do that in the webserver you're using to publish nextcloud. Your last post points to dns issues.
As @remkoh mentioned, installing software on a third server can not have messed up your ISPConfig systems. This third server has no way to access or change anything in ISPConfig.The more likely reason is that changes in your router or firewall to make the nextcloud system accessible caused this. Better not touch or modify the ISPConfig system, as it may not have been changed when you do something on a third system. Altering the ISPConfig system will not help in the best case and could cause damage in the worst case.
The script that facilitated the nextcloud installation has created an SSL configuration using cerbot. I dont know how this works, but if the public IP of our network got associated with a different set of SSL certificates pointing towards nextcloud then this may have easily messed up our public access to the servers.
Since it started with your 3rd server, does it end when you shutdown that server? I'm thinking your 3rd server may have hijacked the ip of a dns server in your lan that you're using for dns resolving on your mailservers. So with that dns server gone the mailservers can't resolve anything anymore. It's just a thought...
It looks like a dns problem as there is clear dns delay even accessing web pages in the network, however the google dns servers in the router remain intact. The NC server has been shutdown and unpluged from the network. The other servers use static ips with static dns (same as the router). Any pointers?
