proxy_pass not seen as SNI-client according to Apache directive

[Lucas Rolff]

Hi Maxim,

Thank you a lot for the quick reply, I'll give it a test tomorrow morning!

And Robert has a valid point indeed, why is it actually disabled by default?

> Robert Paprocki <mailto:rpaprocki at fearnothingproductions.net>
> 14 February 2016 at 22:46
>
>
> Out of curiosity, is there a philosophical/design reason this option 
> is not enabled by default?
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
> Maxim Dounin <mailto:mdounin at mdounin.ru>
> 14 February 2016 at 21:58
> Hello!
>
>
> http://nginx.org/r/proxy_ssl_server_name
>
> Lucas Rolff <mailto:lucas at slcoding.com>
> 14 February 2016 at 20:14
> Hi guys,
>
> I'm having a rather odd behavior - I use nginx as a reverse proxy 
> (basically as a CDN) - where if the file isn't in cache, I do use 
> proxy_pass to the origin server, to get the file and then cache it.
>
> This works perfectly in most cases, but if the origin is running 
> apache and happen to use the Apache Directive "SSLStrictSNIVHostCheck" 
> where it's set to On.
>
> Basically it decides whether a non-SNI client is allowed to access a 
> name-based virtual host over SSL or not.
> But when using proxy_pass this seems to the apache server that it's a 
> non-SNI client:
> [Sun Feb 14 19:32:50 2016] [error] No hostname was provided via SNI 
> for a name based virtual host
> [Sun Feb 14 19:33:00 2016] [error] No hostname was provided via SNI 
> for a name based virtual host
>
> I was able to replicate this issue on multiple nginx versions (both on 
> 1.8.1, 1.9.9 and 1.9.10).
> It results in 403 forbidden for the client.
>
> If I set the directive SSLStrictSNIVHostCheck to off, I do not get a 
> 403 forbidden - and the files I try to fetch gets fetched correctly. 
> (Meaning proxy_pass do understand SNI).
>
> The nginx zone does a proxy_pass https://my_domain; and the my_domain 
> is running on a server that runs SNI.
>
> Best Regards,
> Lucas Rolff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160214/23e4a724/attachment.html>