JDK-8184673 : Fix compatibility issue in AlgorithmChecker for 3rd party JCE providers
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 8u141,9,10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-07-14
  • Updated: 2018-02-15
  • Resolved: 2017-07-17
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 10 JDK 8 Other
10 b16Fixed 8u161Fixed openjdk7uFixed
Related Reports
Relates :  
Relates :  
The change http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d911fe42d2da to sun.security.provider.certpath.AlgorithmChecker has introduced an incompatibility to legacy JCE providers that would return old naming convention names, like SHA1/RSA, for X509Certificate.getSigAlgName().

Although the new naming such as SHA1withRSA should be implemented by the providers, it is safe to revert this place to take the signature algorithm name from the internal certificate implementation object that exists at this place anyway. By doing this we can overcome the potential incompatibility.
This request came in for 8uX fix if I recall correctly (8u critical request) . Let's fix there first. Fixed already in JDK 10.

I think so. I don't see it in 9 at all at present.

Should this also be backported to JDK 9.0.4 along with 8u161?

No response, over a weekend... :/ This regression should have been resolved in 8u151. I added the label before that was released. We would still like to see it fixed in 8u161 if possible, which I believe is based on 8u152, not 8u162.

no response, removing label for now.

[~andrew] please add background to why the critical request label is on this issue. It's already fixed in the jdk8u-dev code line.

8174849 is also part of this multi-backport patch applied to earlier releases.

The issue has been discussed here: http://mail.openjdk.java.net/pipermail/security-dev/2017-July/016068.html