JDK-8140422 : Add mechanism to allow non default root CAs to be not subject to algorithm restrictions
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-10-23
  • Updated: 2019-05-31
  • Resolved: 2016-05-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9 Other
8u152Fixed 9 b117Fixed openjdk7uFixed
Related Reports
Blocks :  
Blocks :  
Blocks :  
Blocks :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8171464 :  
We should provide a mechanism or option to distinguish certificates that chain to the default root CAs that are included in the cacerts file in the JRE from those that are added subsequently or otherwise not in the default set (e.g., private CAs used within an enterprise) when enforcing the algorithm restrictions in the jdk.certpath.disabledAlgorithms security property.

This allows certificates that are issued by private CAs to be treated differently with respect to algorithm restrictions. These CAs may not yet be compliant with standard recommendations on weak algorithms and/or may need more time to conform to the restrictions.
UR SQE OK to take the enhancement to CPU17_01

When enforcing constraints via the CertPath API, the PKIX implementation is provided with the certificate chain, and a set of trust anchors. It does not necessarily know if the trust anchor (or root CA) is public or non-public, or it may not know the keystore they came from (the caller can specify the anchors as a Set<TrustAnchor> or a KeyStore). We need a mechanism that allows us to check if the anchor is a root CA that is included in the cacerts file shipped with the JDK. Additionally, we need to add an option (e.g. jdkCA) to the jdk.certpath.disabledAlgorithms property to toggle this behavior, e.g.: jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA This would mean the constraints for MD2 and MD5 are applied to all certs but for SHA-1 they are only applied to certs chaining back to the default set of cacerts in the JDK (it does not include any that are subsequently added to cacerts by a user/admin).