Java lang runtimeexception keypair generation error



Rutoken и КриптоПро JCP (ошибка java.lang.RuntimeException)

Форум Рутокен → Техническая поддержка пользователей → Rutoken и КриптоПро JCP (ошибка java.lang.RuntimeException)

Сообщений 7

#1 Тема от mariya 2015-06-17 17:21:00

  • mariya
  • Посетитель
  • Неактивен

Rutoken и КриптоПро JCP (ошибка java.lang.RuntimeException)

Всем Доброго времени суток!
возникла проблема: в вэб-сервисе не подписываются запросы с помощью крипто jcp, возникает ошибка:
java.lang.RuntimeException: Не найден закрытый ключ
at isc.jcp.JcpFacade.createSignature(JcpFacade.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.intersys.gateway.JavaGateway.executeInstanceMethod(JavaGateway.java:891)
at com.intersys.gateway.JavaGateway.executeMethod(JavaGateway.java:836)
at com.intersys.gateway.JavaGateway.processMessage(JavaGateway.java:432)
at com.intersys.gateway.JavaGateway.run(JavaGateway.java:421)
at com.intersys.gateway.JavaGateway.run(JavaGateway.java:402)

После выполнения:
store = KeyStore.getInstance(«RutokenStore»);
store.load(null, «пароль»);
получаем:
store!=null

Затем:
aliases = store.aliases();
size = store.size();
получаем:
aliases не содержит элементов,
size = 0

Соответственно в хранилище RutokenStore не видится контейнер.

КриптоПро JCP 1.0 (1.0.54)
Java 1.7.0.17
драйвер рутокена 2.96.00.0530
модуль поддержки рутокена для криптопро jcp 2.06.00.0013

Источник

Error on Debian with Java 8: «Could not generate DH keypair» #2626

Comments

fd0 commented Jun 27, 2016 •

I’m trying to use ZAP on Debian with OpenJDK8 (package is openjdk-8-jre , Version 8u91-b14-1

bpo8+1 ). Accessing a website via HTTPS through ZAP with a browser configured properly (CA is installed and configured) leads to the following error (most of the time, see notes below):

These are my notes so far:

  • It looks like ZAP is trying to create DH parameters larger than 2048 bit, this will be supported in Java 9, thread on stackoverflow, OpenJDK bugtracker
  • Using burpsuite works, with the same version of Java
  • It seems Fedora patched OpenJDK to allow larger primes: https://bugzilla.redhat.com/show_bug.cgi?id=1163501
  • It looks like the size of the DH parameters is provided by the server: thread on stackoverflow
  • Whether this error occurs depends on the Server: It works well with TLS servers with small DH groups, but due to the mitigation for the Logjam attack, everybody generated large, custom DH parameters.
  • I’ve tried the latest released version (2.5.0) and the latest nightly version of ZAP, no difference.

Is there anything I can do to help you debug this problem further?

I’d really like to use ZAP, is it maybe possible to configure the SSLContext to only accept ciphers which do not use DH with a Java version that is unable to handle large DH parameters? How do other program work around this limitation?

The text was updated successfully, but these errors were encountered:

Источник

Could not generate DH keypair (Unlimited Strength Extension doesn’t work)

I’m trying to do simple https GET from a webserver having a selfsigned 2048 certificate, but it fails since stock java doesn’t support > 1024 bits encryption.
I’ve hit this with 1.6.0_07 and 1.6.0_43, and for both versions, I’ve tried downloading:
http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html

and replacing the two jar files, but with no detectable change. Is there any (simple) way to verify that I actually did install the two files successfully?
is there something else I need to do?

Upgrading java is not an option in the short run..

The full exception..
javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1591)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1554)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1537)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1463)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:64)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flushBuffer(AbstractSessionOutputBuffer.java:147)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flush(AbstractSessionOutputBuffer.java:154)
at org.apache.http.impl.AbstractHttpClientConnection.doFlush(AbstractHttpClientConnection.java:278)
at org.apache.http.impl.AbstractHttpClientConnection.flush(AbstractHttpClientConnection.java:283)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.flush(ManagedClientConnectionImpl.java:175)
at org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:260)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:717)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:522)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
at tp7summerization.RancidParser.findTP7Aggregates(RancidParser.java:122)
at tp7summerization.RouterThread.run(RouterThread.java:42)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.RuntimeException: Could not generate DH keypair
at com.sun.net.ssl.internal.ssl.DHCrypt. (DHCrypt.java:106)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:417)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:145)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:623)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
. 17 more
Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)
at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
at com.sun.net.ssl.internal.ssl.DHCrypt. (DHCrypt.java:100)
. 25 more

Answers

