WSO2 ESB Отправить посредник с учетными данными сертификата клиента

У нас есть служба WCF в IIS, которая защищена защитой транспортного средства (SSL) с сертификатами клиента (а не с сообщением WS-Security, но самим IIS). Я добавил сертификат на wso2carbon.jks Всякий раз, когда выполняется отправка посредника, время запроса прерывается. В журнале IIS отображается только ошибка 500.0. Если в конфигурации IIS я решил игнорировать клиентские сертификаты, все работает нормально. Также закодированные клиенты Java Axis2 и .Net отлично работают с включенными сертификатами на ISS.WSO2 ESB Отправить посредник с учетными данными сертификата клиента

Скорее всего, я пропустил что-то в вызове. Требуется ли WS-политика для такого случая? Буду признателен за любую помощь.

источник

2013-03-13 adnecs

Дополнительная информация - похоже, проблема с углеродным транспортом. Проверка проводки всех транспортных средств застряла в рукопожатии в Hello Request Так что сервер отправляет Hello на ESB, и связь застряла. Только CommonsHTTPTransportSender смог завершить рукопожатие с сервером (все равно не отправил сертификат) Так может ли это быть проблемой для пересылок PassThrough и NIO в Carbon? – adnecs

Наконец-то найден обходной путь.

Решение Включить SSLAlwaysNegoClientCert в IIS. Вот хороший пост: Make IIS require SSL client certificate during initial handshake

Причина: IIS по умолчанию будет пересматривать SSL, если клиент обращается к защищенному ресурсу. Транзакции NIO и HttpPathThrough не позволяют пересматривать (что имеет смысл, поскольку это уязвимость системы безопасности). Таким образом, IIS не получает Client Hello и выдает ошибку 500 (для пользователей WSO2, почему клиент TryIt зависает до таймаута?)

Примечание: не всегда мы можем вносить изменения на стороне IIS, поэтому было бы намного лучше, если бы транспорты, доступные в WSO2 ESB, были бы более гибкими, чем позволяли пересматривать (возможно, я пропустил, где его настроить ...)

источник

2013-03-15 05:16:00 adnecs

Приятно слышать, что вы нашли обходной путь для этого. Но вы пытались запустить ESB со следующим дополнительным параметром, -Dsun.security.ssl.allowUnsafeRenegotiation = true (я нашел его в jira, на который вы указали мне). Джира говорит, что она не работает. Но просто хотел проверить, попробовали ли вы это. –

Thx. Этот параметр работает только с транспортом Core Http и не влияет на NIO или транзит. Так что в этом случае это не помогло. – adnecs

Я посмотрел дальше и обнаружил, что проблема все еще существует. Команда WSO2 ESB знает об этом, и это в их дорожной карте исправлено правильно. Они также предложили использовать посредник CallOut в качестве обходного пути для этого. –

В этом случае WSO2 ESB действует как клиент. Поэтому вам нужно импортировать сертификат в client-truststore.jks, который находится в папке репозитория/ресурсов/безопасности WSO2 ESB. Тогда ваш служебный вызов должен работать.

источник

2013-03-14 06:14:02

Да, это должно быть в client-truststore.jks. Вы можете включить SSL debugginh в ESB и посмотреть, что пойдет не так в тот момент в ESB. Есть ресурсы, которые объяснят, как включить журналы отладки SSL. –

От всей отладки, похоже, проблема заключается в том, что оба транспорта PassThrough и NIO https не поддерживают (ошибка?) Пересмотр SSL. Когда клиент отправляет запрос на серверный сервер с запросом на возврат сертификата, отправляя запрос Hello. Клинт не отвечает и все застревает. Транзакт основного HTTP завершает перезаключение. Обнаружена ошибка, открытая вами wso2.org/jira/browse/CARBON-11041 Кажется, что это связано. Могли ли вы решить проблему? Это действительно блокирующий процесс для нас, поэтому я буду очень благодарен за помощь. – adnecs

WSO2 ESB Отправить посредник с учетными данными сертификата клиента

ответ

Смежные вопросы