У меня apache работает на одной машине в качестве балансировщика нагрузки:
<VirtualHost *:443>
ServerName ssl.example.com
DocumentRoot /home/example/public
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/example.crt
SSLCertificateKeyFile /etc/pki/tls/private/example.key
<Proxy balancer://myappcluster>
BalancerMember http://app1.example.com:12345 route=app1
BalancerMember http://app2.example.com:12345 route=app2
</Proxy>
ProxyPass / balancer://myappcluster/ stickysession=_myapp_session
ProxyPassReverse / balancer://myappcluster/
</VirtualHost>
Обратите внимание, что балансировщик принимает запросы через SSL-порт 443, но затем обменивается данными с участниками балансировщика на не-ssl-порте. Возможно ли, чтобы переадресация на участников балансировщика тоже была под SSL?
Если да, то это лучший / рекомендуемый способ?
Если да, нужно ли мне иметь еще один сертификат SSL для каждого участника балансира?
Есть ли SSLProxyEngine
директива имеет к этому какое-то отношение?
Да, вы на правильном пути. Вы захотите настроить прослушиватель SSL на своих внутренних устройствах.
Для них вам понадобятся сертификаты, но они, вероятно, могут быть просто самозаверяющими - если вы не установите SSLProxyVerify
команда, Apache не заботится об их аутентификации (конечно, вы можете проверить ее, если захотите)
И да, установите SSLProxyEngine on
и измените свой ProxyPass
директивы https
и правильный новый порт.
Я обнаружил, что если вы балансируете SSL с не-SSL Tomcat, то приложение Tomcat получает базовый набор для URL-адреса, отличного от SSL, что, похоже, вызывает проблемы со смесью содержимого SSL и не-SSL. Передача SSL на SSL Tomcat работает нормально.
Вы не хотите этого делать. Балансировщик Apache HTTPD должен работать в той же локальной сети, что и Tomcats, поэтому SSL не требуется, и в любом случае Apache HTTP должен быть конечной точкой SSL для клиента, а также доверенной конечной точкой SSL для Tomcat. Во второй части нет смысла.
Вы можете настроить Apache HTTPD SSL, чтобы передавать клиентские сертификаты и т. Д. Через AJP, чтобы ваше веб-приложение не могло фактически сказать, что это не SSL, и степень, в которой вы можете настроить SSL вплоть до уровня каталога в Apache HTTPD в любом случае делает его гораздо лучшим местом для обработки конфигурации SSL.