Назад | Перейти на главную страницу

Реализуйте HTTPS с помощью pfSense, Varnish и Tomcat

Ситуация

У меня есть сервер ESXi, на котором размещено несколько виртуальных машин, в том числе по одной для каждого pfSense, Varnish и Tomcat. Они настроены следующим образом:

  1. pfSenseVM (Брандмауэр, IP = 10.0.0.1)

    • Правила NAT с порта 80 на VarnishVM:80 и порт 443 на VarnishVM:443
    • webConfigurator прослушивает порт 443
    • webConfigurator недоступен извне
    • установил сертификат SSL по умолчанию с CN=Common Name (eg, YOUR name) под Система > Cert Manager
  2. VarnishVM (Прокси, IP = 10.0.0.2)

    • Направляет запросы для my.domain.com:443 на бэкэнд Tomcat:8443
  3. TomcatVM (Сервер приложений, IP = 10.0.0.3)

    • соединитель в server.xml слушает порт 8443
    • самоподписанный сертификат, перенесенный в хранилище ключей, используемое вышеуказанным соединителем
    • самоподписанный сертификат имеет ЦС CN=*.domain.com

Проблема

Кажется, я получаю не тот сертификат (CN=Common Name (eg, YOUR name)).

Почему я получаю неправильный сертификат? Я могу только предположить, что мне нужно настроить webConfigurator из pfSense для прослушивания на другом порту. Если это правильно, как мне это сделать?

ОБНОВИТЬ

Теперь у меня есть экземпляр Pound (PoundVM) и заставил webConfigurator работать на другом порту.

Это все еще не работает. 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.