Host systems are respectively:
1. OSX, where all 3 occurrences of the files < local_policy.jar, US_export_policy.jar >has been replaced. (plugin version, installed version & Xcode version)
2. FreeBSD, where both occurrences of the files has been replaced. (SUN version & Diablo version).

I also checked that the files have the same attributes/rights set as the original ones.
I hope the date of the two jars should be ignorable.

Читайте также:  Hardware monitor error power

If you check the link in the original post — is it right for 1.6?

Seems like a dead end to me as it stands..

I must be jinxed somehow:

/usr/local/bin/java -jar /store0/JavaApplication4/JavaApplication4.jar
os.arch : i386
os.name : FreeBSD
os.version : 8.1-RELEASE
Java version : 1.6.0_07

java -jar «/Users/ssch/NetBeansProjects/JavaApplication4/dist/JavaApplication4.jar»
os.arch : x86_64
os.name : Mac OS X
os.version : 10.8.3
Java version : 1.6.0_43

I guess it’d make sense to suspect some other cause then just the amount of bits used in the certificate?
I’m really not that much of a scolar when it comes to certificates — and as mentioned, I think its a self-signed one.
its using: SHA-1 with RSA Encryption
and its issued by RapidSSL.com fwiw.

I’ve tried to expand a bit on your code and print out all the available providers, and the getInfo() of each of them:

Available provider: SUN version 1.6
SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP, Collection CertStores, JavaPolicy Policy; JavaLoginConfig Configuration)
Available provider: Apple version 1.0
Apple Provider (implements DES, Triple DES, AES, Blowfish, PBE, Diffie-Hellman, HMAC/MD5, HMAC/SHA1)
Available provider: SunRsaSign version 1.5
Sun RSA signature provider
Available provider: SunJSSE version 1.6
Sun JSSE provider(PKCS12, SunX509 key/trust factories, SSLv3, TLSv1)
Available provider: SunJCE version 1.6
SunJCE Provider (implements RSA, DES, Triple DES, AES, Blowfish, ARCFOUR, RC2, PBE, Diffie-Hellman, HMAC)
Available provider: SunJGSS version 1.0
Sun (Kerberos v5, SPNEGO)
Available provider: SunSASL version 1.5
Sun SASL provider(implements client mechanisms for: DIGEST-MD5, GSSAPI, EXTERNAL, PLAIN, CRAM-MD5; server mechanisms for: DIGEST-MD5, GSSAPI, CRAM-MD5)
Available provider: XMLDSig version 1.0
XMLDSig (DOM XMLSignatureFactory; DOM KeyInfoFactory)
Available provider: SunPCSC version 1.6
Sun PC/SC provider

I’m not sure I understand your response. Do you get an exception on either of the OS?

I note you are using Netbeans. It is very common for people to fail to configure the Netbeans ‘Platform’ correctly so that they pick up the Netbeans JDK rather than the one they desire. If in doubt, follow «Properties->Libraries->Manage Platforms» and add the desired JDK then configure «Properties->Libraries->Java Platform» .

No, there were no exceptions.

I now tried on a third machine (OSX also), running JDK7.
This is the entire screen-dump. Notice that only the local_policy.jar changes size — I’m not sure if it matters that I’m located in Denmark?
The NetBeans project is using the JDK listed below, at least that what the settings for the project says.

Is there really no chance that this is something other then the policies not being installed correct?

Also — I really appreciate all the help I’m getting in here — really awesome how fast responses are coming and how competent they are!! Excellent!

Источник

Почему SSL-рукопожатие дает «не удалось создать исключение DH keypair»?

когда я делаю SSL-соединение с некоторыми IRC-серверами (но не другими-предположительно из-за предпочтительного метода шифрования сервера), я получаю следующее исключение:

примером сервера, демонстрирующего эту проблему, является aperture.Эспер.net: 6697 (это IRC-сервер). Примером сервера, который не демонстрирует проблему, является kornbluth.freenode.net: 6697. [Неудивительно, что все серверы в каждой сети совместно используют то же самое поведение.]

мой код (который, как отмечалось, работает при подключении к некоторым серверам SSL):

это последний startHandshake, который выбрасывает исключение. И да, с «trustAllCerts» происходит какая-то магия; этот код заставляет систему SSL не проверять сертификаты. (Так. не проблема к экзамену.)

очевидно, одна из возможностей заключается в том, что сервер esper неправильно настроен, но я искал и не нашел никаких других ссылок на людей возникли проблемы с SSL-портами esper, и «openssl» подключается к нему (см. ниже). Поэтому мне интересно, является ли это ограничением поддержки SSL по умолчанию Java или что-то еще. Есть предложения?

вот что происходит, когда я подключаюсь к aperture.esper.net 6697 использование ‘openssl’ из командной строки:

как уже отмечалось, после всего этого он успешно подключается, что больше, чем вы можете сказать для моего приложения Java.

