Strange ssl results

@gwr

Also, SSL reports from SSL labs are correct for both sites:

• https://www.ssllabs.com/ssltes…lahusch-hausverwaltung.de
• https://www.ssllabs.com/ssltest/analyze.html?d=erendiz.com

To resume, the issue is only in your head

@gwr

Are you serious?

First, you should learn a bit more about SNI and how Apache2 is working. As administrator you should at least know that:

• Your IP address is not a domain name and is not part of the SSL certificate alternative names (even through, that would not solve the problem).
• You shouldn't reach your site using an IP address
• To make NO SNI working, the IP must be assigned to only one SSL vhost.

So yes, I confirm that the issue is only in your head, probably due to your lack of knownledge regarding how both SNI and Apache2 are working.

We use the Name-based virtualhosts and SNI only. Thus, if you browse a site using the IP address instead of the domain name (which must be part of the SSL certificate subject alternative names), Apache will not be able to determine the real vhost that you want reach because the Host header will not matches with any server name. In such case, Apache will serves the first site that it can found (the first vhost matching your IP address). That the expected behavior.

Note that you cannot use the IP-based Virtual Hosts because in such case, each site should have its own IP address. In a shared hosting environnent, the IP addresses are generally shared through several customers (or domains) , hence the usage of SNI.

Quote from gwr

I know this baviour...

I really have a doubt about that. Else, why you would have be suprised of SSL labs results If you already knew the reason

Quote from gwr

So would be fine to define a splash page for pure IP invoke...

There is already the ServerDefaultPage plugin that was made available for that exact purpose but that will not solve the SSL certificate validity problem as the IP address is not part of SSL certificate subject alternative names and thus, there will always be a SSL certificate name mismatch error raised. Also, we cannot force redirect of SSL to normal HTTP connection in such case because the SSL handstack occurs earlier in the process. You should really consider to learn a bit more

Quote from gwr

Thx

You're welcome.
Thread closed.