Discussion:
HTTPS web service client not working with cxf version 2.6.x and 2.7.x but working fine with version 2.5.x
(too old to reply)
cxf_webservice
2013-09-03 04:26:21 UTC
Permalink
I have been struggling with this scenario where i have a web service client
that i developed using cxf version 2.5.x to connect to the web service
hosted within Data Power using SSL. Everything works fine with the cxf
version 2.5.x. The moment i change to cxf version to 2.6.x or 2.7.x i start
getting handshake failures. I am using 2 way ssl which means that on the
client side i have a truststore which holds the public key of the
certificate installed on the Data power's web service side. Likewise i have
given the public key of the self signed certificate that i have on the
client side and this public key has been installed on the truststore on the
data power side.I have been using programmatic way of enabling SSL and the
relevant code for the web service client is here under:private
ServiceRequestPort getWSPort() { URL wsdlURL =
ServiceRequestService.WSDL_LOCATION; try { wsdlURL
= new
URL("file:/local/app/dhome/apps/quattroCloud/config/ServiceRequestService.wsdl");
} catch (MalformedURLException e) { e.printStackTrace(); }
QName SERVICE_NAME = new
QName("http://www.autodesk.com/ws/ServiceRequest/1.0",
"ServiceRequestService"); ServiceRequestService ss = new
ServiceRequestService(wsdlURL, SERVICE_NAME); ServiceRequestPort
wsPort = ss.getServiceRequest(); SSLContext
sslContext = null; try { sslContext =
getSSLContext("/local/app/dhome/apps/quattroCloud/config/quattroCloud.p12",
"autodesk"); } catch (Exception e) { e.printStackTrace(); }
TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.setSecureSocketProtocol("TLS");
tlsParams.setSSLSocketFactory(sslContext.getSocketFactory()); Client
c = ClientProxy.getClient(wsPort); HTTPConduit conduit = (HTTPConduit)
c.getConduit(); conduit.setTlsClientParameters(tlsParams);
((BindingProvider)wsPort).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
quattroCloudConfig.getTibcowsURL()); return wsPort; }In the above
code the SSLContext is obtained using:private static SSLContext
getSSLContext(String keyStoreFilePath, String pKeyPassword) throws Exception
{ try { SSLContext context = SSLContext.getInstance("TLS");
InputStream keyInput = new FileInputStream(keyStoreFilePath); KeyStore ks
= KeyStore.getInstance("PKCS12"); KeyManagerFactory km =
KeyManagerFactory.getInstance("SunX509"); ks.load(keyInput,
pKeyPassword.toCharArray()); keyInput.close(); km.init(ks,
pKeyPassword.toCharArray()); context.init(km.getKeyManagers(), null, new
SecureRandom()); return context; } catch (Exception e) {
e.printStackTrace(); } return null; }The client side certifcate that i
am using has been created using openssl and are in PKCS12 format, following
commands were used to create the certificate for which the public key has
been shared on data power's side and has been imported within data power's
truststore. Created private key like so: openssl genrsa -out
HOSTNAME-private.pem 2048 Create a self-signed X509 certificate: openssl
req -new -x509 -key HOSTNAME-private.pem -out HOSTNAME-certificate.pem -days
1825Create a PKCS12 keystore and import the host certificate we just
created: openssl pkcs12 -export –out quattroCloud.p12 -in
HOSTNAME-certificate.pem -inkey HOSTNAME-private.pem Every time i
am trying to invoke a webservice operation on the port that is returned from
the getWSPort() when cxf version 2.7.6 is being used i get the follwing
handshake error:0000: 14 03 01 00 01 01
......*** Finishedverify_data: { 14, 134, 102, 9, 242, 17, 92, 21, 186,
202, 96, 1 }***s[write] MD5 and SHA1 hashes: len = 160000: 14 00 00 0C 0E
86 66 09 F2 11 5C 15 BA CA 60 01 ......f...\...`.Padded plaintext before
ENCRYPTION: len = 480000: 14 00 00 0C 0E 86 66 09 F2 11 5C 15 BA CA 60 01
......f...\...`.0010: 39 23 50 C4 45 8A 07 D8 6C 03 86 96 77 EE 4E A4
9#P.E...l...w.N.0020: 40 5A AA 8C 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B
@Z..............tomcat-http-2, WRITE: TLSv1 Handshake, length =
48tomcat-http-2, waiting for close_notify or alert: state 1tomcat-http-2,
Exception while waiting for close java.net.SocketException: Software caused
connection abort: recv failedtomcat-http-2, handling exception:
java.net.SocketException: Software caused connection abort: recv
failedtomcat-http-2, called close()tomcat-http-2, called
closeInternal(true)tomcat-http-2, called closeSocket()Some more observations
from the ssl logs that i have seen are here under:Looking at the logs it’s
clear that the client certificate chain process in 2.5.x is able to send the
client certificate, where as it is not sending the client cert in 2.7.x.
2.5.11*** Certificate chainchain [0] = [[ Version: V3 Subject:
CN=uspetdeccprx001.autodesk.com, OU=EIS Development Team, O=AutodeskInc,
L=San Rafael, ST=California, C=US Signature Algorithm: SHA1withRSA, OID =
1.2.840.113549.1.1.5The same step in 2.7.x is not able to send the client
certificate, which results in the handshake error as the mutual
authentication error.2.7.x*** Certificate chain****** ClientKeyExchange, RSA
PreMasterSecret, TLSv1Another difference is that with 2.5.x cxf runtime we
see certificateVerify step taking place like so:Server write IV:0000: D3 C8
EB C7 93 9E 78 D3 53 E8 6C D8 AE FD F6 F4 ......x.S.l.....***
CertificateVerify[write] MD5 and SHA1 hashes: len = 2620000: 0F 00 01 02 01
00 7B 9E 77 47 57 A1 FE A8 32 37 ........wGW...270010: 3E 1A DA 82 9C 00
BC 03 CD 73 FF 72 16 9E 03 C1 >........s.r....0020: FA B1 C6 F7 0E 20 24
26 47 C5 71 82 4E AB 45 6C ..... $&G.q.N.El0030: DF 23 ED 63 85 38 62 C6
A0 95 DD 0E CE 02 D0 F2 .#.c.8b.........0040: A1 F8 E5 97 30 C0 B3 EC E8
0C 79 19 2B 57 EC 8E ....0.....y.+W..0050: CB 01 50 2A 24 C5 A2 6C F9 1A
DB 5F 94 11 EF D8 ..P*$..l..._....0060: DA 4A 6A 0E 9E 50 C9 C0 FF C6 EA
5F 83 A1 60 00 .Jj..P....._..`.0....where as with 2.7.x case at the same
corresponding step we don't see ***CertificateVerify happening from Client
side instead we see exception getting thrown before the data gets exchanged
via the post request.Server write IV:0000: 05 1B B0 9B 57 39 09 BA 63 55
C1 DE 00 42 B2 FC ....W9..cU...B..tomcat-http-2, WRITE: TLSv1 Change Cipher
Spec, length = 1[Raw write]: length = 60000: 14 03 01 00 01 01
......*** Finishedverify_data: { 14, 134, 102, 9, 242, 17, 92, 21, 186,
202, 96, 1 }***s[write] MD5 and SHA1 hashes: len = 160000: 14 00 00 0C 0E
86 66 09 F2 11 5C 15 BA CA 60 01 ......f...\...`.Padded plaintext before
ENCRYPTION: len = 480000: 14 00 00 0C 0E 86 66 09 F2 11 5C 15 BA CA 60 01
......f...\...`.0010: 39 23 50 C4 45 8A 07 D8 6C 03 86 96 77 EE 4E A4
9#P.E...l...w.N.0020: 40 5A AA 8C 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B
@Z..............tomcat-http-2, WRITE: TLSv1 Handshake, length =
48tomcat-http-2, waiting for close_notify or alert: state 1tomcat-http-2,
Exception while waiting for close java.net.SocketException: Software caused
connection abort: recv failedtomcat-http-2, handling exception:
java.net.SocketException: Software caused connection abort: recv
failedtomcat-http-2, called close()tomcat-http-2, called
closeInternal(true)tomcat-http-2, called closeSocket()The code that is being
used for the webservice client as shown above is exactly the same and it
works with version 2.5.x but fails with cxf version 2.6.x or 2.7.x. Also i
am using cxf in conjunction with Spring as a part of my web application.
Spring version that is being used in 3.2.3 Release and webserver on which we
are deploying this application is Tomcat 7.0.42.If any one has encountered
this problem before kindly inform me if there is any specific configuration
settings that have changed from version 2.6.x onwards which i might be
missing. Any pointers in this regard are greatly appreciated. Thanks!



--
View this message in context: http://cxf.547215.n5.nabble.com/HTTPS-web-service-client-not-working-with-cxf-version-2-6-x-and-2-7-x-but-working-fine-with-version-x-tp5733425.html
Sent from the cxf-user mailing list archive at Nabble.com.
Colm O hEigeartaigh
2013-09-03 11:37:56 UTC
Permalink
Could you supply a test-case to reproduce the problem + I'll take a look?

Colm.
Post by cxf_webservice
I have been struggling with this scenario where i have a web service client
that i developed using cxf version 2.5.x to connect to the web service
hosted within Data Power using SSL. Everything works fine with the cxf
version 2.5.x. The moment i change to cxf version to 2.6.x or 2.7.x i start
getting handshake failures. I am using 2 way ssl which means that on the
client side i have a truststore which holds the public key of the
certificate installed on the Data power's web service side. Likewise i have
given the public key of the self signed certificate that i have on the
client side and this public key has been installed on the truststore on the
data power side.I have been using programmatic way of enabling SSL and the
relevant code for the web service client is here under:private
ServiceRequestPort getWSPort() { URL
wsdlURL =
ServiceRequestService.WSDL_LOCATION; try {
wsdlURL
= new
URL("file:/local/app/dhome/apps/quattroCloud/config/ServiceRequestService.wsdl");
} catch (MalformedURLException e) {
e.printStackTrace(); }
QName SERVICE_NAME = new
QName("http://www.autodesk.com/ws/ServiceRequest/1.0",
"ServiceRequestService"); ServiceRequestService ss = new
ServiceRequestService(wsdlURL, SERVICE_NAME);
ServiceRequestPort
wsPort = ss.getServiceRequest();
SSLContext
sslContext = null; try {
sslContext =
getSSLContext("/local/app/dhome/apps/quattroCloud/config/quattroCloud.p12",
"autodesk"); } catch (Exception e) {
e.printStackTrace(); }
TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.setSecureSocketProtocol("TLS");
tlsParams.setSSLSocketFactory(sslContext.getSocketFactory());
Client
c = ClientProxy.getClient(wsPort);
HTTPConduit conduit = (HTTPConduit)
c.getConduit();
conduit.setTlsClientParameters(tlsParams);
((BindingProvider)wsPort).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
quattroCloudConfig.getTibcowsURL()); return
wsPort; }In the above
code the SSLContext is obtained using:private static SSLContext
getSSLContext(String keyStoreFilePath, String pKeyPassword) throws Exception
{ try { SSLContext context
= SSLContext.getInstance("TLS");
InputStream keyInput = new FileInputStream(keyStoreFilePath);
KeyStore ks
= KeyStore.getInstance("PKCS12");
KeyManagerFactory km =
KeyManagerFactory.getInstance("SunX509");
ks.load(keyInput,
pKeyPassword.toCharArray()); keyInput.close();
km.init(ks,
pKeyPassword.toCharArray());
context.init(km.getKeyManagers(), null, new
SecureRandom()); return context;
} catch (Exception e) {
e.printStackTrace(); } return
null; }The client side certifcate that i
am using has been created using openssl and are in PKCS12 format, following
commands were used to create the certificate for which the public key has
been shared on data power's side and has been imported within data power's
truststore. Created private key like so: openssl genrsa -out
HOSTNAME-private.pem 2048 Create a self-signed X509 certificate: openssl
req -new -x509 -key HOSTNAME-private.pem -out HOSTNAME-certificate.pem -days
1825Create a PKCS12 keystore and import the host certificate we just
created: openssl pkcs12 -export –out quattroCloud.p12 -in
HOSTNAME-certificate.pem -inkey HOSTNAME-private.pem Every time i
am trying to invoke a webservice operation on the port that is returned from
the getWSPort() when cxf version 2.7.6 is being used i get the follwing
handshake error:0000: 14 03 01 00 01 01
......*** Finishedverify_data: { 14, 134, 102, 9, 242, 17, 92, 21, 186,
202, 96, 1 }***s[write] MD5 and SHA1 hashes: len = 160000: 14 00 00 0C 0E
86 66 09 F2 11 5C 15 BA CA 60 01 ......f...\...`.Padded plaintext before
ENCRYPTION: len = 480000: 14 00 00 0C 0E 86 66 09 F2 11 5C 15 BA CA 60 01
......f...\...`.0010: 39 23 50 C4 45 8A 07 D8 6C 03 86 96 77 EE 4E A4
9#P.E...l...w.N.0020: 40 5A AA 8C 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B
@Z..............tomcat-http-2, WRITE: TLSv1 Handshake, length =
48tomcat-http-2, waiting for close_notify or alert: state 1tomcat-http-2,
Exception while waiting for close java.net.SocketException: Software caused
java.net.SocketException: Software caused connection abort: recv
failedtomcat-http-2, called close()tomcat-http-2, called
closeInternal(true)tomcat-http-2, called closeSocket()Some more observations
from the ssl logs that i have seen are here under:Looking at the logs it’s
clear that the client certificate chain process in 2.5.x is able to send the
client certificate, where as it is not sending the client cert in 2.7.x.
CN=uspetdeccprx001.autodesk.com, OU=EIS Development Team, O=AutodeskInc,
L=San Rafael, ST=California, C=US Signature Algorithm: SHA1withRSA, OID =
1.2.840.113549.1.1.5The same step in 2.7.x is not able to send the client
certificate, which results in the handshake error as the mutual
authentication error.2.7.x*** Certificate chain****** ClientKeyExchange, RSA
PreMasterSecret, TLSv1Another difference is that with 2.5.x cxf runtime we
see certificateVerify step taking place like so:Server write IV:0000: D3 C8
EB C7 93 9E 78 D3 53 E8 6C D8 AE FD F6 F4 ......x.S.l.....***
CertificateVerify[write] MD5 and SHA1 hashes: len = 2620000: 0F 00 01 02 01
00 7B 9E 77 47 57 A1 FE A8 32 37 ........wGW...270010: 3E 1A DA 82 9C 00
BC 03 CD 73 FF 72 16 9E 03 C1 >........s.r....0020: FA B1 C6 F7 0E 20 24
26 47 C5 71 82 4E AB 45 6C ..... $&G.q.N.El0030: DF 23 ED 63 85 38 62 C6
A0 95 DD 0E CE 02 D0 F2 .#.c.8b.........0040: A1 F8 E5 97 30 C0 B3 EC E8
0C 79 19 2B 57 EC 8E ....0.....y.+W..0050: CB 01 50 2A 24 C5 A2 6C F9 1A
DB 5F 94 11 EF D8 ..P*$..l..._....0060: DA 4A 6A 0E 9E 50 C9 C0 FF C6 EA
5F 83 A1 60 00 .Jj..P....._..`.0....where as with 2.7.x case at the same
corresponding step we don't see ***CertificateVerify happening from Client
side instead we see exception getting thrown before the data gets exchanged
via the post request.Server write IV:0000: 05 1B B0 9B 57 39 09 BA 63 55
C1 DE 00 42 B2 FC ....W9..cU...B..tomcat-http-2, WRITE: TLSv1 Change Cipher
Spec, length = 1[Raw write]: length = 60000: 14 03 01 00 01 01
......*** Finishedverify_data: { 14, 134, 102, 9, 242, 17, 92, 21, 186,
202, 96, 1 }***s[write] MD5 and SHA1 hashes: len = 160000: 14 00 00 0C 0E
86 66 09 F2 11 5C 15 BA CA 60 01 ......f...\...`.Padded plaintext before
ENCRYPTION: len = 480000: 14 00 00 0C 0E 86 66 09 F2 11 5C 15 BA CA 60 01
......f...\...`.0010: 39 23 50 C4 45 8A 07 D8 6C 03 86 96 77 EE 4E A4
9#P.E...l...w.N.0020: 40 5A AA 8C 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B
@Z..............tomcat-http-2, WRITE: TLSv1 Handshake, length =
48tomcat-http-2, waiting for close_notify or alert: state 1tomcat-http-2,
Exception while waiting for close java.net.SocketException: Software caused
java.net.SocketException: Software caused connection abort: recv
failedtomcat-http-2, called close()tomcat-http-2, called
closeInternal(true)tomcat-http-2, called closeSocket()The code that is being
used for the webservice client as shown above is exactly the same and it
works with version 2.5.x but fails with cxf version 2.6.x or 2.7.x. Also i
am using cxf in conjunction with Spring as a part of my web application.
Spring version that is being used in 3.2.3 Release and webserver on which we
are deploying this application is Tomcat 7.0.42.If any one has encountered
this problem before kindly inform me if there is any specific configuration
settings that have changed from version 2.6.x onwards which i might be
missing. Any pointers in this regard are greatly appreciated. Thanks!
--
http://cxf.547215.n5.nabble.com/HTTPS-web-service-client-not-working-with-cxf-version-2-6-x-and-2-7-x-but-working-fine-with-version-x-tp5733425.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
cxf_webservice
2013-09-03 18:02:47 UTC
Permalink
I am not sure as what is needed, do you require the payload that i send
during web service invocation? The scenario is that SSL channel is not
getting initialized whenever i use 2.6.x or 2.7.x cxf runtimes since SSL
handshake is failing as described in my question. But the same code works
perfectly when the CXF runtime is changed to 2.5.x. I was wondering if
something has changed from 2.6.x onwards which i am not aware of otherwise
why would the same functionality stop working every time i migrate from
2.5.x to 2.6/2.7 version.

I believe this is a very common functionality (mutual authentication via
SSL) that CXF should support and this should work just the same in versions
2.6.x/2.7.x which makes me feel that there is some new configuration that
has been introduced which i am not aware of and am unable to find in its
documentation.



--
View this message in context: http://cxf.547215.n5.nabble.com/HTTPS-web-service-client-not-working-with-cxf-version-2-6-x-and-2-7-x-but-working-fine-with-version-x-tp5733425p5733478.html
Sent from the cxf-user mailing list archive at Nabble.com.
cxf_webservice
2013-09-04 02:14:30 UTC
Permalink
has any one come across a similar issue? Do inform me as i am unable to
upgrade my clients to the latest cxf version of 2.7.6 because of this..



--
View this message in context: http://cxf.547215.n5.nabble.com/HTTPS-web-service-client-not-working-with-cxf-version-2-6-x-and-2-7-x-but-working-fine-with-version-x-tp5733425p5733499.html
Sent from the cxf-user mailing list archive at Nabble.com.
Colm O hEigeartaigh
2013-09-04 08:30:01 UTC
Permalink
I require a test-case to reproduce the error you are having. TLS with
mutual authentication is well tested in CXF as is.

Colm.
Post by cxf_webservice
I am not sure as what is needed, do you require the payload that i send
during web service invocation? The scenario is that SSL channel is not
getting initialized whenever i use 2.6.x or 2.7.x cxf runtimes since SSL
handshake is failing as described in my question. But the same code works
perfectly when the CXF runtime is changed to 2.5.x. I was wondering if
something has changed from 2.6.x onwards which i am not aware of otherwise
why would the same functionality stop working every time i migrate from
2.5.x to 2.6/2.7 version.
I believe this is a very common functionality (mutual authentication via
SSL) that CXF should support and this should work just the same in versions
2.6.x/2.7.x which makes me feel that there is some new configuration that
has been introduced which i am not aware of and am unable to find in its
documentation.
--
http://cxf.547215.n5.nabble.com/HTTPS-web-service-client-not-working-with-cxf-version-2-6-x-and-2-7-x-but-working-fine-with-version-x-tp5733425p5733478.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
cxf_webservice
2013-09-04 16:56:39 UTC
Permalink
i am not understanding what you need with respect to a test case, i am trying
to perform mutual authentication using 2 way ssl and i have shared the
scenario as to what i am doing in the first post and as mentioned above the
client cert is not getting sent after server hello done stage of ssl
handshake, i believe that my TLSParameters are getting overwritten or
getting blanked out within which i have initialized the SSL socketfactory. I
was reading the migration guide to 2.7.6 version, HTTPConduit has been
rewritten and some methods have been removed when compared to the same class
present in 2.5.11.

Will you be able to tell if i am initializing the TLSParameters correctly in
the code above. That is where i believe lies the problem. Not sure why the
client is unable to send the client cert to the server, that can only happen
if the SSL SocketFactory has been nulled out or is not getting called to
initialize the ssl channel, which is properly happening with version 2.5.11.

DO you want me to attach the full client code here?



--
View this message in context: http://cxf.547215.n5.nabble.com/HTTPS-web-service-client-not-working-with-cxf-version-2-6-x-and-2-7-x-but-working-fine-with-version-x-tp5733425p5733531.html
Sent from the cxf-user mailing list archive at Nabble.com.
Daniel Kulp
2013-09-04 18:06:29 UTC
Permalink
Post by cxf_webservice
i am not understanding what you need with respect to a test case, i am trying
to perform mutual authentication using 2 way ssl and i have shared the
scenario as to what i am doing in the first post and as mentioned above the
client cert is not getting sent after server hello done stage of ssl
handshake, i believe that my TLSParameters are getting overwritten or
getting blanked out within which i have initialized the SSL socketfactory. I
was reading the migration guide to 2.7.6 version, HTTPConduit has been
rewritten and some methods have been removed when compared to the same class
present in 2.5.11.
Will you be able to tell if i am initializing the TLSParameters correctly in
the code above. That is where i believe lies the problem. Not sure why the
client is unable to send the client cert to the server, that can only happen
if the SSL SocketFactory has been nulled out or is not getting called to
initialize the ssl channel, which is properly happening with version 2.5.11.
DO you want me to attach the full client code here?
I've gone ahead and used your code to update the wsdl_first_https sample from the kits and it seems to work OK providing a TrustManager[] is also set on the context. (which may be a requirement of the sample). I've attached the diff below.

My suggestion would be to take the wsdl_first_https sample and modify it until you can reproduce your issue. Since the sample works using a variety of methods of configuring the TLS stuff, we have a fairly high confidence that it all works.

My 'gut feeling' is that your WSDL has a "http" url in it instead of an https URL. Thus, the configuration of the TLS stuff doesn't apply at that point.
--
Daniel Kulp
dkulp-1oDqGaOF3Lkdnm+***@public.gmane.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com




diff --git a/distribution/src/main/release/samples/wsdl_first_https/src/main/java/demo/hw_https/client/ClientNonSpring.java b/distribution/src/main/release/samples/wsdl_first_https/src/main/java/demo/hw_https/client/ClientNonSpring.java
index f8e9a6c..602480a 100644
--- a/distribution/src/main/release/samples/wsdl_first_https/src/main/java/demo/hw_https/client/ClientNonSpring.java
+++ b/distribution/src/main/release/samples/wsdl_first_https/src/main/java/demo/hw_https/client/ClientNonSpring.java
@@ -23,14 +23,18 @@ import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
+import java.io.InputStream;
import java.net.URL;
import java.security.GeneralSecurityException;
import java.security.KeyStore;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;
+import java.security.SecureRandom;

import javax.net.ssl.KeyManager;
import javax.net.ssl.KeyManagerFactory;
+import javax.net.ssl.SSLContext;
+import javax.net.ssl.SSLSocketFactory;
import javax.net.ssl.TrustManager;
import javax.net.ssl.TrustManagerFactory;
import javax.xml.namespace.QName;
@@ -56,8 +60,9 @@ public final class ClientNonSpring {
public static void main(String args[]) throws Exception {

if (args.length == 0) {
- System.out.println("please specify wsdl");
- System.exit(1);
+ args = new String[] {"src/main/config/hello_world.wsdl", "secure"};
+ //System.out.println("please specify wsdl");
+ //System.exit(1);
}

URL wsdlURL;
@@ -96,25 +101,48 @@ public final class ClientNonSpring {

private static void setupTLS(Greeter port)
throws FileNotFoundException, IOException, GeneralSecurityException {
- String keyStoreLoc = "src/main/config/clientKeystore.jks";
- HTTPConduit httpConduit = (HTTPConduit) ClientProxy.getClient(port).getConduit();
-
- TLSClientParameters tlsCP = new TLSClientParameters();
- String keyPassword = "ckpass";
- KeyStore keyStore = KeyStore.getInstance("JKS");
- keyStore.load(new FileInputStream(keyStoreLoc), "cspass".toCharArray());
- KeyManager[] myKeyManagers = getKeyManagers(keyStore, keyPassword);
- tlsCP.setKeyManagers(myKeyManagers);
-

- KeyStore trustStore = KeyStore.getInstance("JKS");
- trustStore.load(new FileInputStream(keyStoreLoc), "cspass".toCharArray());
- TrustManager[] myTrustStoreKeyManagers = getTrustManagers(trustStore);
- tlsCP.setTrustManagers(myTrustStoreKeyManagers);
+ SSLContext sslContext = null;
+ try {
+ sslContext = getSSLContext("src/main/config/clientKeystore.jks", "cspass", "ckpass");
+ } catch (Exception e) {
+ e.printStackTrace();
+ }
+
+ TLSClientParameters tlsParams = new TLSClientParameters();
+ tlsParams.setSecureSocketProtocol("TLS");
+ SSLSocketFactory socketFactory = sslContext.getSocketFactory();

- httpConduit.setTlsClientParameters(tlsCP);
+ tlsParams.setSSLSocketFactory(socketFactory);
+
+ HTTPConduit conduit = (HTTPConduit) ClientProxy.getClient(port).getConduit();
+ conduit.setTlsClientParameters(tlsParams);
}

+
+ private static SSLContext getSSLContext(String keyStoreFilePath,
+ String pStorePassword,
+ String pKeyPassword) throws Exception {
+ try {
+ SSLContext context = SSLContext.getInstance("TLS");
+ InputStream keyInput = new FileInputStream(keyStoreFilePath);
+ KeyStore ks = KeyStore.getInstance("JKS");
+ KeyManagerFactory km = KeyManagerFactory.getInstance("SunX509");
+ ks.load(keyInput, pStorePassword.toCharArray());
+ keyInput.close();
+ km.init(ks, pKeyPassword.toCharArray());
+
+ KeyStore trustStore = KeyStore.getInstance("JKS");
+ trustStore.load(new FileInputStream(keyStoreFilePath), "cspass".toCharArray());
+ TrustManager[] myTrustStoreKeyManagers = getTrustManagers(trustStore);
+
+ context.init(km.getKeyManagers(), myTrustStoreKeyManagers, new SecureRandom());
+ return context;
+ } catch (Exception e) {
+ e.printStackTrace();
+ }
+ return null;
+}
private static TrustManager[] getTrustManagers(KeyStore trustStore)
throws NoSuchAlgorithmException, KeyStoreException {
String alg = KeyManagerFactory.getDefaultAlgorithm();
Continue reading on narkive:
Loading...