首页 文章

javax.net.ssl.SSLHandshakeException:java.security.cert.CertificateException:证书不符合算法约束

提问于
浏览
0

我们有一种方式的ssl HTTPS服务器,它将CA证书发送到客户端 . 当客户端将请求发送到服务器时,我们得到一个javax.net.ssl.SSLHandshakeException .

当客户端向https服务器发送请求时,服务器正在抛出sslhandshake异常,如下所示 . 我们试图编辑java安全文件,但似乎无法正常工作 .

2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- |NF javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002-  at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002-  at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002-  at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002-  at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002-  at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002-  at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002-  at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002-  at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002-  at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)


Client and Server connection is established.

root@myhostname> wget --no-check-certificate https://myserver:4443/zen_myevent_listener/eventListener/p1
--2016-09-01 05:09:44--  https://myserver/zen_myevent_listener/eventListener/p1
Connecting to 10.255.120.133:4443... connected.

此算法如下图所示:
Algorithm image

这些是我们生成的HTTPS服务器上的证书 .

-rw-------. 1 root root     3967 Aug 26 15:07 01.pem
-rw-------. 1 root root     1659 Aug 26 15:06 ca.crt
-rw-------. 1 root root     1751 Aug 26 15:05 ca.key
-rw-------. 1 root root      112 Aug 26 15:07 index.txt
-rw-------. 1 root root       21 Aug 26 15:07 index.txt.attr
-rw-------. 1 root root        0 Aug 26 15:05 index.txt.old
-rw-------. 1 root root 42542116 Aug 31 09:48 log.txt
-rwxrwxrwx. 1 root root     8805 Aug 26 12:51 openssl.cnf
-rw-------. 1 root root        3 Aug 26 15:07 serial
-rw-------. 1 root root        3 Aug 26 15:04 serial.old
-rw-------. 1 root root     5626 Aug 26 15:07 server-chain.crt
-rw-------. 1 root root     3967 Aug 26 15:07 server.crt
-rw-------. 1 root root      806 Aug 26 15:06 server.csr
-rw-------. 1 root root      887 Aug 26 15:06 server.key

和01.pem /01.der文件放在客户端上 .

当我们用Google搜索并检查时,我们得到了以下修复/解决方案 . 即使在尝试这个之后,我们仍然会遇到同样的错误 .

原因有两个:

  • Sentinel 7.1 SP1或更高版本附带较新的Java版本,其限制为不允许小于1024的RSA密钥大小

  • 日志记录应用程序中使用的默认证书的密钥大小小于1024,并且不符合此限制 . 因此,服务器拒绝与上面显示的错误消息的连接 .

使系统正常工作的最快方法是恢复此更改 . 编辑文件jre / lib / security / java.security并查找以下行:jdk.certpath.disabledAlgorithms = MD2,RSA keySize <1024
删除最后一个限制,该行将如下所示:jdk.certpath.disabledAlgorithms = MD2
重新启动Sentinel以使更改生效 . 这不是解决方案,而是在升级后使工作正常的解决方法 . 适当的解决方案是在使用强加密(密钥大小为1024或更多)的日志记录应用程序上使用自定义证书 . 所有应用程序更新后,可以将限制放回原位 . IDM 4.5包括一个仪器升级,其中包含大于1024的密钥大小的证书以解决此问题 . eDirectory 88SP8 Patch 2和eDirectory 88SP7 Patch 6具有Instrumentation升级功能,其证书的密钥大小大于1024,以解决问题 . (注意:使用eDirectory不会自动升级检测,您还必须在eDir补丁中手动安装检测包 . )

即使在尝试这个之后我们仍然会得到同样的错误 . 有人能帮助我们如何处理这个问题吗?

这是openssl x509 -text -in server.crt的输出

