Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

OSLC Workshop with RTC 5.0 (SSLPeerUniverifiedException)

Hello, I'm trying to run OSLC workshop example.

Open Services for Lifecycle Collaboration Workshop

https://jazz.net/library/article/635

https://jazz.net/wiki/bin/view/Main/OSLCWorkshopDownload


With RTC 4.0.2, it worked.
But with RTC 5.0 , I got SSLPeerUnverifiedException (detail see below).
 ・Server: RTC 5.0 (Express Setup)
   - recreated self-certification after installed
 ・Client: RTC IDE Client

Is there any information about this error?
Is OSLC workshop example compatible with CLM 5.0?
If it isn't compatible, is there any OSLC java sample for CLM 5.0?

SSLPeerUnverifiedException  detail:
>> Example01: Accessing Root Services document with HttpClient
    - Root Services URI: https://jazz-server:9443/ccm/rootservices
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
    at com.ibm.jsse2.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:177)
    at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
    at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:339)
    at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:123)
    at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:147)
    at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:108)
    at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
    at net.jazz.oslc.consumer.examples.Example01.main(Example01.java:52)

0 votes


Accepted answer

Permanent link
Well I figured it out after some debugging and mucking around. It seems that the CLM 5.0 server (with the bundled Tomcat anyway) no longer allows SSL connection with SSLv3 protocol, and TLSv1 is the only one supported in the default configuration. Due to the mismatched protocol, the SSL handshake will fail and no connection can be established. To make the sample code work, you need to modify the net/jazz/oslc/utils/HttpUtils.java file by changing
            sc = SSLContext.getInstance("SSL"); //$NON-NLS-1$
to
            sc = SSLContext.getInstance("TLSv1"); //$NON-NLS-1$
With this change, the code should still work with CLM 4.0.x server since it supports both SSLv3 and TLSv1.

Rosa Naranjo selected this answer as the correct answer

2 votes


2 other answers

Permanent link
I ran the same sample code against my own RTC 4.0.6 environment and jazz.net (5.0) and did not have any problems. The error that you got occurred when the HttpClient first connected to the Jazz server and failed to establish an SSL connection, so it has nothing to do with RTC versions or OSLC. It appears that the code "HttpUtils.setupLazySSLSupport(httpclient);" did not work in your case.
The sample code bundles Apache HTTP Client library 4.0.1 and works for me. Did you use a different version of that library?

0 votes

Comments

Thank you for your response.
>The sample code bundles Apache HTTP Client library 4.0.1 and works for me. Did you use a different version of that library?

I also use Apache HTTP Client library 4.0.1 bundled with workshop.

That's a bit strange. You can use another HTTPS connection for testing. It does not need to be Jazz server. Just pick a secure connection with an unverified certificate (most self-signed certificates fall into this category). If the problem can still be reproduced, you have to debug a bit further, probably on Appache HTTP Client.

@Dnong I tried with CLM 4.0.2 and 4.0.6 no problem. but CLM 5.0 have still same error.  I am also using  Apache HTTP Client library 4.0.1 bundled with workshop.




I can actually see the same error in my CLM 5.0 environment now for some reason. I analyzed the network trace using Wireshark and found out that the Java application actually communicated with the CLM 5.0 server (GET versionCompatibility) before being kicked out by the server (it seems).
The curious thing is CLM 4.0.6 and CLM 5.0 actually use the same certificate if the bundled Tomcat is used.
Some more digging is still required.


Permanent link
Import your server's self-signed certificate to the client JDK's key store, and comment out the line which calls "net.jazz.oslc.utils.HttpUtils.setupLazySSLSupport()".

At first, you export a key by using your browser, or by executing keytool on the server side.

To import a server's key to the client key store using keytool, here is the sample command;
keytool -import -trustcacerts -file <your-server's-certificate-pass> -alias clm50ca -keystore ..\lib\security\cacerts
Note that backing up the key store is recommended, and default key store password is "changeit".

0 votes

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 10,954

Question asked: Jun 04 '14, 2:20 a.m.

Question was seen: 5,545 times

Last updated: Jul 24 '14, 4:54 a.m.

Confirmation Cancel Confirm