Я пытаюсь настроить nginx в качестве интерфейса для IIS 7, чтобы я мог настроить несколько сертификатов SSL с одним IP-адресом, что IIS не поддерживает (шокер).
На мой взгляд, я не нуждаюсь и не должен вмешиваться в уровень HTTP или какие-либо незашифрованные данные, если на то пошло (из-за аутентификации NTLM Exchange, которая привязана к сеансу TCP вместо отдельных запросов). Я должен настроить nginx для обработки только уровня SSL.
К счастью, он поддерживает это! Но, видимо, не с несколькими сертификатами?
В основном это то, что я пытаюсь:
stream {
upstream http_backend {
server 192.168.1.1:80;
}
upstream https_backend {
server 192.168.1.1:443;
}
server {
listen 80;
proxy_pass http_backend;
}
server {
listen 443 ssl;
ssl_certificate certs/default.pem;
ssl_certificate_key certs/default.key;
ssl_certificate certs/domain1.pem;
ssl_certificate_key certs/domain1.key;
ssl_certificate certs/domain2.pem;
ssl_certificate_key certs/domain2.key;
proxy_pass https_backend;
proxy_ssl on;
}
}
В соответствии с документация, ssl_certificate и ssl_certificate_key можно вызывать несколько раз, но для указания сертификатов разных типов, а не для разных доменов. В этом случае последняя пара просто отменяет предыдущие и становится единственным сертификатом, с которым вы договариваетесь при попытке доступа к серверу, независимо от используемого имени хоста.
В stream режим я не могу настроить несколько server записи в том же порту просто меняются server_name как я могу в http режим, по сути server не поддерживает server_name вообще при использовании в stream контекст, поэтому непонятно, как я должен это решить.
Я гуглил весь день и не могу найти решения. Возможно, nginx просто не поддерживает то, что мне нужно? И в каком случае есть альтернатива?
Любые советы приветствуются!
Так что у меня было прозрение, и я сумел решить эту проблему.
Оказывается, вам не нужно настраивать режим SSL или какой-либо сертификат в потоке. server вход, чтобы получить ssl_preread работать, и это дает возможность найти интересный обходной путь.
Я могу настроить несколько server записи о произвольных портах, перечисленных для localhost только, каждый с другим сертификатом и имеет основной server на порт 443, маршрутизирующий входящие соединения на правильный.
Вот базовая конфигурация с 3 сертификатами:
worker_processes 1;
events {
}
stream {
// IIS server
upstream https_backend {
server 10.0.0.1:443;
}
// set up SSL session with the default certificate
upstream default {
server 127.0.0.1:4430;
}
server {
listen 127.0.0.1:4430 ssl;
ssl_certificate certs/default.pem;
ssl_certificate_key certs/default.key;
proxy_ssl on;
proxy_pass https_backend;
}
// set up SSL session with certificate for marvel.com, www.marvel.com
upstream marvel {
server 127.0.0.1:4431;
}
server {
listen 127.0.0.1:4431 ssl;
ssl_certificate certs/marvel.pem;
ssl_certificate_key certs/marvel.key;
proxy_ssl on;
proxy_pass https_backend;
}
// set up SSL session with certificate for dccomics.com, www.dccomics.com
upstream dccomics {
server 127.0.0.1:4432;
}
server {
listen 127.0.0.1:4432 ssl;
ssl_certificate certs/dccomics.pem;
ssl_certificate_key certs/dccomics.key;
proxy_ssl on;
proxy_pass https_backend;
}
// route connection to the tunnel with correct certificate
map $ssl_preread_server_name $upstream {
marvel.com marvel;
www.marvel.com marvel;
dccomics.com dccomics;
www.dccomics.com dccomics;
default default;
}
server {
listen 443;
ssl_preread on;
proxy_pass $upstream;
}
}
Что касается аутентификации SSL и NTLM, это творит чудеса, единственное, чего мне не хватает в этой настройке, - это возможность зарегистрировать реальный IP-адрес пользователя в журналах IIS, поскольку я не могу установить X-Forwarded-For в заголовках HTTP.