Weblogic убивает конфигурацию SSL CXF?

Хорошее время!

Я создал простой клиент CXF для связи с удаленной службой, защищенной SSL. Если я запускаю тест JUnit, рукопожатие выполняется без ошибок, и связь проходит нормально.

<http:conduit name="<service_namespace_port>.http-conduit">
   <http:client AutoRedirect="true" Connection="Keep-Alive"/>
   <http:tlsClientParameters secureSocketProtocol="SSL" disableCNCheck="true">
    <sec:keyManagers keyPassword="pass">
        <sec:keyStore type="JKS" password="pass" file="keystore"/>
    </sec:keyManagers>
    <sec:trustManagers>
        <sec:keyStore type="JKS" password="pass" file="truststore"/>
    </sec:trustManagers>
    <sec:cipherSuitesFilter>
        <sec:include>.*_EXPORT_.*</sec:include>
        <sec:include>.*_EXPORT1024_.*</sec:include>
        <sec:include>.*_WITH_DES_.*</sec:include>
        <sec:include>.*_WITH_AES_.*</sec:include>
        <sec:include>.*_WITH_NULL_.*</sec:include>
        <sec:exclude>.*_DH_anon_.*</sec:exclude>
    </sec:cipherSuitesFilter>
</http:tlsClientParameters>

If I deploy my application on a Weblogic Server (11g) and perform a request, the handshake fails with the error "unable to find valid certification path to requested target". According to the logs got by the "-Djavax.net.debug=all", the problem is Weblogic gets its java cacert (/jre/lib/security) ignoring the configured CXF client's truststore.

Я пытался написать строку <package-name>javax.jws.*</package-name> в файле weblogic-application.xml, но это убивает приложение с ошибкой "org.springframework.beans.MethodInvocationException: свойство 'serviceClass' вызвало исключение; вложенным исключением является java.lang.NoClassDefFoundError: javax/jws/веб-сервис".

Может кто-нибудь, пожалуйста, подскажите, как запретить weblogic участвовать в обмене сообщениями clent-сервер?

ИЗМЕНИТЬ. Это полная конфигурация клиента (Spring-CXF):

<http:conduit name="<service_namespace_port>.http-conduit">
        <http:client AutoRedirect="true" Connection="Keep-Alive"/>
        <http:tlsClientParameters secureSocketProtocol="SSL" disableCNCheck="true">
            <sec:keyManagers keyPassword="pass">
                <sec:keyStore type="JKS" password="pass" file="keystore"/>
            </sec:keyManagers>
            <sec:trustManagers>
                <sec:keyStore type="JKS" password="pass" file="truststore"/>
            </sec:trustManagers>
            <sec:cipherSuitesFilter>
                <sec:include>.*_EXPORT_.*</sec:include>
                <sec:include>.*_EXPORT1024_.*</sec:include>
                <sec:include>.*_WITH_DES_.*</sec:include>
                <sec:include>.*_WITH_AES_.*</sec:include>
                <sec:include>.*_WITH_NULL_.*</sec:include>
                <sec:exclude>.*_DH_anon_.*</sec:exclude>
            </sec:cipherSuitesFilter>
        </http:tlsClientParameters>
    </http:conduit>

    <jaxws:client id="service"
                  serviceClass="foo.bar.ServiceClass"
                  address="<service_url>" />
    <bean id="client" class="foo.bar.ClientClass"/>

ИЗМЕНИТЬ. Согласно этому сообщению, я изменил <http:conduit name="<service_namespace_port>.http-conduit"> на <http:conduit name="*.http-conduit">, и теперь я получаю сообщение об ошибке "вложенное исключение java.lang.RuntimeException: невозможно создать безопасный XMLInputFactory". Некоторое время назад у меня была эта ошибка, и решение, которое я нашел, это с использованием системное свойство. Но больше не подходит... Кто-нибудь знает, как это исправить?


java cxf weblogic11g
person Dmitry    schedule 09.07.2013    source источник
comment
Вы проверили конкретную конфигурацию сервера для веб-логики на веб-сайте Apache CXF? cxf.apache.org/docs/   -  person Cristian Meneses    schedule 09.07.2013
comment
Да, и как я писал в вопросе, такая конфигурация убивает деплоймент. Пожалуйста, посмотрите абзац со строкой javax.jws.*. Вы знаете, как это исправить?   -  person Dmitry    schedule 09.07.2013
comment
Поскольку вы говорите Weblogic предпочитать javax.jws.*packages в вашем EAR/WAR, у вас есть библиотеки JAX-WS, упакованные в ваше приложение?   -  person Cristian Meneses    schedule 09.07.2013
comment
Похоже, что такой библиотеки нет, поскольку она не работает. Но если таких библиотек нет, CXF их не использует. Если это так, он будет содержать их как зависимости, и Maven загрузит их для него, и развертывание не завершится ошибкой. Пожалуйста, поправьте меня, если я ошибаюсь.   -  person Dmitry    schedule 09.07.2013
comment
Я опубликовал ответ на свои выводы, пожалуйста, дайте мне знать, как это происходит, чтобы я мог помочь вам, если вам нужно что-то еще.   -  person Cristian Meneses    schedule 09.07.2013
comment
Спасибо большое, попробую через 5 минут. Не могли бы вы объяснить, зачем нужны эти зависимости (потому что, если я не использую SSL, нет проблем с подключением к удаленному сервису). Я использую CXF 2.7.5   -  person Dmitry    schedule 09.07.2013
comment
Потому что почти все серверы приложений включают в себя собственный стек веб-сервисов с настраиваемыми реализациями по соображениям безопасности и другим вещам. Поскольку вы работаете с предоставленным фреймворком (CXF), в зависимости от поведения загрузчика классов он попытается предоставить отсутствующие зависимости (если таковые имеются) из библиотек сервера приложений, что может привести к такого рода ошибкам. Обычно услуги без ssl не представляют проблем.   -  person Cristian Meneses    schedule 09.07.2013

