Bug 780059 (SOA-2424) - Truststore configuration does not work properly for HttpClientFactory
Summary: Truststore configuration does not work properly for HttpClientFactory
Keywords:
Status: CLOSED NEXTRELEASE
Alias: SOA-2424
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBossESB
Version: 5.1.0.ER2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 5.1.0 GA
Assignee: Kevin Conner
QA Contact:
URL: http://jira.jboss.org/jira/browse/SOA...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-14 10:35 UTC by Jiri Pechanec
Modified: 2011-02-17 09:01 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-02-17 09:01:32 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
wsp.zip (20.98 KB, application/zip)
2010-10-14 10:35 UTC, Jiri Pechanec
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker SOA-2424 0 Major Closed Truststore configuration does not work properly for HttpClientFactory 2014-05-28 12:24:30 UTC

Description Jiri Pechanec 2010-10-14 10:35:01 UTC
project_key: SOA

The attached test case is based on webservice_proxy_security

1) Configure httpclient-8443.properties to point to the keystore included
2) COnfigure serv.xml in jbossweb.sar to use the keystore
3) Start server
4) ant deploy
5) ant runtest
Exception is thrown
     [java] 12:27:24,945 DEBUG [main][content] >> "<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:hello="http://webservice_proxy_security/helloworld"><soapenv:Header/><soapenv:Body><hello:sayHello><toWhom>jpechane</toWhom></hello:sayHello></soapenv:Body></soapenv:Envelope>"
     [java] Exception in thread "main" 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
     [java] 	at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
     [java] 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1611)
     [java] 	at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:187)
     [java] 	at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:181)
     [java] 	at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1035)
     [java] 	at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:124)
     [java] 	at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516)
     [java] 	at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454)
     [java] 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
     [java] 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1112)
     [java] 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:623)
     [java] 	at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
     [java] 	at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
     [java] 	at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
     [java] 	at java.io.FilterOutputStream.flush(FilterOutputStream.java:123)
     [java] 	at org.apache.commons.httpclient.methods.StringRequestEntity.writeRequest(StringRequestEntity.java:150)
     [java] 	at org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:495)
     [java] 	at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973)
     [java] 	at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
     [java] 	at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:397)
     [java] 	at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
     [java] 	at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
     [java] 	at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324)
     [java] 	at org.jboss.soa.esb.samples.quickstart.webservice_proxy_security.test.SendWSMessage.main(SendWSMessage.java:89)
     [java] Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
     [java] 	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:285)
     [java] 	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:191)
     [java] 	at sun.security.validator.Validator.validate(Validator.java:218)
     [java] 	at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:126)
     [java] 	at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:209)
     [java] 	at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:249)
     [java] 	at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1014)
     [java] 	... 19 more
     [java] Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
     [java] 	at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:174)
     [java] 	at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238)
     [java] 	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:280)
     [java] 	... 25 more

6) Uncomment two sysproperty in runinternal target at build XML and set them to point to the keystore
7) ant runtest

Now the execution should be finished without problems. Thus it seems that local truststore config are ignored.

Comment 1 Jiri Pechanec 2010-10-14 10:35:29 UTC
Attachment: Added: wsp.zip


Comment 2 Kevin Conner 2010-10-15 05:22:00 UTC
There are a couple of issues to be addressed

- The defined protocol is never used, which means that the socket factory will always use the factory associated with the default Protocol instance
- The protocol socket factory builders cannot retrieve an encrypted password from a file

Comment 3 Kevin Conner 2010-10-15 05:27:14 UTC
Link: Added: This issue depends JBESB-3504


Comment 4 Kevin Conner 2010-10-15 05:29:43 UTC
Link: Added: This issue depends JBESB-3505


Comment 5 Laura Bailey 2010-12-17 00:41:32 UTC
Writer: Added: Darrin


Comment 6 Laura Bailey 2010-12-17 00:48:00 UTC
Release Notes Docs Status: Added: Not Yet Documented


Comment 8 Jiri Pechanec 2011-01-11 11:00:41 UTC
Verified in ER6

Comment 9 Dana Mison 2011-02-17 09:01:32 UTC
Release Notes Docs Status: Removed: Not Yet Documented Added: Documented as Resolved Issue
Release Notes Text: Added: Truststore configuration in HttpClientFactory did not work correctly.  There were two issues.  Firstly, the defined protocol was never used, meaning that  the socket factory always used the factory associated with the default Protocol instance.  And secondly, the protocol socket factory builder were  unable to retrieve encrypted passwords from a file.  Both of these issues have been resolved and Truststore configuration works correctly in HttpClientfactory.



Note You need to log in before you can comment on or make changes to this bug.