原始密钥

Question

我有一个地图应用程序，可以在给定URL的情况下添加 ArcGIS 9.3 + 基本地图。我想添加的其中一个网址来自客户的网址并受到保护。我的地图应用程序之前使用的是Java 6，并且能够无问题地添加安全URL。我现在升级到Java 7并且正在获得

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

异常。起初，我认为情况就是这样，因为在Java 7中，默认情况下，禁用了用于签署SSL证书的MD2算法。您可以在java.security文件中看到：

"jdk.certpath.disabledAlgorithms=MD2"

但是，当我检查该网址的Certification Signature Algorithm时，会显示SHA-1。更奇怪的是，如果我在"jdk.certpath.disabledAlgorithms=MD2"文件中注释掉java.security行，则该网址无效。在SSL过程中，MD2是否在其他地方使用过？我在这里错过了什么吗？

Answer 1

背景

MD2被广泛认为是不安全的，因此在JDK 6u17版本中禁用Java（请参阅发行说明http://www.oracle.com/technetwork/java/javase/6u17-141447.html，“在证书链验证中禁用MD2”）以及JDK 7，根据您指向的配置在java.security。

Verisign使用的是带有md2WithRSAEncryption签名算法（序列70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf）的Class 3根证书，但弃用了它并将其替换为具有相同密钥和名称的另一个证书，但使用了算法{ {1}}。但是，有些服务器仍然在SSL握手期间发送旧的MD2签名证书（具有讽刺意味的是，我遇到了由Verisign运行的服务器的这个问题！）。

您可以通过以下方式验证是否属于这种情况：

sha1WithRSAEncryption

JDK的最新版本（例如6u21和7的所有发布版本）应该resolve此问题通过自动删除具有相同颁发者和公钥的证书作为可信锚（默认情况下在cacerts中）。

如果新JDK仍存在此问题

检查您是否有实现旧openssl s_client -showcerts -connect <server>:<port>接口的自定义信任管理器。 JDK 7+应该与此接口兼容，但是根据我在信任管理器实现X509TrustManager而不是较新的X509TrustManager（docs）时的调查，JDK使用自己的包装器（X509ExtendedTrustManager）并以某种方式绕过了此问题的内部修复。

解决方案是：

使用默认信任管理器或
修改您的自定义信任管理器以直接扩展AbstractTrustManagerWrapper（一个简单的更改）。

Answer 2

Eclipse无法连接到SVN https存储库（也应该应用于使用SSL / TLS的任何应用程序）。

svn：E175002：连接已关闭：javax.net.ssl.SSLHandshakeException：java.security.cert.CertificateException：证书不符合算法约束

该问题是由禁用MD5相关算法的最新Java 8 OpenJDK更新引起的。作为发布新证书之前的解决方法（如果有的话），请在java.security文件中更改以下键

警告
  请记住，这可能会带来安全隐患，因为禁用的算法被认为是弱的。   作为替代方案，解决方法可以通过命令行选项在JVM基础上应用，以使用外部 java.security 文件进行此更改，例如：   java -Djava.security.properties=/etc/sysconfig/noMD5.java.security
  对于 Eclipse ，在 -vmargs 下面的 eclipse.ini 上添加一行   -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

Answer 3

在Fedora 28上，只需注意一下

security.useSystemPropertiesFile =真

<{1}}文件的

，位于：

$（dirname $（readlink -f $（java）））/../ lib / security / java.security

Fedora 28在

引入了disabledAlgorithms控件的外部文件

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

您可以编辑此外部文件，也可以通过设置

将其从java.security中排除

security.useSystemPropertiesFile =假

Answer 4

我们在一个我们无法控制的数据库中遇到此问题，并且需要另一个解决方案（此处列出的解决方案不起作用）。对我来说，我需要：

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

我认为在我的情况下，它与强制某个订单有关。

Answer 5

这种情况更有可能发生，因为证书链中的某个地方有证书，更可能是旧的根，但仍然使用MD2RSA algorythm签名。

您需要将其放入证书库并将其删除。

然后回到您的认证机构，然后向他们询问新的根。

更有可能是具有相同有效期的相同根，但已使用SHA1RSA重新认证。

希望得到这个帮助。

Answer 6

的同事。

在开发REST API的自动化测试期间，我遇到了这个问题。 JDK 7_80仅安装在我的机器上。在我安装JDK 8之前，一切正常，我有可能获得带有JMeter的OAuth 2.0令牌。安装JDK 8后，开始了Certificates does not conform to algorithm constraints的噩梦。

JMeter和Serenity都没有获得令牌的可能性。 JMeter使用JDK库来发出请求。当库调用连接到使用它的端点时，库只会引发异常，忽略请求。

接下来是注释 ALL java.security文件中专门用于disabledAlgorithms的所有行。

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

Answer 7

我在SOAP-UI中遇到过这个问题，上面没有一个解决方案对我没有帮助。

正确的解决方案是添加

-Dsoapui.sslcontext.algorithm = TLSv1

在vmoptions文件中（在我的例子中是...... \ SoapUI-5.4.0 \ bin \ SoapUI-5.4.0.vmoptions）

Answer 8

由于此结果是Google为此错误返回的第一个结果，我只想补充一点，如果有人在寻找方法，请在不更改全局文件java.security的情况下更改java安全设置（例如，您需要运行一些测试），您可以通过JVM参数提供覆盖的安全文件 -Djava.security.properties =您的/文件/路径，您可以通过覆盖禁用来启用必要的算法。

Answer 9

在docker内部使用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

java.security.cert.CertificateException：证书不符合算法约束

9 个答案:

背景

如果新JDK仍存在此问题

原始密钥

更改为