javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: 证书不符合算法约束
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
我们有一种方法可以将 CA 证书发送到客户端的 ssl HTTPS 服务器。当客户端向服务器发送请求时，我们得到 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.
算法如下图所示：
这些是我们在 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文件放在客户端。
当我们用谷歌搜索和检查时，我们得到了以下 fix/resolution。即使在尝试之后，我们仍然遇到同样的错误。
这样做的原因有两个：
- Sentinel 7.1 SP1 或更高版本附带一个较新的 Java 版本，该版本具有不允许 RSA 密钥大小小于 1024
的限制
- 日志记录应用程序中使用的默认证书的密钥大小小于 1024，不符合此限制。因此，服务器拒绝连接并显示如上所示的错误消息。
The fastest way to get the system working is to revert back this
change. Edit the file jre/lib/security/java.security and look for this
line:
jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
Remove the last restriction, the line will look like this:
jdk.certpath.disabledAlgorithms=MD2
Restart Sentinel for the changes to take effect.
This would not be a solution but a workaround to get things working after the upgrade.
A proper resolution is to use custom certificates on the logging applications that use strong encryption (key sizes of 1024 or more).
Once all applications have been updated, the restriction can be put
back in place.
IDM 4.5 includes an instrumentation upgrade with certificates to a key size larger than 1024 to fix this problem.
eDirectory 88SP8 Patch 2 and eDirectory 88SP7 Patch 6 have
Instrumentation upgrades with certificates to a key size larger than
1024 to fix the problem. (Note: Instrumentation is not automatically
upgraded with eDirectory, you must also manually install the
instrumentation package within the eDir patch.)
即使尝试了此操作，我们仍然遇到相同的错误。有人可以帮助我们如何进行吗？
这是 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-----
java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
...
Signature Algorithm: md5WithRSAEncryption
这很糟糕。作为签名算法的 MD5 已被破坏多年，这种破坏已在多年前的重大攻击中成功使用（Stuxnet）。我的猜测是 Java 抱怨这个。
由于证书显然是最近才创建的，所以有人严重搞砸了这个证书的创建。不要尝试解决它，而是创建适当的证书，即使用适当的签名算法（SHA-256 而不是 MD5）和适当的密钥大小（2048 而不是 1024）。
我们有一种方法可以将 CA 证书发送到客户端的 ssl HTTPS 服务器。当客户端向服务器发送请求时，我们得到 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.
算法如下图所示：
这些是我们在 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文件放在客户端。
当我们用谷歌搜索和检查时，我们得到了以下 fix/resolution。即使在尝试之后，我们仍然遇到同样的错误。
这样做的原因有两个：
- Sentinel 7.1 SP1 或更高版本附带一个较新的 Java 版本，该版本具有不允许 RSA 密钥大小小于 1024 的限制
- 日志记录应用程序中使用的默认证书的密钥大小小于 1024，不符合此限制。因此，服务器拒绝连接并显示如上所示的错误消息。
The fastest way to get the system working is to revert back this change. Edit the file jre/lib/security/java.security and look for this line:
jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024Remove the last restriction, the line will look like this:
jdk.certpath.disabledAlgorithms=MD2Restart Sentinel for the changes to take effect.
This would not be a solution but a workaround to get things working after the upgrade.
A proper resolution is to use custom certificates on the logging applications that use strong encryption (key sizes of 1024 or more). Once all applications have been updated, the restriction can be put back in place.
IDM 4.5 includes an instrumentation upgrade with certificates to a key size larger than 1024 to fix this problem.
eDirectory 88SP8 Patch 2 and eDirectory 88SP7 Patch 6 have Instrumentation upgrades with certificates to a key size larger than 1024 to fix the problem. (Note: Instrumentation is not automatically upgraded with eDirectory, you must also manually install the instrumentation package within the eDir patch.)
即使尝试了此操作，我们仍然遇到相同的错误。有人可以帮助我们如何进行吗？
这是 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-----
java.security.cert.CertificateException: Certificates does not conform to algorithm constraints ... Signature Algorithm: md5WithRSAEncryption
这很糟糕。作为签名算法的 MD5 已被破坏多年，这种破坏已在多年前的重大攻击中成功使用（Stuxnet）。我的猜测是 Java 抱怨这个。
由于证书显然是最近才创建的，所以有人严重搞砸了这个证书的创建。不要尝试解决它，而是创建适当的证书，即使用适当的签名算法（SHA-256 而不是 MD5）和适当的密钥大小（2048 而不是 1024）。