Dear Till, Within these forums i can see that several persons do have problems with installing a SSL-certifcate for their website which are hosted on their ISPConfig3 server. Also do i and it causes me pain in my head. I try to explain what happens: I have a cluster of 6 ISPConfig3 servers (2 machines, 3 on each machine). These servers are all XEN VMs Every ISPConfig3 server (of course) has its own IP-address. On the master ISPConfig3 server i use some additional IP-addresses as well for the websites whith Comodo SSL-certifaces. This works excellent. However, when i define additional IP-addresses with version within ISPConfig3.0.2.2 it goes wrong. I mentioned this already before within thread http://www.howtoforge.com/forums/showthread.php?t=49072&highlight=3.0.2.2. After modifying the file /etc/network/interfaces again, i installed the website with a dedicated (additional) IP-address (not *) on the slave server. And yes i know which steps to take as i did this procedure many times. After installing the Comodo SSL-certicate everything is up and running, so thats good....alt least for a while. After some time Firefox shows me the error at http://www.example.tld "It works" and at https://www.example.tld ssl_error_rx_record_too_long. After some time everything is normal again, which means the site is up and running. First i thought: probably i did something wrong, maybe an DNS issue, but no. Also the vhosts where fine! I repeated all the steps 3 times for 2 websites with a SSL-certicate but the problem remains. After all, i decided to change the IP-addresses of the websites with SSL-certicates into the same IP-address of the host, which are the same IP-address of the slave ISPConfig3 servers. That worked and keeps working. The sites with SSL-certicates keeps up and running. On the master ISPConfig3 server i use websites with additional IP-addresses with SSL-certicates as well. No problems on the master server. However, the same result on the slave servers when additional IP-addresses is NOT possible. I want to ask you to have a look at this, because this is really not nice!
This seems to be a DNS problem. Changing the IP address resolves such dns problems when the slave and master servers have diffenet IP addresses for a specific A-Record (split brain). You have to check the master and every slave server if they all give the correct IP address back for a specific A-record. ISPConfig is not doing any scheduled reconfigurations and if the vhost file is ok, then it is not caused by ispconfig.
Hi Till, Ok i see and thanks for your answer! To be honest, I did not think about a "split brain". But if so, how is that possible. I mean, all server domain names and websites make use of the same DNS-servers. These are the 3 DNS-servers of my DNS-registar. (I do not use my own.) Does that mean it is a DNS-cache problem on one of the DNS-servers i make use of?
A split brain happens e.g. if one of the dns servers misses a dns update or did not accept the update. You can try to check the domain with a dns test tool like this: http://www.intodns.com/ But it might be that it reports that everything is ok now as you changed the IP.
Hi Till, Thanks for your help and sorry for my wrong conclusion, but i was thinking that it must be a bug, because of my bad experience with adding additional IPs and the wrong result in /etc/network/interfaces. I did change the IP indeed and that avoids the problem exactly as you told me.
