It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,845
×11,979

question asked: Jun 27 '12, 10:43 a.m.
question was seen: 8,742 times
last updated: Dec 06 '12, 12:45 p.m.

Related questions

"RSA premaster secret error" when connecting to RTC

0
1
Luca Martinucci (1.0k●3●97●112) | asked Jun 27 '12, 10:43 a.m.
I am trying to connect to a RTC repository programmatically (using a snippet of the plain Java Libraries).
When I execute Snippet1 I get this error:

Jun 27, 2012 4:37:55 PM org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
INFO: I/O exception (javax.net.ssl.SSLKeyException) caught when processing request: RSA premaster secret error
Jun 27, 2012 4:37:55 PM org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
INFO: Retrying request
Unable to login: CRJAZ0099I When accessing the URL "https://<hostname>:9443/jts/versionCompatibility?clientVersion=3.0.1" the following HTTP error occurred: "RSA premaster secret error"

It looks like a SSL authentication error, but I couldn't determine its cause.
RTC version is 3.0.1.1, RTC is deployed on Tomcat, OS is Windows Server 2003 SE SP1
Any suggestion?
Comments
Harshal Bhavsar commented Jul 30 '12, 5:26 a.m. | edited Jul 30 '12, 9:30 a.m.

Did u find any solution for it.I am facing the same problem its exact same exception and using http apache client 3.x

Please let me know the solution for it Thanks in advance!!

Luca Martinucci commented Aug 01 '12, 12:19 p.m.

Sorry, no news.

Buzz Moschetti commented Nov 29 '12, 6:38 p.m.

Same problem; just got it today.   In googling about, I suspect it has something to do with the crypto libraries that are picked up when you set -Djava.ext.dirs.   My perl module (written over the summer) DOES connect so the client-side perl SSL libs (written in C not Java) are OK and this means the server is working too.



Accepted answer

3
permanent link
Buzz Moschetti (76●2●5) | answered Nov 30 '12, 8:28 a.m.
Confirmed -- the java.ext.dirs instruction is goofing up the way the crypto libs are pulled in.    If you use good ol' fashioned CLASSPATH it works.   Put all those libs in a big CLASSPATH variable and run it, i.e.

CLASSPATH=\
apache-mime4j-0.6.jar:\
com.ibm.icu_4.0.1.v20090822.jar:\
com.ibm.rational.wvcm.ct_3.0.4.v20120314_0638.jar:\
com.ibm.rational.wvcm.factory_3.0.2.v20110831_0247.jar:\
com.ibm.rational.wvcm.interop_3.0.3.v20120314_0638.jar:\
...
snippets:.
java -classpath $CLASSPATH snippets.Snippet1

Luca Martinucci selected this answer as the correct answer
Comments
Buzz Moschetti commented Nov 30 '12, 8:29 a.m.

BTW:
java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.6) (6b22-1.10.6-0ubuntu1)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)

Buzz Moschetti commented Dec 06 '12, 12:45 p.m.

For clarity:   If you carefully order the args to java.ext.dir it will work.   For starters, ensure the default VM ext dirs are first and the CLM lib dir is LAST.

But truly, this is not the true purpose of java.ext.dir.   There are 69 jars in CLM lib and although I can appreciate why putting 69 libs in the CLASSPATH is a drag, it nonetheless is The Proper Way to declare app-level libs to the VM.   I would suggest that IBM jarjar the thing into a substantially smaller set of symbol-isolated jars.

Your answer

Register or 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.