Does NGINX support SNI or does it not?

Question

EDIT New question: Can NGINX inspect the TLS request to look for SNI like HAProxy (etc) does?

According to what I've read around (and I've been told), NGINX should not support SNI and I should go for HAProxy for an SSL-transparent reverse proxy. Fine. However, this seems to suggest that NGINX does in fact support SNI, but I can't find a single scrap of useful documentation around. That is, everything I was able to find implied that I still had to provide NGINX with the certificates in order for it to be able to match the request's hostname. But isn't that exactly the problem SNI tries to solve?

Now, I'm starting to run a considerable number of different HTTPS sites on the same IP address, which takes its toll when maintaining the same piece of information across many different configurations, so I'd like to know if I'm better off ditching NGINX and learn yet another software (aka HAProxy) or if I can actually stick to NGINX -- and how.

Ideally, I'd like for the proxy to provide kind of a transparent tunnel for the encrypted traffic, and only the client and the back-end server (say, Apache or whatever other application I'm running) should be able to decrypt it -- meaning that I won't have to keep the certificates information in the reverse proxy's configuration. Meaning that I can go from here

server {
    listen 443 default ssl;

    server_name example.org;
    add_header X-Clacks-Overhead "GNU Terry Pratchett";

    ssl on;
    ssl_certificate         /etc/le_certs/example.org/live/example.org/fullchain.pem;
    ssl_certificate_key     /etc/le_certs/example.org/live/example.org/privkey.pem;

    location / {
        proxy_pass_header   Server;
        proxy_set_header    Host $host;
        proxy_set_header    X-Real-IP $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto $scheme;
        proxy_pass          https://exampleapp;
    }
}

to here

server {
    listen 443 default ssl;

    server_name example.org;
    add_header X-Clacks-Overhead "GNU Terry Pratchett";

    location / {
        proxy_pass_header   Server;
        proxy_set_header    Host $host;
        proxy_set_header    X-Real-IP $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto $scheme;
        proxy_pass          https://exampleapp;
    }
}

with the additional benefit that the proxy's container won't have to have access to the certificates at all (seeing that this is a Docker setup, that's an awful lot of volumes mounted, which results in even more maintenance).

Solution

You misunderstand the "lack" of SNI support.

First, nginx is generally fine for "wildcard" SSL setups. The support issue is in older clients (i.e. browsers), which are not capable of handling SNI.

Comments

[Michael Hampton]

Look into Kubernetes and OpenShift, which among other things give you this functionality for free.

[Morpheu5]

1) Can you point me to the specific bits in the docs? 2) They seem like an overkill for the very specific feature I need. Besides, I'm already using another deployment system, so I'd need a pretty good reason for such an overhaul…

[Morpheu5]

1) What if I don't want wildcard certificates? 2) I don't have a problem with older clients, I can always set up a fallback page – and I'm testing with a recent Chrome which supports SNI. The link you provided show that I still have to insert the ssl_certificate(_key) directive(s) in the server directive for NGINX to be able to look into the request and figure out which backend to proxy. Subsequently, the proxied application needs to access the same certificate, thus I have to configure certificates in two distinct places, one of which should not need to know about them, if SNI worked…

[Colt]

My point is that your issue is about nginx proxies, not about whether nginx supports SNI. Although wildcard is a common way, it might have been better for me to say "multiple" certificates on a single IP address. SNI is only relevant to the ability of the server, under TLS, to be able to resolve server_name example1.com vs. server_name example2.com. Again, the point being that you have asked the question in a manner that assumes the wrong problem, which may limit the help you get.

[Morpheu5]

Ok, so where am I mistaken? Is it not true that the point of SNI is to request the hostname in clear text so that the proxy can match the request to the right backend without needing to decrypt the connection? I think we're saying the same thing, just using different words. My point is again that I thought I should be able to omit the certs/keys from NGINX's config, so that I have one less thing to maintain.

[Colt]

No! Read the whole Wikipedia article I linked to. It explains SNI pretty well. From the article, "SNI [allows] the client [to] send the name of the virtual domain as part of the TLS negotiation," i.e. as part of the secure setup, which "enables the server to select the correct virtual domain early and present the browser with the certificate containing the correct name." This way, in "clients and servers that implement SNI, a server with a single IP address can serve a group of domain names for which it is impractical to get a common certificate." Your issue is not about SNI.

[Morpheu5]

I see, you're right. So how is HAProxy able to deal with that without having access to the certificates? Or what about sniproxy?

[Colt]

And here is where you need to go back to Michael. I was only trying to answer the question you asked, and then desperately trying to get you to forget about SNI and focus on the right question ;) - you might in fact, even try a whole new question, focused on what you want to do, as opposed to what you think is wrong, which might get better attention