dovle01

Tuesdays Tips: Certificates does not conform to algorithm constraints

Discussion created by dovle01 Employee on May 6, 2015


This error message "Certificates does not conform to algorithm constraints" comes from an out dated SSL Certificate.  A common method within QA Organization's that this type of error occurs is when a specific department (the originator) wants their SUT to be exercised by the QA Department,  The originatorprovides an SSL certificate for the QA people to use.  As a result, the QA personnel have no prior knowledge how or when the certificate was created.  If the QA person exercises the SUT and receives "Certificates does not conform to algorithm constraints", it is due to an older certificate being used that contains a security issue.  Typically, the QA Department does not have time for to send the certificate back to the originating department and wait for an updated cert.  Here is how to progress the testing, make note of the error as something the Originator needs to address, and still meet the deadlines for the testing cycle.

 

  1. Look for this file in the path indicated:

    $LISA_HOME/jre/lib/security/java.security
  2. Open with a text editor.  Look for this line:

    jdk.certpath.disabledAlgorithms=MD2
  3. Comment it out so it looks like this:

    #jdk.certpath.disabledAlgorithms=MD2
  4. Save the file and re-run the test.  It will pass the spot where it complained about the "Certificates does not conform to algorithm constraints".

 

Here is a more in depth answer if you want to read further or want to give a complete answer when returning the Certificate to the originator:

 

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

You can verify that this is the case with:

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, then check if you have a custom trust manager implementing the older X509TrustManager interface. JDK 7 is supposed to be compatible with this interface, however it appears that 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. Using the default trust manager, or modifying your custom trust manager to extend X509ExtendedTrustManager directly (a simple change) should solve the problem.

 

To sum it up in English, it is likely happening because somewhere along your certificate chain you have a certificate, more likely an old root, which is still signed with the MD2RSA algorithm. 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 re-certified with SHA1RSA.

 

Please note:  CA cannot guarantee the accuracy of third party links.  These links may change without notice to this article or CA in general.

Outcomes