Ответы (2)


arrow_upward
3
arrow_downward

Наконец, у меня есть решение для обеих проблем.

Прежде всего, я хотел бы поблагодарить Cristian Meneses за действительно полезные ответы!

Далее, пожалуйста, смотрите мой ответ в этот пост для Решение проблемы «Не удается создать безопасный XMLInputFactory». И после этого проверьте этот пост для конфигурации http:conduit имя (в моем случае я использовал такую ​​конструкцию: <http:conduit name="*.http-conduit">). Смешав эту информацию, мне удалось заставить мое приложение работать.

Итак, насколько я понимаю, основная идея заключается в том, что когда WLS соответствует имени канала, он использует настроенные хранилища ключей клиента CXF, но если это не так, он использует cacerts.

СОВЕТЫ ДЛЯ ЧУДЕС: на самом деле нет необходимости (но настоятельно рекомендуется) называть bean-компонент http:conduit так, как указано в официальной документации (моя цель состояла в том, чтобы сделать конечную точку службы настраиваемой). Имя bean-компонента http:conduit является шаблоном для сопоставления имени службы, к которой вы хотите подключиться. Пожалуйста, обратитесь к билет. Существует отличный обходной путь, предоставленный Джейсоном Пеллом.

person Dmitry    schedule 10.07.2013

arrow_upward
0
arrow_downward

Кажется, вам не хватает зависимости.. geronimo-ws-metadata_2.0* (не знаю, какая конкретная версия для вашей версии CXF).

Также в Maven Central эта зависимость, по-видимому, применяется только к cxf-buldle, возможно, поэтому Maven не включил ее для вас...

Кстати, это применимо, если вы продолжаете использовать <package-name>javax.jws.*</package-name>, так как geronimo-ws-metadata_2.0* содержит отсутствующий интерфейс

==================================

Это моя конфигурация, чтобы заставить канал работать

<!-- OVERRIDE DEFAULT TRUSTSTORE, USE BUNDLE TRUSTSTORE INSTEAD -->
<http:conduit name="{http://myWebserviceNamespace/}myWebservicePort.http-conduit">
    <http:tlsClientParameters>
        <sec:trustManagers>
            <sec:keyStore type="JKS" password="myPass"
                 resource="myTrustStore.jks" />
             </sec:trustManagers>
     </http:tlsClientParameters>
</http:conduit>     

<jaxws:client id="myClient"
       serviceClass="com.example.webservice.MyService"
       address="https://path.to/MYSERVICE/services/MyWebservice"/>

Мне пришлось использовать «ресурс» вместо «файл», так как мое хранилище доверенных сертификатов было на пути к классам

person Cristian Meneses    schedule 09.07.2013
comment
Извините, процесс развертывания занял время. Это решение исправило конфигурацию пружины (проблема javax.jws.*), но не решило основную проблему. Weblogic, как и ранее, использует файл jdk1.6.0_45\jre\lib\security\cacerts. - person Dmitry; 09.07.2013
comment
Не могли бы вы опубликовать контекст весны, в котором определен ваш клиент веб-сервиса? Несколько дней назад я боролся с этим на сервере приложений Websphere, может быть, я могу помочь вам с этим. Под основной проблемой вы имеете в виду, что он продолжает использовать хранилище доверенных сертификатов jre/lib/sercurity/cacerts? - person Cristian Meneses; 09.07.2013
comment
Конечно. Пожалуйста, смотрите правку. Основная проблема в том, что Weblogic убивает конфигурацию CXF. - person Dmitry; 09.07.2013
comment
Последнее решение, которое я вижу, это настроить хранилище доверенных сертификатов на Weblogic, но это кажется плохой идеей, потому что после этого я не вижу причин для настройки CXF. - person Dmitry; 09.07.2013
comment
Я добавил свой пример конфигурации, чтобы ответить... Может быть, это поможет - person Cristian Meneses; 09.07.2013