Как бы вы настроить SSL от конца до конца с WebLogic через Netscaler
Новичок в Weblogic и Netscaler нужна помощь с архитектурой
Я хочу предоставить сервис на веб-логике Интернету, чтобы мобильные пользователи могли получить доступ к веб-сервису. В настоящее время внутренний трафик работает нормально, когда пользователи получают прямой доступ к сайту, например http://xxx.internal.local:7001
мне нужно иметь включенный SSL сквозной как для внутренних пользователей, так и для внешних пользователей, а также возможность доступа к веб-сервису извне и внутри
Транспортный поток
- Внешний пользователь |||| <- HTTPS ->|||| NetScaler|||| <- HTTPS -> веблогический сервер
- Внутренние пользователи подключаются напрямую к weblogic
- Внутренние пользователи будут использовать
https://xxx.internal.local:7002- (Частный DNS и IP-адрес)
- Внешние пользователи будут использовать
https://xxx.external.com:443- (Общедоступный DNS и IP-адрес)
SAN Cert (имеет локальный домен и внешний домен) установлен и импортирован в хранилище ключей Java weblogic.
Каков наилучший способ достичь этого?
Вещи, которые мы пробовали
Администратор Netscaler, конфигурирующий SSL Пройти через Netscaler - например, не расшифровывать и не перешифровывать, и перенаправлять порт 443 на 7002
Настройка CNAME во внутреннем DNS для указания xxx.external.com на xxx.internal.local
- внутренний трафик в
https://xxx.internal.local:7002был в порядке и зашифрован - Сбой внешнего трафика и ошибки Cert, представленные пользователям
Мне неясно, как это должно быть настроено с использованием внешнего домена и внутреннего домена вместе с Netscaler, выполняющим мост SSL - есть ли лучший способ сделать это - например, иметь разгрузку SSL Netscaler на VIP и повторно зашифровать обратно в weblogic и изменить Заголовки узла HTTP, чтобы соответствовать внутреннему имени домена (обратный прокси)
заранее спасибо
4 ответа
Спасибо всем за отзывы. Испытанное рабочее решение было следующим.
Один публично сгенерированный сертификат SAN (с внешним доменом и внутренним доменом в записях SAN) установлен на Netscaler и сервере weblogic
Внешние пользователи будут использовать внешний URL-адрес домена " https://xxx.external.com/". Внешний трафик SSL будет прерван при расшифровке Netscaler и повторном шифровании обратно на внутренний сервер weblogic на порту 7002 .NETscaler также изменит заголовок узла HTTP в запросе на внутреннее имя узла, а также изменит заголовки узла Http- ответа на внешнее имя узла.
Внутренние пользователи будут использовать внутренний URL-адрес домена, например, https://xxx.internal.local:7002/
Провайдеры сертификатов больше не выдают сертификаты с внутренними доменами, так как я понимаю, поэтому это может не сработать для вас. но я думаю обойти эту проблему. Вы можете создать внутренний сертификат CA с внутренним доменным именем. установить на сервере weblogic и netscaler. Купите публично сгенерированный Cert с внешним доменным именем и установите его на Netscaler. поэтому внешний трафик будет использовать публичный сертификат для шифрования трафика, а внутренний трафик будет зашифрован с использованием внутреннего сертификата.
Хотя это старый вопрос, в WebLogic нет особого понимания ответа. Вот мой опыт около 7 лет работы с WebLogic (с Netscaler и без него в качестве бэкэнда).
1) Почему вы выставляете свое приложение на порт 7001 или 7002? Как правило, 7001 и 7002 будут содержать AdminServer, и вы определенно НЕ хотите, чтобы люди могли получить доступ к http::7001/console (или https::7002/console). Порты 7001 и 7002 должны быть доступны только из доверенных (административных) частей вашей сети.
1a) Как правило, если вы используете Oracle Fusion Middleware, приложение будет запускаться на отдельном управляемом сервере, который получает свои собственные порты. Например, Oracle WebCentre Content работает на управляемом сервере с именем UCM_server1, который имеет свои основные сервисные порты 16200 (http) и 16201 (https).
2) Вы действительно должны поместить WebLogic за обратный прокси-сервер для отображения любого типа сайта. Обычно мы использовали либо OHS (версия httpd для Oracle), либо Apache httpd. Затем обычно вы используете weblogic_module внутри httpd для обратного прокси на вашем управляемом сервере WebLogic. (и в его расширенных настройках вы бы установили "Включить модуль WebLogic" (или назвали его так же, я не могу вспомнить его из головы).
2a) Модуль weblogic_module особенно важен (или, скорее, он обеспечивает особенно важные функции при использовании за обратным прокси-сервером). Особенности, такие как знание:
Входил ли трафик по http или https (важно, если приложение хочет создать ссылки / перенаправления и вы хотите избежать таких вещей, как петли перенаправления).
С какого IP-адреса был получен трафик (особенно важно, если используется SSO, в зависимости от того, насколько хороши ваши настройки безопасности)
2b) Большая часть того, что делает модуль weblogic_module, устанавливает конкретные заголовки HTTP-запроса. Включение "Использовать модуль weblogic" в настройках управляемого сервера просто говорит WebLogic "доверять некоторым конкретным заголовкам, которые входят в запросы, и использовать их, чтобы узнать больше о том, откуда поступил трафик и как он поступил в систему".
На самом деле, я бы посоветовал лучше избегать использования weblogic_module, особенно если вы хотите сделать лучший опыт "упс, сайт недоступен" (т. Е. Обработчик 503), не перенаправляя пользователя (изменяя его контекст, чтобы он не мог просто перезагрузите страницу). Просто делайте то же самое, что и weblogic_module - это не очень сложно.
3) Вставьте кеш перед этим (лак, nginx и т. Д.). По моему опыту, вы действительно хотите обслуживать только динамический материал из WebLogic и убедиться, что вы обслуживаете статический контент из чего-то, оптимизированного для этой цели. Не связывайте свои рабочие темы без необходимости; иногда они могут быть дефицитными ресурсами. В зависимости от вашего приложения, вы можете предпочесть иметь что-то, что позволит вам легко управлять такими вещами, как заголовки кэша (потому что некоторые продукты - Oracle WebCentre Content, я смотрю на вас - просто бесполезны, когда дело касается сделать сайт кеш-сайтом без переписывания заголовков Cache-Control).
4) Скорее всего, вы хотите иметь один URL-адрес... иметь разные внутренние и внешние URL-адреса... просто ужасно. Подумайте об использовании таких методов, как DNS с разделенным горизонтом, при котором внутренние клиенты получат один IP-адрес (например, 10.xxx), а внешние клиенты - другой (например, 123.xxx), или просто будут обслуживать все с одного общедоступного IP-адреса. Вы должны иметь один и тот же сертификат SSL на каждом; В противном случае HSTS вполне может дать вам проблемы.
5) Говоря о SSL, я бы предложил вам также использовать самозаверяющие сертификаты (или локально выданные сертификаты, если у вас есть локальный CA) для внутренних устройств (например, серверов WebLogic, таких как AdminServer, а также Nodemanager), и просто иметь CA сертификаты на актуальных веб-руководителей.
6) Если вы используете httpd, я настоятельно рекомендую вам развернуть его с помощью mod_remoteip, так как идея заключается в том, что у вас есть хороший источник журналирования.
У A-Team (они из Oracle - и очень хорошо разбираются в различных продуктах Oracle) есть хороший пост в блоге на тему weblogic_module: разгрузка SSL и сервер WebLogic.
У F5 есть полезное руководство по развертыванию, в котором показано, как настроить обратный прокси-сервер (F5 BigIP в их случае, но все еще актуально для Netscaler или просто httpd), и не нужно использовать weblogic_module.
7) Вы, вероятно, возненавидите меня за то, что я так много думаю о вас... но я говорю вам, все это зависит от опыта... некоторые из которых довольно болезненны.
8) О, и в случае, если вы выполняете свои рабочие нагрузки Java в среде VMWare (которая не предоставляет аппаратный генератор случайных чисел), вы захотите сделать что-то, чтобы гарантировать, что ваше приложение когда-либо использует только / dev / urandom и никогда /dev/random --- найдите все файлы jre/lib/security/java.security и установите securerandom.source=file:/dev/./urandom для обхода очень давно (возможно, где-то окончательно разрешено в Java 8) ошибка, из-за которой он был бы "умным" и заканчивал тем, что использовал / dev / random, делая такие вещи, как запуск, ужасно медленными.
SAN Cert (имеет локальный домен и внешний домен) установлен и импортирован в хранилище ключей Java weblogic.
Это должно означать, что локальный самозаверяющий сертификат, созданный вами как провайдером сертификатов, не разрешит локальный домен в сертификате. Это означает, что он не будет распознаваться внешними браузерами, поскольку они не распознают самозаверяющие сертификаты, созданные вашей компанией. Разве у вас нет выданного извне сертификата подстановочного знака, который, следовательно, работает для обоих?
Администратор Netscaler, конфигурирующий SSL Пройти через Netscaler - например, не расшифровывать и не перешифровывать, и перенаправлять порт 443 на 7002
Это не будет работать по той же причине. Ваш сервер отправит внутренний сертификат обратно с сервера.
иметь netscaler разгрузить SSL на VIP и перешифровать обратно в weblogic и изменить заголовки хоста HTTP, чтобы соответствовать внутреннему имени домена (обратный прокси-сервер)
Это то, что вы должны сделать. Купите сертификат для внешнего домена, а затем используйте внутренне выданный самоподписанный сертификат для внутреннего домена.
В качестве альтернативы используйте одно и то же доменное имя внутри и снаружи, а затем можете использовать один и тот же сертификат на обоих или использовать сквозной. С этой настройкой вы можете иметь внешний DNS, указывающий на LoadBalancer, и внутренний указывать непосредственно на веб-сервер, если хотите.
Вот шаги, чтобы заархивировать это.
Шаг 1: Добавьте IP к netscaler (если у вас более 1 сервера weblogic, добавьте все по одному)
Шаг 2. Создайте сервер, используя внутренний IP-адрес каждого сервера (например, WebLogic_Svc1,WebLogic_Svc2).
Шаг 3: Создайте сервис, используя указанный выше внутренний IP-адрес сервера. (Используйте порт № 7002, где у вас есть, если работоспособен)
Шаг 4: Свяжите сертификат, используемый в WebLogic, с вышеуказанным сервисом.
Шаг 5: Теперь вы можете изменить монитор на использование SSL.(Вы также можете оставить монитор на мониторе tcp по умолчанию. Убедитесь, что port7002 открыт из SNIP для вашего WebLogic, в противном случае сервис будет продолжать показывать вниз).
Шаг 6: Если вы видите WebLogic_Svc1, WebLogic_Svc2 вверх, мы можем перейти к последним двум шагам.
Шаг 7: Создайте LB VServer xxx.external.com с использованием маршрутизируемого общедоступного IP-адреса, который будет размещать и использовать порт #443.
Шаг 8: Привязать общедоступную пару SSL CertKey к вышеуказанному LB Vserver . (Убедитесь, что внешний SSL-сертификат CertKey связан с соответствующим промежуточным и корневым сертификатом. Ваш общедоступный поставщик сертификатов выдаст вам промежуточный и корневой сертификат. Если вы этого не сделаете, ваш общедоступный сертификат все равно не будет признан браузерами подбородком доверия не будет завершено.)
Шаг 9: Свяжите две вышеупомянутые службы с LB VServer xxx.external.com.
Если вышеуказанные шаги слишком сложны для вас, посмотрите следующее видео на YouTube от Andrew (theurbanpenguin)