Affects soitoolkit-encryption-web-tool-0.6.1-M4 (SSL was introduced in issue
329, r2019).
Problem found on Mule-3.4.0, java version "1.7.0_51" (64 bit), windows server
2008R2.
Problem description
=============
When the soitoolkit-encryption-web-tool is deployed as in hte supplied
readme-file, the truststore configured in:
soitoolkit-encryption-web-tool-common.xml
<jetty:tls-server path="${HTTPS_TLS_TRUSTSTORE}" storePassword="${HTTPS_TLS_TRUSTSTORE_PASSWORD}"/>
is being set on the whole Mule-container.
This can be observed by inspecting system-properties (if the app is already
deployed when the container starts) where system-property
"javax.net.ssl.trustStore" is being set to ${HTTPS_TLS_TRUSTSTORE} from the
config above.
This has serious effects on other applications that rely on the Java default
truststore:
jdk1.7.0_51\jre\lib\security\cacerts
CA-certs can no longer be resolved against the default truststore resulting in
errors for other apps like:
---
CauseException: sun.security.validator.ValidatorException: PKIX path building
failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1884)
---
Proposed solution
============
The encryption-tool shouldn't need it own truststore configured at all, remove:
<jetty:tls-server path="${HTTPS_TLS_TRUSTSTORE}" storePassword="${HTTPS_TLS_TRUSTSTORE_PASSWORD}"/>
from configuration.
Original issue reported on code.google.com by hakan.d...@gmail.com on 14 Feb 2014 at 8:33
Original issue reported on code.google.com by
hakan.d...@gmail.com
on 14 Feb 2014 at 8:33