Читайте также:  Unhandled exception caught при запуске

если это актуально, я использую OS X 10.6.8, Java версии 1.6.0_26.

21 ответов

проблема заключается в простом размере. Максимально допустимый размер, который принимает Java, составляет 1024 бита. Это известная проблема (см. JDK-6521495).

отчет об ошибке, с которым я связался, упоминает решение использование реализации JCE BouncyCastle. Надеюсь, это сработает.

обновление

Это было сообщено как ошибка JDK-7044060 и недавно отремонтированы.

заметим, однако, что предел был поднят только до 2048 бит. Для размеров > 2048 бит, есть JDK-8072452-удалить максимальный основной размер ключей DH; исправление представляется для 9.

ответ» Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files » не работал для меня, но предложение поставщика JCE BouncyCastle сделало это.

вот шаги, которые я предпринял с помощью Java 1.6.0_65-b14-462 на Mac OSC 10.7.5

1) Скачать эти баночки:

2) переместите эти банки в $JAVA_HOME/lib / ext

3) редактировать $JAVA_HOME / lib / безопасность / java.безопасность следующим образом: безопасность.поставщик.1=org.после установки BouncyCastle.око.поставщик.BouncyCastleProvider

перезапустить приложение, с помощью JRE и дать ему попробовать

вот мое решение (java 1.6), также было бы интересно, почему я должен был это сделать:

Я заметил из javax.безопасность.debug=ssl, что иногда используемый набор шифров является tls_dhe_. и когда-нибудь это TLS_ECDHE_. Позже произойдет, если я добавлю BouncyCastle. Если tls_ecdhe_ был выбран, большую часть времени он работал, но не всегда, поэтому добавление даже поставщика BouncyCastle было ненадежным (сбой с той же ошибкой, каждый раз или около того). Наверное, где-то на Солнце. реализация иногда его выбирают DHE, иногда выбрать ECDHE.

поэтому решение, размещенное здесь, зависит от полного удаления шифров TLS_DHE_. Примечание: BouncyCastle не требуется для решения.

создайте файл сертификации сервера:

сохраните это, поскольку на него будут ссылаться позже, чем здесь решение для SSL http get, исключая наборы шифров TLS_DHE_.

наконец вот как он используется (certFilePath, если путь сертификата сохранен из openssl):

ответ выше правильный, но с точки зрения обходного пути у меня были проблемы с реализацией BouncyCastle, когда я установил его в качестве предпочтительного поставщика:

Это также обсуждается в одном потоке форума, который я нашел, в котором не упоминается решение. http://www.javakb.com/Uwe/Forum.aspx/java-programmer/47512/TLS-problems

Я нашел альтернативное решение, которое работает для моего случая, хотя я совсем не доволен этим. Решение это установить это так, что алгоритм Диффи-Хеллмана вообще недоступен. Затем, предположим, что сервер поддерживает альтернативный алгоритм, он будет выбирать во время обычных переговоров. Очевидно, недостатком этого является то, что если кому-то каким-то образом удается найти сервер, который поддерживает только Diffie-Hellman на 1024 битах или меньше, это фактически означает, что он не будет работать там, где он работал раньше.

вот код, который работает с данным SSLSocket (перед подключением это):

вы можете полностью отключить DHE в своем jdk, редактировать jre/lib/security / java.безопасность и убедитесь, что DHE отключен, например. как

вы можете установить провайдера динамически:

1) Скачать эти баночки:

2) скопируйте банки в WEB-INF/lib (или ваш classpath)

3) Добавить провайдера динамически:

Это довольно старый пост, но если вы используете Apache HTTPD, вы можете ограничить размер DH. См.http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh

Если вы используете jdk1.7.0_04, обновление до jdk1.7.0_21. Проблема была исправлена в этом обновлении.

Если вы все еще укушены этой проблемой и вы используете Apache httpd v> 2.4.7, попробуйте следующее:http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh

скопировано с url:

начиная с версии 2.4.7, mod_ssl будет использовать параметры DH, которые включают простые числа с длиной более 1024 бит. Однако Java 7 и более ранние версии ограничивают их поддержку простых размеров DH максимум 1024 битами.

Если ваш клиент на основе Java прерывается с исключениями, такими как java.ленг.RuntimeException: не удалось создать пару ключей DH и java.безопасность.InvalidAlgorithmParameterException: простой размер должен быть кратен 64 и может варьироваться только от 512 до 1024 (включительно), а httpd регистрирует внутреннюю ошибку TLSv1 alert (номер предупреждения SSL 80) (на уровне LogLevel info или выше), вы можете либо изменить список шифров mod_ssl с помощью SSLCipherSuite (возможно, в сочетании с SSLHonorCipherOrder), либо использовать пользовательские параметры DH с 1024-битным простым, который всегда будет иметь приоритет над любым из встроенных параметров DH.

