的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連接

回答

相關問題