3

We have an application that uses a JAX-RPC client library and is running on a legacy version of Java (1.4.2) and are receiving the following SSL error:

java.lang.NoClassDefFoundError
    javax.crypto.Cipher.a(DashoA6275)
    javax.crypto.Cipher.getInstance(DashoA6275)
    com.sun.net.ssl.internal.ssl.SunJSSE_i.a(DashoA12275)
    com.sun.net.ssl.internal.ssl.CipherBox$JCECipherBox.<init>(DashoA12275)
    com.sun.net.ssl.internal.ssl.CipherRC4.a(DashoA12275)
    com.sun.net.ssl.internal.ssl.SunJSSE_h.a(DashoA12275)
    com.sun.net.ssl.internal.ssl.CipherSuite$BulkCipher.a(DashoA12275)
    com.sun.net.ssl.internal.ssl.SunJSSE_ax.c(DashoA12275)
    com.sun.net.ssl.internal.ssl.SSLSocketImpl.f(DashoA12275)
    com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA12275)
    com.sun.net.ssl.internal.ssl.SunJSSE_az.j(DashoA12275)
    com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA12275)
    com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA12275)
    com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA12275)
    com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
    com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA12275)
    com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA12275)
    sun.net.www.protocol.https.HttpsClient.afterConnect(DashoA12275)
    sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(DashoA12275)
    sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:569)
    sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(DashoA12275)
    com.sun.xml.rpc.client.http.HttpClientTransport.writeMessageToConnection(HttpClientTransport.java:278)
    com.sun.xml.rpc.client.http.HttpClientTransport.invoke(HttpClientTransport.java:64)
    com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:69)
    [ ... trace continues into internal application code ... ]

This has worked for us before and the only changes to the client library are ones related to the authentication protocol used and required an update to the latest build of BouncyCastle. These changes were all at a higher level than the SSL protocol and this error appears to not even involve BouncyCastle.

Has anyone seen an error like this before and perhaps have any thoughts or suggestions? I tried adding the certificate to cacerts. This works fine if run against Java 1.6 however unfortunately the production system running this is still tied to Java 1.4 for the time being.

Also, our JAX-RPC code, and the authentication it does works correctly if we connect to our development systems without SSL.

[edit - additional information] I can now see that there is some conflict happening with the newer versions of BouncyCastle to cause the issue. I've tried using the ancient (1.18) version and I seem to not get the SSL error, but instead get one from our application because it requires newer algorithms.

javanna
  • 59,145
  • 14
  • 144
  • 125
Michael
  • 2,460
  • 3
  • 27
  • 47
  • You may want to have a look at the JRE security policy files (%JAVA_HOME%/jre/lib/security/java.security and java.policy) to see the classes being used by Java 1.4.... maybe the SSL certificate uses some new Cypher which wasn't available for Java 1.4 and you may be able to find that out by looking at the difference between the classes Java is using. – Renato Dec 20 '11 at 16:06
  • Have you made sure you're using the BouncyCastle library for Java 1.4 (it comes in various builds for the same version of the library itself). – Bruno Dec 20 '11 at 17:25
  • 1
    I don't think it has to do with the Cipher used by the SSL certificate. If I revert from BouncyCastle 1.46 to the ancient 1.18 that we previously used the SSL connection works fine. (In that case our application itself breaks because we upgraded to use newer Ciphers) – Michael Dec 20 '11 at 18:58
  • Try not using an ancient version of Java? ;P – Andy Dec 20 '11 at 19:03
  • 1
    @nalroff Oh, how I'd like to. Sadly as you can see I have no control over this. :-/ – Michael Dec 20 '11 at 19:07
  • So, it seems if I use BC 1.26 it gives the error about not having the "SHA256withRSA" cipher our application uses but not the SSL one. If I move to BC 1.27 I get the above SSL error. ****facepalm**** – Michael Dec 21 '11 at 14:19
  • Since there seems to be no real resolution with BouncyCastle does anyone have a suggestion for another 1.4 compatible provider that supports "SHA256withRSA"? (I'm assuming no, but figure it's worth asking.) – Michael Jan 03 '12 at 15:54

2 Answers2

1

So, after a lot of research I finally discovered that deep in our code we inserted the BC provider as provider number 1.

Security.insertProviderAt(prov, 1);

Instead of doing that changing to just adding the provider fixed the issue.

Security.addProvider(prov);
Michael
  • 2,460
  • 3
  • 27
  • 47
0

javax.crypto.Cipher is located in separate (from rt.jar) JAR file called jce.jar. Maybe the classloader failes to find this file or there are no read permissions set on this file for your production app server.

Wojciech Owczarczyk
  • 5,595
  • 2
  • 33
  • 55
  • 2
    `NoClassDefFoundError` means it can find the class but not the classes that are imported by that class. Thus, it found `Cipher` class. You are wrong. – gigadot Dec 20 '11 at 16:11
  • Good point. I thought Cipher was in the message of the exception. Anyway the problem might be caused by some other, security related jar file. – Wojciech Owczarczyk Dec 20 '11 at 16:40
  • 1
    After some more experimenting with things I have found it is definitely related to our BouncyCastle library. I switched back to the (really) old version we used before and no longer receive that error, but instead receive errors I would expect to receive from our application with the older library. At least it is some progress! – Michael Dec 20 '11 at 17:24