для создания пользовательских параметров DH используйте

Читайте также:  Lenovo 2103 detection error on ssd0 m 2

попробуйте загрузить» Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files » из загрузки Java сайт и замена файлов в вашем JRE.

Это сработало для меня, и мне даже не нужно было использовать BouncyCastle — стандартный Sun JCE смог подключиться к серверу.

PS. Я получил ту же ошибку (ArrayIndexOutOfBoundsException: 64), когда я попытался использовать BouncyCastle перед изменением файлов политики, поэтому кажется, что наша ситуация очень похожий.

у меня такая же проблема с Yandex Maps server, JDK 1.6 и Apache HttpClient 4.2.1. Ошибка была

с включенной отладкой по -Djavax.net.debug=all в журнале было сообщение

я исправил эту проблему, добавив BouncyCastle library bcprov-jdk16-1.46.jar и регистрация провайдера в классе картографического сервиса

поставщик регистрируется при первом использовании MapService .

решена проблема путем обновления до JDK 8.

Я использую coldfusion 8 на JDK 1.6.45 и имел проблемы с предоставлением мне только красных крестов вместо изображений, а также с cfhttp, не способным подключиться к локальному веб-серверу с ssl.

мой тестовый скрипт для воспроизведения с ColdFusion 8 был

это дало мне довольно общую ошибку » исключение ввода-вывода: peer не аутентифицируется.» Затем я попытался добавить сертификаты сервера, включая корневые и промежуточные сертификаты, в хранилище ключей java, а также coldfusion keystore, но ничего не помогло. затем я отладил проблему с

у меня тогда была идея, что веб-сервер (apache в моем случае) имел очень современные шифры для ssl и довольно ограничительный (qualys score a+) и использует сильные ключи diffie hellmann с более чем 1024 битами. очевидно, что coldfusion и java jdk 1.6.45 не могут справиться с этим. Следующим шагом в odysee было подумать об установке альтернативной безопасности провайдер для java, и я решил для bouncy castle. см. также http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-eclipse-for-java-jse-projects/

затем я загрузил

от http://www.bouncycastle.org/latest_releases.html и установил его под C:\jdk6_45\jre\lib\ext или где когда-либо ваш jdk, в оригинальной установке coldfusion 8 он будет находиться под C:\JRun4\jre\lib\ext но . Я использую новый jdk (1.6.45), расположенный вне каталога coldfusion. очень важно поставить bcprov-ext-jdk15on-156.банка в каталоге \ext (это стоило мне около двух часов и некоторых волос 😉 затем я отредактировал файл C:\jdk6_45\jre\lib\security\java — . безопасность (с wordpad не с редактором.exe!) и поставить в одну строку для нового провайдера. после этого список выглядел так:

(см. Новый в позиции 1)

затем перезапустите службу coldfusion полностью. вы может тогда

и наслаждаться чувством. и конечно

что за ночь и что за день. Надеюсь, это поможет (частично или полностью) кому-то там. если у вас есть вопросы, просто напишите мне на info . (домен выше).

если сервер поддерживает шифр, который не включает DH, вы можете заставить клиента выбрать этот шифр и избежать ошибки DH. Например:

имейте в виду, что указание точного шифра склонно к поломке в долгосрочной перспективе.

У нас точно такая же ошибка возвращается, чтобы исправить это было легко после нескольких часов серфинга в интернете.

мы загрузили самую высокую версию jdk, которую мы могли найти на oracle.com, установил его и указал JBoss application server в каталог установленного нового jdk.

перезапущен Jboss, переработан, Исправлена проблема.

у меня есть эта ошибка с Bamboo 5.7 + Gradle project + Apache. Gradle попытался получить некоторые зависимости от одного из наших серверов через SSL.

устранение:

добавить вывод в файл сертификата (для Apache — SSLCertificateFile param)

попробуйте построить проект снова

я использовал для получения аналогичной ошибки доступа svn.apache.org с клиентами JAVA SVN, использующими IBM JDK. В настоящее время svn.apache.org пользователи клиенты шифруют предпочтения.

после запуска только один раз с захватом пакета / javax.сеть.debug=все, что я смог занести в черный список только один шифр DHE, и все работает для меня (вместо этого ECDHE обсуждается).

хорошее быстрое исправление, когда нелегко изменить клиента.

я обнаружил ошибку SSL на сервере CentOS под управлением JDK 6.

мой план состоял в том, чтобы установить более высокую версию JDK (JDK 7), чтобы сосуществовать с JDK 6, но оказывается, что просто установка нового JDK с rpm -i не хватило.

установка JDK 7 будет успешной только с rpm -U опции обновления, как показано ниже.

Источник

Оцените статью
toolgir.ru
Adblock
detector