[BlueOnyx:21020] Re: Let's Encrypt Certificate #2 MISMATCH - it's normal

[Felix Kaegi]

Hi Michael

Well spotted and explained. 

In my case it is the SSL Server tests showing Certificate #2 MISMATCH that
distracted me from the real problem I faced, namely "Not Secure" links on
the SSL protected sites. 

For example, a not secure link to the stylesheet, like <link
href="http://www.domain.tld/styles.css" rel="stylesheet" type="text/css" />
can create havoc with the site appearance. The link must explicitly point to
https and not just http. Same for images, it is necessary to link to https
explicitly.

Having fixed the not secure links, going now to that Vsite via HTTPS in the
browser no errors appear anymore (and clicking on the cert information it
shows that the SSL cert with the FQDN of the Vsite I'm visiting is being
used for this visit). However, an SSL Server test on
https://www.ssllabs.com/ssltest/ will still show a Certificate #2 MISMATCH,
which I now happily ignore. :)

Like you wrote: All in all, it's fine and working as intended.

Thanks.

Best regards
Felix



-----Original Message-----
From: Blueonyx [mailto:blueonyx-bounces at mail.blueonyx.it] On Behalf Of
Michael Stauber
Sent: Saturday, May 6, 2017 00:52
To: BlueOnyx General Mailing List <blueonyx at mail.blueonyx.it>
Subject: [BlueOnyx:21017] Re: Let's Encrypt Certificate #2 MISMATCH - it's
normal

Hi Tobias and all,

> at my installation it makes no difference at all.

I looked a bit further and this is expected behaviour during an SSL
connection to a Vsite where SSL runs via SNI:

https://de.wikipedia.org/wiki/Server_Name_Indication

This page goes a bit into technical details about it, but ignore everything
on it but the graphic, as we're talking Apache and not Zimbra. The
principles are the same, though:

https://wiki.zimbra.com/wiki/Multiple_SSL_Certificates,_Server_Name_Indicati
on_(SNI)_for_HTTPS

The point being: BlueOnyx Apache 2.2 (5207R/5208R) and 2.4 (5209R) supports
SSL for Vsites via SNI, so that we no longer need one IP per SSL enabled
Vsite.

But this also means: During the communication the "default SSL" cert (for
the server) might be presented to diagnostic tools such as SSLlabs test
suite. Once the client <-> server connection has negotiated that both sides
support SNI the connection use the SNI SSL cert of the actual Vsite.

And you can see that it works when you go to the Vsite via HTTPS in your
browser and click on the cert information. It'll show that the SSL cert with
the FQDN of the Vsite you're visiting is being used for this visit.

So all in all? It's fine and working as intended.

--
With best regards

Michael Stauber
_______________________________________________
Blueonyx mailing list
Blueonyx at mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx