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).
