1

We have one way ssl HTTPS server which sends CA certificates to the client. When the client sends the request to the server we are getting a javax.net.ssl.SSLHandshakeException.

When the client sends request to the https server, server is throwing a sslhandshake exception as shown below. We tried to edit java security file but that seems to be not working.

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.

The algorithm for this is shown in the picture below: Algorithm image

These are the certificates on HTTPS server which we have generated.

-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

and 01.pem /01.der file is placed on client.

When we googled and checked, we got the below fix/resolution. Even after trying this, we are still getting the same error.

The reason for this is twofold:

  • Sentinel 7.1 SP1 or later ships with a newer Java version that has a restriction to not allow RSA keySizes of less than 1024
  • The default certificates used in the logging applications have a key size of less than 1024 and don't comply to this restriction. Because of this, the server rejects the connection with the error message shown above.

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.)

Even after trying this we are still getting the same error. Could some one help us how to proceed with this?

Here is the output of 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/[email protected]
        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/[email protected]
        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/[email protected]
                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-----
Improve this question
2
  • The problem is with the certificate but the image does not show the certificate. For example do openssl x509 -text -in server.pem on the certificate you use in the server and add the output to your question. Commented Sep 1, 2016 at 6:22
  • This is likely the problem: md5WithRSAEncryption. Also see MD5 considered harmful today | Creating a rogue CA certificate. Commented Sep 2, 2016 at 0:15

1 Answer 1

Reset to default
1 
java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
...
Signature Algorithm: md5WithRSAEncryption

This is pretty bad. MD5 as signature algorithm is broken for many years and this brokenness was already used successfully in major attacks years ago (Stuxnet). My guess is that Java complains about this.

Since the certificates are obviously just created recently someone messed up this certificate creation badly. Don't try to work around it but instead create proper certificates, i.e. using a proper signature algorithm (SHA-256 instead of MD5) and a proper key size (2048 instead of 1024).

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.