的Java NoClassDefFoundError的使用SSL连接

我们有一个使用JAX-RPC客户端库和基于Java（1.4.2）的旧版本正在运行，正在接受以下SSL错误的应用程序：的Java NoClassDefFoundError的使用SSL连接

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 ... ]

这之前已经为我们工作过了，对客户端库的唯一更改是与使用的身份验证协议相关的更改，并且需要更新BouncyCastle的最新版本。这些更改都比SSL协议更高，并且此错误似乎甚至不涉及BouncyCastle。

有没有人看到过这样的错误，也许有任何想法或建议？我试图将证书添加到cacerts。如果运行在Java 1.6上，这很好，但不幸的是运行它的生产系统暂时仍然与Java 1.4绑定在一起。

此外，如果我们连接到没有SSL的开发系统，我们的JAX-RPC代码以及它所做的认证工作正常。

[edit - additional information]我现在可以看到新版本的BouncyCastle发生了一些冲突，导致问题。我试过使用古代（1.18）版本，我似乎没有得到SSL错误，而是从我们的应用程序中获得一个，因为它需要更新的算法。

来源

2011-12-20 Michael

您可能想查看JRE安全策略文件（％JAVA_HOME％/ jre/lib/security/java.security和java.policy）以查看Java 1.4正在使用的类... 。也许SSL证书使用了一些不适用于Java 1.4的新Cypher，并且您可以通过查看Java正在使用的类之间的差异来找到该证书。 – Renato 2011-12-20 16:06:06

你确定你正在使用Java 1.4的BouncyCastle库（它有各种版本的库本身）。 – Bruno 2011-12-20 17:25:04

是的，我有1.4库。 – Michael 2011-12-20 18:57:22

因此，大量的研究后，我终于发现，深藏在我们的代码中插入了BC提供商作为供应商编号1

Security.insertProviderAt(prov, 1);

而不是这样做改变，只是增加了提供固定的问题。

Security.addProvider(prov);

来源

2012-02-03 16:27:37 Michael

javax.crypto.Cipher

位于分开（从rt.jar中）JAR文件称为jce.jar。也许类加载器无法找到该文件，或者您的生产应用程序服务器没有为此文件设置读取权限。

来源

2011-12-20 16:00:30

'NoClassDefFoundError'意味着它可以找到该类，但不能找到该类导入的类。因此，它找到了'Cipher'类。你错了。 – gigadot 2011-12-20 16:11:48

好点。我认为密码是在例外的消息。无论如何，这个问题可能是由其他一些安全相关的jar文件引起的。 – 2011-12-20 16:40:31

经过一些更多的实验后，我发现它与我们的BouncyCastle库相关。我切换回以前使用的（真正的）旧版本，不再收到该错误，而是收到我期望从旧应用程序库收到的错误。至少这是一些进展！ – Michael 2011-12-20 17:24:02

的Java NoClassDefFoundError的使用SSL连接

回答

相关问题