Java.security.cert.CertificateException: сертификаты не соответствуют ограничениям алгоритма

У меня есть приложение сопоставления, которое может добавлять базовые карты ArcGIS 9.3+ с учетом URL-адреса. Один из URL-адресов, которые я хотел бы добавить, - это URL-адрес клиента и защищен. Мое приложение сопоставления использовало Java 6 раньше и смогло добавить защищенный URL без проблем. Теперь я обновлен до Java 7 и получаю

"java.security.cert.CertificateException: Certificates does not conform to algorithm constraints"

исключение. Сначала я считаю, что это так, потому что в Java 7 по умолчанию алгоритм MD2 для подписывания сертификатов SSL отключен. Это можно увидеть в файле java.security:

"jdk.certpath.disabledAlgorithms=MD2"

Но когда я проверяю Certification Signature Algorithm этого URL-адреса, он говорит SHA-1. Еще более странно, если я прокомментирую строку "jdk.certpath.disabledAlgorithms=MD2" в файле java.security, URL-адрес будет работать без проблем. Используется ли MD2 где-то еще во время процесса SSL? Я что-то пропустил?

Ответ 1

Фон

MD2 широко признана небезопасной и, следовательно, отключена на Java в версии JDK 6u17 (см. примечания к выпуску http://www.oracle.com/technetwork/java/javase/6u17-141447.html, "Отключить MD2 в проверке цепочки сертификатов" ), а также JDK 7, согласно конфигурации, указанной в java.security.

Verisign использовала корневой сертификат класса 3 с алгоритмом подписи md2WithRSAEncryption (serial 70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf), но не рекомендовал его и заменил его другим сертификатом с тем же ключом и именем, но подписал с алгоритмом sha1WithRSAEncryption. Тем не менее, некоторые серверы по-прежнему отправляют старый подписанный сертификат MD2 во время установления связи SSL (по иронии судьбы, я столкнулся с этой проблемой с сервером, выполняемым Verisign!).

Вы можете убедиться, что это так:

openssl s_client -showcerts -connect <server>:<port>

Последние версии JDK (например, 6u21 и все выпущенные версии 7) должны решить эту проблему, автоматически удалив сертификаты с тем же эмитентом и открытым ключом как надежный anchor (по умолчанию в cacerts).

Если у вас все еще есть эта проблема с новыми JDK

Проверьте, есть ли у вас собственный диспетчер доверия, реализующий более старый интерфейс X509TrustManager. Предполагается, что JDK 7+ совместим с этим интерфейсом, однако на основе моего исследования, когда диспетчер доверия реализует X509TrustManager, а не новый X509ExtendedTrustManager (docs), JDK использует свою собственную оболочку (AbstractTrustManagerWrapper) и как-то обходит внутреннее исправление этой проблемы.

Решение:

используйте диспетчер доверия по умолчанию или
измените свой собственный диспетчер доверия, чтобы напрямую расширить X509ExtendedTrustManager (простое изменение).

Ответ 2

Eclipse не удалось подключиться к репозиториям SVN https (также должно применяться к любому приложению, использующему SSL/TLS).

svn: E175002: соединение было закрыто: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: сертификаты не соответствуют ограничениям алгоритма

Проблема была вызвана последним обновлением Java 8 OpenJDK, которое отключило алгоритмы, связанные с MD5. В качестве обходного пути, пока новые сертификаты не будут выпущены (если когда-либо), измените следующие ключи в файле java.security

ПРЕДУПРЕЖДЕНИЕ
Имейте в виду, что это может иметь последствия для безопасности, поскольку отключенные алгоритмы считаются слабыми. В качестве альтернативы, обходной путь может быть применен на основе JVM с помощью параметра командной строки для использования внешнего файла java.security с этими изменениями, например:
java -Djava.security.properties=/etc/sysconfig/noMD5.java.security
Для Eclipse добавьте строку на eclipse.ini ниже -vmargs
-Djava.security.properties=/etc/sysconfig/noMD5.java.security

оригинальные ключи

jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768

изменить на

jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize < 768

Файл java.security находится в linux 64 по адресу /usr/lib64/jvm/java/jre/lib/security/java.security.

Ответ 3

На Fedora 28 просто обратите внимание на строчку

security.useSystemPropertiesFile = TRUE

файла java.security, найденного по адресу:

$ (dirname $ (readlink -f $ (который java)))/../lib/security/java.security

Fedora 28 представила внешний файл управления отключенными алгоритмами в

/etc/crypto-policies/back-ends/java.config

Вы можете редактировать этот внешний файл или вы можете исключить его из java.security, установив

security.useSystemPropertiesFile = ложь

Ответ 4

У нас есть эта проблема с одной базой данных, которую мы не контролируем, и она требует другого решения (перечисленные здесь не работают). Для меня мне нужно:

-Djdk.tls.client.protocols="TLSv1,TLSv1.1"

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

Ответ 5

это, скорее всего, происходит потому, что где-то рядом с цепочкой сертификатов у вас есть сертификат, более вероятно, старый корень, который все еще подписан с алгоритмом MD2RSA.

Вам нужно найти его в хранилище сертификатов и удалить его.

Затем вернитесь в свой центр сертификации и спросите их о новом корне.

Скорее всего, это будет тот же самый корень с тем же периодом действия, но он был повторно сертифицирован с помощью SHA1RSA.

Надеюсь на эту помощь.

Ответ 6

коллег.

Я столкнулся с этой проблемой во время разработки тестов автоматизации для нашего REST API. JDK 7_80 был установлен только на моей машине. До того, как я установил JDK 8, все работало отлично, и у меня была возможность получить токены OAuth 2.0 с JMeter. После того, как я установил JDK 8, начался кошмар с Certificates does not conform to algorithm constraints.

Оба JMeter и Serenity не имели возможности получить токен. Для выполнения запроса JMeter использует библиотеку JDK. Библиотека просто вызывает исключение, когда вызов библиотеки выполняется для подключения к конечным точкам, которые используют его, игнорируя запрос.

Следующим шагом было прокомментировать все строки, посвященные disabledAlgorithms, в файлах ALL java.security.

C:\Java\jre7\lib\security\java.security
C:\Java\jre8\lib\security\java.security
C:\Java\jdk8\jre\lib\security\java.security
C:\Java\jdk7\jre\lib\security\java.security

Затем он начал работать наконец. Я знаю, что подход грубой силы, но это был самый простой способ его исправить.

# jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
# jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

Ответ 7

У меня есть эта проблема в SOAP-UI, и ни одно решение выше не помогло мне.

Правильное решение для меня было добавить

-Dsoapui.sslcontext.algorithm = TLSv1

в файле vmoptions (в моем случае это было... \SoapUI-5.4.0\bin\SoapUI-5.4.0.vmoptions)

Ответ 8

Так как этот результат является первым, что Google возвращает за эту ошибку, я просто добавлю, что если кто-то ищет способ изменить настройки безопасности java без изменения глобального файла java.security (например, вам нужно запустить несколько тестов), вы можете просто предоставьте переопределяющий файл безопасности с помощью параметра JVM -Djava.security.properties = your/file/path, в котором вы можете включить необходимые алгоритмы, переопределив отключения.

Ответ 9

Используя openjdk-7 внутри докера, я смонтировал файл с содержимым https://gist.github.com/dtelaroli/7d0831b1d5acc94c80209a5feb4e8f1c#file-jdk-security

#Location to mount
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/security/java.security

Спасибо @luis-muñoz