37

I have a mapping application that can add ArcGIS 9.3+ base maps given a URL. One of the URLs that I would like to add is from a customer's URL and is secured. My mapping application was using Java 6 before and was able to add the secure URL with no issues. I now upgraded to Java 7 and am getting a 

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

exception. At first, I believe this to be the case because in Java 7, by default, the MD2 algorithm to sign SSL certificates is disabled. You can see this in the java.security file:

"jdk.certpath.disabledAlgorithms=MD2"

But when I check the Certification Signature Algorithm of that URL, it says SHA-1. What is even more strange is if I comment out the "jdk.certpath.disabledAlgorithms=MD2" line in the java.security file, the URL will work with no issues. Is MD2 used somewhere else during the SSL process? Am I missing something here?

malat
  • 12,152
  • 13
  • 89
  • 158
james
  • 601
  • 1
  • 7
  • 12
  • 4
    Bumped into this exception when using 512-bit RSA keys. My `java.security` file has `jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024`. I'm using OpenJDK 7. – Daniel Nov 23 '15 at 18:58

10 Answers10

54

Background

MD2 was widely recognized as insecure and thus disabled in Java in version JDK 6u17 (see release notes http://www.oracle.com/technetwork/java/javase/6u17-141447.html, "Disable MD2 in certificate chain validation"), as well as JDK 7, as per the configuration you pointed out in java.security.

Verisign was using a Class 3 root certificate with the md2WithRSAEncryption signature algorithm (serial 70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf), but deprecated it and replaced it with another certificate with the same key and name, but signed with algorithm sha1WithRSAEncryption. However, some servers are still sending the old MD2 signed certificate during the SSL handshake (ironically, I ran into this problem with a server run by Verisign!).

You can verify that this is the case by getting the certificate chain from the server and examining it:

openssl s_client -showcerts -connect <server>:<port>

Recent versions of the JDK (e.g. 6u21 and all released versions of 7) should resolve this issue by automatically removing certs with the same issuer and public key as a trusted anchor (in cacerts by default).

If you still have this issue with newer JDKs

Check if you have a custom trust manager implementing the older X509TrustManager interface. JDK 7+ is supposed to be compatible with this interface, however based on my investigation when the trust manager implements X509TrustManager rather than the newer X509ExtendedTrustManager (docs), the JDK uses its own wrapper (AbstractTrustManagerWrapper) and somehow bypasses the internal fix for this issue.

The solution is to:

  1. use the default trust manager, or

  2. modify your custom trust manager to extend X509ExtendedTrustManager directly (a simple change).

Raman
  • 17,606
  • 5
  • 95
  • 112
  • Could you check out my (very similar) [question](http://stackoverflow.com/q/20988183/7581)? – itsadok Jan 08 '14 at 06:12
  • 7
    Not only was the openssl s_client ... command incredibly useful, but the solution to my 6 hours of pain and suffering was the X509ExtendedTrustManager change. – user2591854 Jan 21 '16 at 02:44
  • 6
    Change to _X509ExtendedTrustManager_ is the best solution ever. Thank you so much. – Gianluca Greco Oct 27 '16 at 08:53
28

Eclipse failed to connect to SVN https repositories (should also apply to any app using SSL/TLS).

svn: E175002: Connection has been shutdown: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints

The issue was caused by latest Java 8 OpenJDK update that disabled MD5 related algorithms. As a workaround until new certificates are issued (if ever), change the following keys at java.security file

WARNING
Keep in mind that this could have security implications as disabled algorithms are considered weak. As an alternative, the workaround can be applied on a JVM basis by a command line option to use an external java.security file with this changes, e.g.:
java -Djava.security.properties=/etc/sysconfig/noMD5.java.security
For Eclipse, add a line on eclipse.ini below -vmargs
-Djava.security.properties=/etc/sysconfig/noMD5.java.security

original keys

jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768

change to

jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize < 768

java.security file is located in linux 64 at /usr/lib64/jvm/java/jre/lib/security/java.security

LMC
  • 10,453
  • 2
  • 27
  • 52
  • is there a way in code to override same in apache 4.4 – Vish Aug 08 '16 at 18:48
  • not sure but looks related to SSLCipherSuite Directive. Take a look here https://httpd.apache.org/docs/current/mod/mod_ssl.html. Look for this string: RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5 – LMC Aug 09 '16 at 17:55
  • change doesn't work for me, I had to comment out these two lines – sify Apr 26 '18 at 03:33
16

On Fedora 28, just pay attention to the line

security.useSystemPropertiesFile=true

of the java.security file, found at:

$(dirname $(readlink -f $(which java)))/../lib/security/java.security

Fedora 28 introduced external file of disabledAlgorithms control at

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

You can edit this external file or you can exclude it from java.security by setting

security.useSystemPropertiesFile=false

paulmdavies
  • 1,248
  • 3
  • 12
  • 28
Aleksandar Brankovic
  • 171
  • 1
  • 2
  • 1
    I was having this issue with Dbeaver and MS SQL JDBC 6.0 - 6.4 . This solution worked for me and setting -Djdk.tls.client.protocols=TLSv1 did not. – ElectronicBlacksmith Jun 14 '18 at 13:29
  • I was having problems on Fedora 28 with certificates with RSA keys of less than 1024 being rejected - I removed that exception from the `/etc/crypto-policies/back-ends/java.config` and now it works fine. Thanks. – paulmdavies May 09 '19 at 15:41
  • Thank you, this fixed it for me on Fedora 30. – Janne Aug 22 '19 at 12:09
  • I ran into this on Centos 8 and RHEL 8, that now also have crypto-policies. – Onnonymous Mar 04 '21 at 10:42
4

We have this problem with one database we don't control and it requried another solution (The ones listed here didn't work). For mine I needed:

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

I think in my case it had to do with forcing a certain order.

Bill K
  • 62,186
  • 18
  • 105
  • 157
  • This is the only solution that helped me fight "Certificates does not conform to algorithm constraints" exception with DavMail. Had to modify /usr/bin/davmail script to add that option. – Alexander Amelkin Jul 03 '17 at 10:14
2

Since this result is the first that Google returns for this error, I'll just add that if anyone looks for way do change java security settings without changing the global file java.security (for example you need to run some tests), you can just provide an overriding security file by JVM parameter -Djava.security.properties=your/file/path in which you can enable the necessary algorithms by overriding the disablements.

Joonas Vali
  • 727
  • 6
  • 11
1

this is more likely happening because somewhere along your certificate chain you have a certificate, more likely an old root, which is still signed with the MD2RSA algorythm.

You need to locate it into your certificate store and delete it.

Then get back to your certification authority and ask them for then new root.

It will more likely be the same root with the same validity period but it has been recertified with SHA1RSA.

Hope this help.

snlpnstslocn
  • 29
  • 1
1

colleagues.

I have faced with this trouble during a development of automation tests for our REST API. JDK 7_80 was installed at my machine only. Before I installed JDK 8, everything worked just fine and I had a possibility to obtain OAuth 2.0 tokens with a JMeter. After I installed JDK 8, the nightmare with Certificates does not conform to algorithm constraints began.

Both JMeter and Serenity did not have a possibility to obtain a token. JMeter uses the JDK library to make the request. The library just raises an exception when the library call is made to connect to endpoints that use it, ignoring the request.

The next thing was to comment all the lines dedicated to disabledAlgorithms in ALL java.security files. 

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

Then it started to work at last. I know, that's a brute force approach, but it was the most simple way to fix it.

# jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
# jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
Lord Nighton
  • 1,670
  • 21
  • 15
  • Got a bit proper solution, than this ad-hoc one :-) In our case `hybris` works with a weak certificate (and is started at Java 7 and behaves as a server from architectural point of view). So, to fix this trouble I will suggest you to read a bit more about this trouble here (https://www.sslshopper.com/article-how-to-create-a-self-signed-certificate-using-java-keytool.html). An only thing you need to do is to generate a new `keystore` (use **2048** bits key to generate a certificate, its **important**) file and replace an old one. And finally it works just fine. – Lord Nighton Feb 23 '17 at 11:21
0

I have this issue in SOAP-UI and no one solution above dont helped me.

Proper solution for me was to add

-Dsoapui.sslcontext.algorithm=TLSv1

in vmoptions file (in my case it was ...\SoapUI-5.4.0\bin\SoapUI-5.4.0.vmoptions)

menkow
  • 627
  • 1
  • 8
  • 9
0

Using openjdk-7 inside docker I have mounted a file with the content https://gist.github.com/dtelaroli/7d0831b1d5acc94c80209a5feb4e8f1c#file-jdk-security

#Location to mount
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/security/java.security

Thanks @luis-muñoz

dtelaroli
  • 1,227
  • 1
  • 13
  • 20
0

On redhat el8, running openjdk8. Changing the value of the following property from true to false

security.useSystemPropertiesFile = false

In the java.security file fixed the above issue for me

Siddhartha Mukherjee
  • 2,703
  • 2
  • 24
  • 29
Valentine Tobah
  • 1
  • 1