root@rover> openssl x509 -text -in server.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: md5WithRSAEncryption
        Issuer: C=IN, ST=Karnataka, L=Bangalore, O=mycompany, OU=abc, CN=rover/emailAddress=myemail@gmail.com
        Validity
            Not Before: Aug 26 09:37:05 2016 GMT
            Not After : Dec  9 09:37:05 2019 GMT
        Subject: C=IN, ST=Karnataka, O=mycompany, OU=IMS, CN=rover/emailAddress=myemail@gmail.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:a4:51:0e:c5:7e:eb:e9:8e:89:9c:79:6a:b5:94:
                    d3:94:53:43:b2:26:47:a5:13:25:87:a3:73:03:27:
                    4f:f8:b2:60:86:00:b3:c7:8a:d4:bd:3c:70:33:1e:
                    16:4b:0a:e7:a7:50:a6:48:0e:33:cf:6e:72:30:13:
                    c0:bd:1a:b3:57:ec:ec:bd:6b:90:84:f4:79:a9:29:
                    48:50:7d:e0:07:22:c5:cc:b1:81:4d:8d:61:f5:c6:
                    58:87:73:e0:1b:b9:a1:fc:a0:1a:42:79:96:f6:11:
                    cf:0a:60:fe:26:d4:e3:a6:b8:ca:8d:2c:48:b1:41:
                    5e:f8:64:a6:2f:02:e5:5b:8f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Authority Key Identifier: 
                keyid:C5:05:6A:D7:1B:9A:E1:B6:A5:A2:2F:70:2B:13:C6:C2:74:DA:70:45
                DirName:/C=IN/ST=Karnataka/L=Bangalore/O=mycompany/OU=IMS/CN=rover/emailAddress=myemail@gmail.com
                serial:B0:C5:54:AC:F8:78:7B:5F

    Signature Algorithm: md5WithRSAEncryption
         36:ae:d7:aa:c2:ce:20:91:c9:57:77:e7:4b:c5:e1:b5:28:5d:
         4b:85:db:03:90:67:4e:f9:7d:b1:35:8c:de:80:6d:bf:f5:d0:
         c9:1b:10:8a:c2:de:5e:88:d6:f6:0d:fc:05:92:f0:88:81:98:
         8c:c9:a4:57:1b:70:7d:8d:dc:90:c9:cd:e3:77:1f:81:f0:63:
         39:42:14:ff:d6:46:cb:f9:84:2c:8d:cc:1e:b5:b9:6a:12:2a:
         c4:d4:5c:fa:79:a6:ea:a8:9b:53:65:54:c9:68:a4:d8:63:0f:
         64:a5:35:88:6d:9f:3b:bf:dd:ec:5f:69:95:a2:17:94:97:c9:
         26:89:d2:1b:12:2f:39:35:1f:aa:41:d0:23:2f:0e:c8:83:02:
         9d:70:46:ff:23:3d:5b:46:58:fa:ff:1c:3f:d1:9b:78:21:b9:
         cf:ae:b5:3c:64:12:70:92:71:0f:9f:b0:f9:54:6a:e7:51:41:
         b0:66:2f:0a:57:a1:a7:e6:f8:e0:7b:46:7d:e5:66:b7:f7:e9:
         d4:23:16:89:b0:bc:8e:c5:e6:b9:69:a1:bc:2b:98:08:fc:10:
         9c:9e:71:a8:b6:c1:fa:9a:71:5a:79:9d:07:cb:73:d4:e7:5a:
         01:16:76:38:6e:29:8b:6a:12:72:e9:ac:36:54:a2:9f:75:ef:
         3b:6e:c6:e0
-----BEGIN CERTIFICATE-----
MIID2DCCAsCgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBjzELMAkGA1UEBhMCSU4x
EjAQBgNVBAgTCUthcm5hdGFrYTESMBAGA1UEBxMJQmFuZ2Fsb3JlMQ4wDAYDVQQK
EwVOb2tpYTEMMAoGA1UECxMDSU1TMQ8wDQYDVQQDEwZtYXJzMDQxKTAnBgkqhkiG
9w0BCQEWGmtpc2hvcmUudmVybmVrYXJAbm9raWEuY29tMB4XDTE2MDgyNjA5Mzcw
NVoXDTE5MTIwOTA5MzcwNVowezELMAkGA1UEBhMCSU4xEjAQBgNVBAgTCUthcm5h
dGFrYTEOMAwGA1UEChMFTm9raWExDDAKBgNVBAsTA0lNUzEPMA0GA1UEAxMGbWFy
czA0MSkwJwYJKoZIhvcNAQkBFhpraXNob3JlLnZlcm5la2FyQG5va2lhLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApFEOxX7r6Y6JnHlqtZTTlFNDsiZH
pRMlh6NzAydP+LJghgCzx4rUvTxwMx4WSwrnp1CmSA4zz25yMBPAvRqzV+zsvWuQ
hPR5qSlIUH3gByLFzLGBTY1h9cZYh3PgG7mh/KAaQnmW9hHPCmD+JtTjprjKjSxI
sUFe+GSmLwLlW48CAwEAAaOB1TCB0jAJBgNVHRMEAjAAMIHEBgNVHSMEgbwwgbmA
FMUFatcbmuG2paIvcCsTxsJ02nBFoYGVpIGSMIGPMQswCQYDVQQGEwJJTjESMBAG
A1UECBMJS2FybmF0YWthMRIwEAYDVQQHEwlCYW5nYWxvcmUxDjAMBgNVBAoTBU5v
a2lhMQwwCgYDVQQLEwNJTVMxDzANBgNVBAMTBm1hcnMwNDEpMCcGCSqGSIb3DQEJ
ARYaa2lzaG9yZS52ZXJuZWthckBub2tpYS5jb22CCQCwxVSs+Hh7XzANBgkqhkiG
9w0BAQQFAAOCAQEANq7XqsLOIJHJV3fnS8XhtShdS4XbA5BnTvl9sTWM3oBtv/XQ
yRsQisLeXojW9g38BZLwiIGYjMmkVxtwfY3ckMnN43cfgfBjOUIU/9ZGy/mELI3M
HrW5ahIqxNRc+nmm6qibU2VUyWik2GMPZKU1iG2fO7/d7F9plaIXlJfJJonSGxIv
OTUfqkHQIy8OyIMCnXBG/yM9W0ZY+v8cP9GbeCG5z661PGQScJJxD5+w+VRq51FB
sGYvClehp+b44HtGfeVmt/fp1CMWibC8jsXmuWmhvCuYCPwQnJ5xqLbB+ppxWnmd
B8tz1OdaARZ2OG4pi2oScumsNlSin3XvO27G4A==
-----END CERTIFICATE-----

1 回答

  • 0

    java.security.cert.CertificateException:证书不符合算法约束
    ...
    签名算法:md5WithRSAEncryption

    这很糟糕 . MD5作为签名算法已被打破多年,这种破坏已在几年前的主要攻击中成功使用(Stuxnet) . 我的猜测是Java抱怨这一点 .

    由于证书显然是刚刚创建的,所以有人搞砸了这个证书创建 . 不要尝试解决它,而是创建适当的证书,即使用适当的签名算法(SHA-256而不是MD5)和正确的密钥大小(2048而不是1024) .

相关问题