Ситуация
У меня есть сервер ESXi, на котором размещено несколько виртуальных машин, в том числе по одной для каждого pfSense, Varnish и Tomcat. Они настроены следующим образом:
pfSenseVM
(Брандмауэр, IP = 10.0.0.1)
VarnishVM:80
и порт 443 на VarnishVM:443
CN=Common Name (eg, YOUR name)
под Система > Cert ManagerVarnishVM
(Прокси, IP = 10.0.0.2)
my.domain.com:443
на бэкэнд Tomcat:8443
TomcatVM
(Сервер приложений, IP = 10.0.0.3)
server.xml
слушает порт 8443CN=*.domain.com
Проблема
Кажется, я получаю не тот сертификат (CN=Common Name (eg, YOUR name)
).
https://my.domain.com
в браузере он продолжает загружаться, и после нескольких попыток я вижу в Firebug, что запрос был прерван. Журнал лака показывает тайм-аут.wget https://my.domain.com
из TomcatVM
, полученный сертификат тот, что установлен в pfSense и не работает из-за сертификатов » CN
. Я считаю, что это ключ.wget https://localhost:8443
из TomcatVM
, полученный сертификат тот, который установлен в хранилище ключей Java, что правильно, но явно не работает, потому что localhost
не совпадает *.domain.com
Почему я получаю неправильный сертификат? Я могу только предположить, что мне нужно настроить webConfigurator из pfSense для прослушивания на другом порту. Если это правильно, как мне это сделать?
ОБНОВИТЬ
Теперь у меня есть экземпляр Pound (PoundVM
) и заставил webConfigurator работать на другом порту.
PoundVM:443
(замена тот, кто VarnishVM:443
PoundVM
(IP = 10.0.0.4) Это все еще не работает. Firebug по-прежнему показывает «Прервано», и я не вижу сообщений журнала от Pound.
Следует также отметить, что (самоподписанный) сертификат был создан на TomcatVM
используя OpenSSL (как .crt) и импортированный в хранилище ключей Java. Затем я скопировал это и закрытый ключ в PoundVM
и создал файл .pem, используя это руководство. В Cert
ценность в Конфигурация фунта указывает на этот файл. Это правильно?
ОБНОВЛЕНИЕ 2
Я сделал ошибку копирования и вставки в Конфигурация фунта, адрес, который прослушивает прослушиватель HTTPS, теперь 10.0.0.4 вместо 127.0.0.1, и к Pound можно получить доступ извне. Теперь он дает мне HTTP 414: Request URI too long, хотя запрашиваемый URI составляет около 200 символов. Я обнаружил, что могу настроить MAXBUF
при составлении фунт. Но я установил его с помощью apt ... Тем не менее, я нахожу 414 странным, потому что URI https://my.domain.com/some/path/that/is/ surely/not/1024/bytes/long
ОБНОВЛЕНИЕ 3
Теперь он работает, перенаправляя на HTTP-порт Tomcat вместо HTTPS. Паунд для меня новичок, и я подумал, что могу перенаправить зашифрованный запрос на Tomcat.
webConfigurator находится на порту 443, как и ваш NAT. Вы не можете получить и то, и другое. Вы упомянули, что перемещение webConfigurator по-прежнему не позволяет этому работать; Я предполагаю, что в pfSense есть особая магия, примененная к порту 443 для ограничения доступа администратора. Вы можете либо отключить эту магию, либо сделать много более простой вариант и запустите NAT для другого порта или другого IP. Из двух, отдельный порт, наверное, намного проще. Допустим, вы выбрали 8443 (для согласованности с сервером Tomcat). Затем вы получите доступ к сайту с помощью https://my.domain.com:8443.
Теперь, все, что было сказано, вы не объяснили, как вы здесь декодируете SSL. Varnish не работает с SSL-трафиком. Таким образом, даже если вы заставите это работать, это ... не будет работать. Поэтому вам нужно либо немного дополнить свое объяснение, либо переосмыслить / отказаться от использования Varnish. Одним из распространенных решений, которые я видел, является использование выделенного прокси-сервера для декодирования SSL, например Фунт, перед лаком.
См. Также "Почему нет SSL"FAQ на сайте Varnish.