Could you supply a test-case to reproduce the problem + I'll take a look? Colm.
On Tue, Sep 3, 2013 at 5:26 AM, cxf_webservice <[email protected]> wrote: > 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 Talend Community Coder http://coders.talend.com
