HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials (http://www.howtoforge.com/forums/index.php)
-   General (http://www.howtoforge.com/forums/forumdisplay.php?f=25)
-   -   Problems with installing SSL-certifates on ISPConfig3 slaveservers (http://www.howtoforge.com/forums/showthread.php?t=49244)

Hans 5th October 2010 09:42

Problems with installing SSL-certifates on ISPConfig3 slaveservers
 
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/sho...hlight=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!

till 5th October 2010 10:42

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.

Hans 5th October 2010 11:21

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?

till 5th October 2010 11:50

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.

Hans 5th October 2010 12:22

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. :)


All times are GMT +2. The time now is 20:40.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.