EDIT Nouvelle question : NGINX peut-il inspecter la requête TLS pour rechercher le SNI comme le fait HAProxy (etc) ?
D'après ce que j'ai lu autour de moi (et j'ai été a dit à ), NGINX ne devrait pas supporter SNI et je devrais opter pour HAProxy pour un reverse proxy transparent SSL. Bien. Cependant, este semble suggérer que NGINX supporte effectivement SNI, mais je ne trouve pas la moindre trace de documentation utile. En fait, tout ce que j'ai pu trouver impliquait que je devais encore fournir les certificats à NGINX pour qu'il soit capable de faire correspondre le nom d'hôte de la requête. Mais n'est-ce pas exactement le problème que SNI tente de résoudre ?
Je commence à faire tourner un nombre considérable de sites HTTPS différents sur la même adresse IP, ce qui n'est pas sans conséquences lorsqu'il s'agit de maintenir le même élément d'information dans de nombreuses configurations différentes. J'aimerais donc savoir s'il vaut mieux laisser tomber NGINX et apprendre un autre logiciel (alias HAProxy) ou si je peux rester fidèle à NGINX - et comment.
Idéalement, j'aimerais que le proxy fournisse une sorte de tunnel transparent pour le trafic crypté, et que seuls le client et le serveur back-end (disons Apache ou toute autre application que j'exécute) soient en mesure de le décrypter - ce qui signifie que je n'aurai pas à conserver les informations relatives aux certificats dans la configuration du proxy inverse. Ce qui signifie que je peux partir d'ici
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;
}
}pour ici
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;
}
}avec l'avantage supplémentaire que le conteneur du proxy n'aura pas du tout besoin d'avoir accès aux certificats (étant donné qu'il s'agit d'une configuration Docker, cela représente beaucoup de volumes montés, ce qui entraîne encore plus de maintenance).
