Little Background: Debian 8.5 Jessie ISPConfig 3.0.5.4p9 ---- DomainA DomainB both have DNS handled by CloudFlare.com only two sites on ispconf server currently while testing http://www.DomainA.com - works fine Enable SSL & create SSL Cert (self signed is fine) - Set CloudFlare to Full (not Full Strict) - which means selfsigned is fine. once cert is generated on ispconfig - https://www.DomainA.com - works ------- Problem ------- Same process for DomainB - uses the same IP - not on issue on other implementations http://www.DomainB.com - works fine Enable SSL & create SSL Cert (self signed is fine) - Set CloudFlare to Full (not Full Strict) - which means selfsigned is fine. once cert is generated on ispconfig - https://www.DomainB.com Loads but displays DomainA website... not DomainB Haven't tested in ispconfig3.1 beta 1 - have it loaded and should be a fairly easy test - have both sites on that as well. ---- Testing in 3.1 Beta 1 Now ----- Same issue... - (may not be accurate forgot to change domainB aiming to test server for testing. currently DomainA and B not working well after dns change to Beta Server. http fine but https failing - probably cert creation issue but testing currently... Will try Beta 2 shortly and see if the same issue occurs... haven tested this configuration under a different control panel and it is working - but that panel just released its new update as well and it had several ssl updates before it was fixed... had very similar issues and the upgrade to new release resolved those issues for it. ------- ISPConfig 3.1b2 ------- seems with B1 and B1 having issues getting SSL to even work for me - reading though what the process for enabling ssl / even self signed will be fine for now After switching a few times - ISPConfig 3.0.5.4p9 seems to be working properly now.. Im wondering if its an issue with CloudFlare and its redirection... just not sure.
SSL works fine here on beta 1 and beta 2, so there must be an issue with your setup. Check that the vhost files have been written and that they contain the ssl config. I use cloudflare here as well with ispconfig and SSL, works out of the box, no additional settings required. It might be that other panels have issues with cloudflare but gladly this does not apply to ispconfig, otherwise you would not have been able to read this post.
the trick is the same IP for some reason... using made up IP address' server IP NAT 10.15 Client1 - DomainA - 10.15 Client1 - DomainB - 10.15 Public - xxx.xxx.101.10 > xxx.xxx.10.15 xxx.xxx.101.11 > xxx.xxx.10.16 not using .16 currently but you get the idea.. same client multiple domains - did see vhosts and ssl sections written all look good. but was consistent loading DomainA website when hitting https://domainB.com Only when I switched Cloudflare to aim at my Beta1/2 box for testing (which failed - noticed vhosts creating ssl for one domain but not the other - and neither would load ssl connection to the box - figuring something via cloudflare cache but not certain yet) When I switched back - 3.0 Box was working correctly - Which leads me to think it was a cloudflare issue ... as nothing changed on the main stable server.
Such an issue normally happens only when a) the browser does not support SNI yet (e.g. IEXplorer on Windows XP), but this is not ispconfig specific and affects all SSL connections that run multiple domains under one IP address or b) when the second domain has no SSL enabled at all (which you checked and which is not the case). Or you have a caching issue or something in a browser or proxy that you use. SNI means that the client that connects to the server has to send the domain name that he wants to access as the server needs this information to deliver the right content. If the ssl config is not written for a domain (no matter which ispconfig version) then this means that the ssl cert is corrupted so apache /nginx could not start with that config and ispconfig had to revert back to the non ssl config to start the system again.
Upgraded ISPConfig 3.0.5.4p9 to Beta2 and still working for a test.. So working - must have been something else! browser makes sense... typically using Chrome - also saw the issue via firefox but firefox doing better - will have to clear chrome cache out if I see it again.. thx again - sounds like browser - test server I'm disabling as it appears the upgrade was fine. will probably roll back but wanted to see what I had messed up!
