AW: SNI and certs.

[Richard Stanway]

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.

https://httpstatuses.com/421

On Tue, Nov 29, 2016 at 9:28 AM, Lukas Tribus <luky-37 at hotmail.com> wrote:

> > > Any real life experience and evidence backing this?
> > yes
>
> Care to elaborate?
>
>
>
> > Not sure why you're doubting me here Lukas. Yes, this is a problem. No
> > I'm not making it up.
>
> We know that crawlers like Googlebot try HTTPS as well, even if there is no
> https link towards the website. That is well known information and publicly
> documented.
>
> What I don't see is why and how that would be a problem, even when HTTPS
> is not properly setup for that particular domain.
>
> Does it cause warnings in the webmaster tools? Who cares?
> Does it affect your ranking? I doubt it.
> Does it index pages or error pages from the default website and assign to
> your website? I doubt that even more.
>
>
>
> > As such, an incorrect or missing cert will fail, and a missing
> > https server block will be handled by the default one ( or the one
> > alphabetically first if not set ).
>
> So serving a 403 or returning 444 from the default block should be fine.
>
>
>
> > it didn't occur to me that search engines would be attempting
> > to force https.
>
> Just because they attempt to use HTTPS doesn't mean the fail to handle
> the case where HTTPS is not properly setup for this particular website.
>
>
>
> The way to properly deal with this would be to abort the TLS handshake.
> Haproxy can do this with the strict-sni directive, but nginx does not
> support
> that.
>
>
>
> Lukas
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20161129/01cc8f56/attachment.html>