<div dir="ltr">There's no "nice" way to handle this in nginx as far as I'm aware. I think the best setup is a default vhost with a generic (server hostname?) certificate, and for any bots or clients that ignore the common name mismatch you can return the 421 Misdirected Request code.<div><br></div><div><a href="https://httpstatuses.com/421">https://httpstatuses.com/421</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 29, 2016 at 9:28 AM, Lukas Tribus <span dir="ltr"><<a href="mailto:luky-37@hotmail.com" target="_blank">luky-37@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> > Any real life experience and evidence backing this?<br>
> yes<br>
<br>
</span>Care to elaborate?<br>
<span class=""><br>
<br>
<br>
> Not sure why you're doubting me here Lukas. Yes, this is a problem. No<br>
> I'm not making it up.<br>
<br>
</span>We know that crawlers like Googlebot try HTTPS as well, even if there is no<br>
https link towards the website. That is well known information and publicly<br>
documented.<br>
<br>
What I don't see is why and how that would be a problem, even when HTTPS<br>
is not properly setup for that particular domain.<br>
<br>
Does it cause warnings in the webmaster tools? Who cares?<br>
Does it affect your ranking? I doubt it.<br>
Does it index pages or error pages from the default website and assign to<br>
your website? I doubt that even more.<br>
<span class=""><br>
<br>
<br>
> As such, an incorrect or missing cert will fail, and a missing<br>
> https server block will be handled by the default one ( or the one<br>
> alphabetically first if not set ).<br>
<br>
</span>So serving a 403 or returning 444 from the default block should be fine.<br>
<span class=""><br>
<br>
<br>
> it didn't occur to me that search engines would be attempting<br>
> to force https.<br>
<br>
</span>Just because they attempt to use HTTPS doesn't mean the fail to handle<br>
the case where HTTPS is not properly setup for this particular website.<br>
<br>
<br>
<br>
The way to properly deal with this would be to abort the TLS handshake.<br>
Haproxy can do this with the strict-sni directive, but nginx does not support<br>
that.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
Lukas<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br></div>