SSL/TLS -证书链验证导致“无效身份验证类型: DHE_RSA”

Question

我有一个连接到部署在HTTPS上的远程web服务的应用程序。我们的应用程序使用FIPS-140级别-1进行SSL/TLS连接，并且基于RSA (该公司)的JCE提供者。

com.rsa.jsse.JsseProvider.JsseProvider()
RsaJsse version 6.14

com.rsa.jsafe.provider.JsafeJCE.JsafeJCE()
JsafeJCE version 6.11

最近，网络服务团队对其终端进行了修改，以启用DH密码。更改后，为SSL选择的密码是TLS_DHE_RSA_WITH_AES_256_GCM_SHA384。但是，证书链验证似乎失败了，只有以下例外情况：

java.lang.IllegalArgumentException: Invalid authentication type: DHE_RSA
    at com.rsa.sslj.x.cj.checkClientTrusted(Unknown Source)
    at com.example.MyX509TrustManager.checkServerTrusted(ReloadableX509TrustManager.java:65)
    at com.rsa.sslj.x.aE.a(Unknown Source)
    at com.rsa.sslj.x.bg.a(Unknown Source)
    at com.rsa.sslj.x.bg.a(Unknown Source)
    at com.rsa.sslj.x.bg.a(Unknown Source)
    at com.rsa.sslj.x.aH.a(Unknown Source)
    at com.rsa.sslj.x.aH.a(Unknown Source)
    at com.rsa.sslj.x.ap.c(Unknown Source)
    at com.rsa.sslj.x.ap.a(Unknown Source)
    at com.rsa.sslj.x.ap.j(Unknown Source)
    at com.rsa.sslj.x.ap.i(Unknown Source)
    at com.rsa.sslj.x.ap.h(Unknown Source)
    at com.rsa.sslj.x.aS.startHandshake(Unknown Source)
    at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:261)
    at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:118)

谁能告诉我“无效身份验证类型: DHE_RSA”的含义是什么？在后端we服务中启用DH密码之前，这种身份验证类型以前是"RSA"，我们从来没有遇到过任何问题。

我在这个问题的评论中看到，如果算法没有被FIPS-140批准，这个错误就会出现。这里会是这样吗？

请注意，com.example.MyX509TrustManager.checkServerTrusted方法没有做任何特殊的事情--它是为了在某些特殊情况下跳过证书链验证而编写的，否则它将委托给java.net.ssl.TrustManager#checkClientTrusted --在这种情况下，TrustManager是RSA类的实例，其名称在RSA jars中被混淆。

更新：

看来com.rsa.sslj.x.cj.checkClientTrusted希望公钥中使用的算法应该是DHE_RSA，因为远程web服务的证书链中使用的算法是RSA --它报告了一个错误，它说的是Invalid authentication type。远程web服务团队最近将dhparam添加到他们的SSL配置到避免逻辑阻塞漏洞中，但是他们没有对他们的证书做任何更改。不清楚为什么我们的SSL客户端从那时起就开始无法连接到远程服务，我是否需要为我们的应用程序或远程web服务团队做些什么。在这方面的任何投入都将是非常有用的。

Answer 1

您的自定义checkServerTrusted不应该转发到标准checkClientTrusted，而应该转发到标准checkServerTrusted。authType for Server是一个密钥交换名称，但对于客户端是一个算法名--它们一般不一样，在您刚刚遇到的情况下，它们是不同的，而且应该是不同的。

FIPS140只指定和限制算法，而不是更高级别的构造，如TLS密钥交换、密匙和协议。DH只在一些不适用于TLS的约束下被批准(由800-56A批准)，但对于FIPS1402实现指南D.8中涵盖FIPS1402的情况，并且在CMVP #2057上以几乎JSAFE版本的方式被列为实现。OTOH SP800-52确实限制了与FIPS140相同的大多数系统的TLS，而r1在2014年不允许使用DHE_RSA，但#2057早于2014年。所以我很确定这里没有FIPS问题。