nginx proxy ssl reverso com múltiplos subdomínios

Question

Estou tentando localizar um exemplo de configuração de alto nível para minha situação atual. Temos um certificado SSL curinga para vários subdomínios que estão em vários servidores IIS internos.

site1.example.com (X.X.X.194) -> IISServer01:8081
site2.example.com (X.X.X.194) -> IISServer01:8082
site3.example.com (X.X.X.194) -> IISServer02:8083

Estou tentando lidar com o tráfego SSL de entrada por meio de uma entrada de servidor e, em seguida, passar o domínio específico para o aplicativo interno do IIS. Parece que tenho duas opções:

1. Codifique uma seção de localização para cada subdomínio (parece confuso com os exemplos que encontrei)

2. Encaminhe o tráfego não criptografado de volta ao mesmo servidor nginx configurado com entradas de servidor diferentes para cada nome de host de subdomínio. (Pelo menos, isso parece ser uma opção).

Meu objetivo final é consolidar grande parte do nosso tráfego SSL para passar pelo nginx, para que possamos usar o HAProxy nos servidores de balanceamento de carga.

Abordará o trabalho # 2 no nginx se eu configurar corretamente as entradas proxy_set_header?

Eu imagino algo nos moldes disso no meu arquivo de configuração final (usando a abordagem # 2):

server {
  listen Y.Y.Y.174:443; #Internally routed IP address
  server_name *.example.com;

  proxy_pass http://Y.Y.Y.174:8081;
}

server {
  listen Y.Y.Y.174:8081;
  server_name site1.example.com;

  -- NORMAL CONFIG ENTRIES --

  proxy_pass http://IISServer01:8081;
}

server {
  listen Y.Y.Y.174:8081;
  server_name site2.example.com;

  -- NORMAL CONFIG ENTRIES --

  proxy_pass http://IISServer01:8082;
}

server {
  listen Y.Y.Y.174:8081;
  server_name site3.example.com;

  -- NORMAL CONFIG ENTRIES --

  proxy_pass http://IISServer02:8083;
}

Isso parece um caminho, mas não tenho certeza se é o melhor caminho. Estou perdendo uma abordagem mais simples para isso?

    

Answer 1

Eu faria algo assim (testado com o nginx 1.4.2, parece funcionar):

server {
  listen 127.0.0.1:443 ssl;
  server_name site1.example.com;

  include common.conf;

  location / {
    proxy_pass http://127.0.0.2:8081;
  }
}

server {
  listen 127.0.0.1:443 ssl;
  server_name site2.example.com;

  include common.conf;

  location / {
    proxy_pass http://127.0.0.2:8082;
  }
}

server {
  listen 127.0.0.1:443 ssl;
  server_name site3.example.com;

  include common.conf;

  location / {
    proxy_pass http://127.0.0.3:8083;
  }
}

Com pelo menos isso em common.conf :

ssl on;
ssl_certificate  /path/to/cert;
ssl_certificate_key  /path/to/key;

    

Answer 2

Acredite ou não, você pode fazer isso:

ssl_session_cache shared:SSL:2m;
ssl_session_timeout 5m;

server {
    listen Y.Y.Y.174:443 default_server ssl;
    server_name _;
    ssl_certificate /etc/pki/tls/certs/server.chained.crt;
    ssl_certificate_key /etc/pki/tls/private/server.key;
}

server {
    listen Y.Y.Y.174:443 ssl;
    server_name site1.example.com;
    [...]
    proxy_pass http://IISServer01:8081;
}

server {
    listen Y.Y.Y.174:443 ssl;
    server_name site2.example.com;
    [...]
    proxy_pass http://IISServer01:8082;
}

server {
    listen Y.Y.Y.174:443 ssl;
    server_name site3.example.com;
    [...]
    proxy_pass http://IISServer02:8083;
}

Sem inclusões, o certificado é carregado na memória apenas uma vez e a sessão deve permanecer armazenada em cache à medida que o usuário passa de subdomínio para subdomínio, poupando-lhe bastante potência de handshake.

Não consigo encontrar nenhuma documentação além esta postagem de falha do servidor para sugerir por que isso funciona, mas posso garantir isso acontece.