Java NoClassDefFoundError с соединением SSL - PullRequest
Новая
       18

Java NoClassDefFoundError с соединением SSL

3 голосов
/ 20 декабря 2011

У нас есть приложение, которое использует клиентскую библиотеку JAX-RPC и работает на устаревшей версии Java (1.4.2) и получает следующую ошибку 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.

Кроме того, наш код JAX-RPC и аутентификация, которую он выполняет, работает правильно, если мы подключаемся к нашим системам разработки без SSL.

[edit - дополнительная информация] Теперь я вижу, что естьВозникла проблема с новыми версиями BouncyCastle.Я попытался использовать древнюю (1.18) версию, и мне кажется, что я не получаю ошибку SSL, а вместо этого получаю ее из нашего приложения, потому что она требует более новых алгоритмов.

Ответы [ 2 ]

1 голос
/ 03 февраля 2012

Итак, после долгих исследований я, наконец, обнаружил, что глубоко в нашем коде мы вставили провайдера BC в качестве провайдера номер 1. 

Security.insertProviderAt(prov, 1);

Вместо того, чтобы сделать это, просто добавив провайдера, исправили проблему. 

Security.addProvider(prov);
0 голосов
/ 20 декабря 2011

javax.crypto.Cipher находится в отдельном (из rt.jar ) файле JAR с именем jce.jar . Возможно, загрузчик классов не может найти этот файл, или для этого сервера рабочих приложений не заданы разрешения на чтение для этого файла.

...