Различия в хранилище доверенных сертификатов Java между Windows 7 и Solaris (Mule 3.3)

У меня есть два модуля, которые я бы предпочел запускать в одной JVM. Оба используют Mule 3.3, и оба должны устанавливать https-подключения к определенным внешним службам.

Модуль A использует специальный коннектор https:

<https:connector name="proxiedHttpsConnector">
    <spring:property name="proxyHostname" value="${feeds.proxy.server}"/>
    <spring:property name="proxyPort" value="${feeds.proxy.port}"/>
    <https:tls-server path="security/modulea_store" storePassword="thesecretpassowrd"/>
</https:connector>

Модуль B использует сторонний код, использующий com.sun.jersey.client.apache.ApacheHttpClient (v 1.6). Модуль B был модифицирован для работы через тот же прокси.

При тестировании модуля B в Windows 7 с использованием jdk1.6.0_27 я получаю следующее исключение:

ERROR 2012-05-09 10:02:39,585 [VideoAvailable.stage1.02] org.mule.exception.DefaultMessagingExceptionStrategy: 
********************************************************************************
Message               : Component that caused exception is: DefaultJavaComponent{VideoAvailable.commponent.414853995}. Message payload is of type: VideoEvent
Code                  : MULE_ERROR--2
--------------------------------------------------------------------------------
Exception stack is:
1. unable to find valid certification path to requested target (sun.security.provider.certpath.SunCertPathBuilderException)
  sun.security.provider.certpath.SunCertPathBuilder:174 (null)
2. PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target (sun.security.validator.ValidatorException)
  sun.security.validator.PKIXValidator:323 (null)
3. sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target (javax.net.ssl.SSLHandshakeException)
  com.sun.net.ssl.internal.ssl.Alerts:174 (http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/net/ssl/SSLHandshakeException.html)
4. javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target (com.sun.jersey.api.client.ClientHandlerException)
  com.sun.jersey.client.apache.DefaultApacheHttpMethodExecutor:213 (null)
5. Component that caused exception is: DefaultJavaComponent{VideoAvailable.commponent.414853995}. Message payload is of type: VideoEvent (org.mule.component.ComponentException)
  org.mule.component.DefaultComponentLifecycleAdapter:359 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/component/ComponentException.html)
--------------------------------------------------------------------------------
Root Exception stack trace:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:174)
    at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238)
    at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:318)
    + 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything)
********************************************************************************

Я могу добавить сертификат для подключения к удаленной службе модуля B в хранилище доверенных сертификатов модуля A, и оба модуля отлично работают в Windows 7.

Запуск той же конфигурации в SunOS 5.10 с jre 1.6.0_06 (я знаю, что она старая) приводит к следующей ошибке:

2012/05/08 17:42:32 | ERROR 2012-05-08 17:42:32,265 [VideoAvailable.stage1.04] org.mule.exception.DefaultMessagingExceptionStrategy: 
2012/05/08 17:42:32 | ********************************************************************************
2012/05/08 17:42:32 | Message               : Component that caused exception is: DefaultJavaComponent{VideoAvailable.commponent.6015177}. Message payload is of type: VideoEvent
2012/05/08 17:42:32 | Code                  : MULE_ERROR--2
2012/05/08 17:42:32 | --------------------------------------------------------------------------------
2012/05/08 17:42:32 | Exception stack is:
2012/05/08 17:42:32 | 1. the trustAnchors parameter must be non-empty (java.security.InvalidAlgorithmParameterException)
2012/05/08 17:42:32 |   java.security.cert.PKIXParameters:183 (null)
2012/05/08 17:42:32 | 2. Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty (java.lang.RuntimeException)
2012/05/08 17:42:32 |   sun.security.validator.PKIXValidator:59 (null)
2012/05/08 17:42:32 | 3. java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty (javax.net.ssl.SSLException)
2012/05/08 17:42:32 |   com.sun.net.ssl.internal.ssl.Alerts:190 (http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/net/ssl/SSLException.html)
2012/05/08 17:42:32 | 4. javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty (com.sun.jersey.api.client.ClientHandlerException)
2012/05/08 17:42:32 |   com.sun.jersey.client.apache.DefaultApacheHttpMethodExecutor:213 (null)
2012/05/08 17:42:32 | 5. Component that caused exception is: DefaultJavaComponent{VideoAvailable.commponent.6015177}. Message payload is of type: VideoEvent (org.mule.component.ComponentException)
2012/05/08 17:42:32 |   org.mule.component.DefaultComponentLifecycleAdapter:359 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/component/ComponentException.html)
2012/05/08 17:42:32 | --------------------------------------------------------------------------------
2012/05/08 17:42:32 | Root Exception stack trace:
2012/05/08 17:42:32 | java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
2012/05/08 17:42:32 |   at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:183)
2012/05/08 17:42:32 |   at java.security.cert.PKIXParameters.<init>(PKIXParameters.java:103)
2012/05/08 17:42:32 |   at java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:87)
2012/05/08 17:42:32 |     + 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything)
2012/05/08 17:42:32 | ********************************************************************************

Оба отлично работают независимо на Windows 7 и SunOS. Оба прекрасно работают вместе в Windows 7. Оба несовместимы с SunOS. Кроме того, добавление сертификата, необходимого для модуля B, в /NFL/ESB/apps/jdk1.6.0_06/jre/lib/security/cacerts и отказ от Mule не помогли. Я также попытался настроить свой Windows 7 JDK, чтобы он указывал на копию cacerts SunOS (по умолчанию), и это не воспроизводило ошибку Sun.


java mule truststore
person nflearl    schedule 09.05.2012    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Возможно ли, что вы использовали «\» в качестве разделителя пути, что привело к сбою в SunOS?

person Raymond Tau    schedule 24.05.2012
comment
Цените комментарий, в SunOS нет \s ни на одном пути. Кроме того, я попробовал более свежую версию JDK на коробке SunOS, и поведение было таким же. Основная проблема заключается в том, что хранилище доверенных сертификатов по умолчанию инициализируется по-разному в Windows 7 и SunOS при запуске обоих модулей. - person nflearl; 24.05.2012

arrow_upward
0
arrow_downward

Мне удалось перенастроить модуль A для использования хранилища доверия по умолчанию:

<https:connector name="proxiedHttpsConnector"
     http:proxyHostname="${feeds.proxy.server}"
     http:proxyPort="${feeds.proxy.port}"/>

что затем позволяет обоим модулям работать вместе.

С точки зрения основной цели это работает отлично. Я никогда полностью не распутывал различные пути инициализации хранилища доверия между Windows 7 и Solaris, но потратил достаточно времени на эту проблему, и мне нужно двигаться дальше.

person nflearl    schedule 30.05.2012