JDK-8176350 : Usage constraints don't take effect when using PKIX
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-03-08
  • Updated: 2017-03-20
  • Resolved: 2017-03-11
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 JDK 9
10Fixed 8u152Fixed 9 b161Fixed
Related Reports
Relates :  
JDK-8160655 - Fix denyAfter and usage types for security properties
Description
1. Imports the below SHA1 certificate into TEST_JDK/lib/security/cacerts as a trusted JDK CA with alias like "testca [jdk]"
-----BEGIN CERTIFICATE-----
MIICWzCCAcQCCQCtPczRiCRiFjANBgkqhkiG9w0BAQUFADByMQswCQYDVQQGEwJV
TjETMBEGA1UECAwKU29tZSBTdGF0ZTEVMBMGA1UEBwwMVW5rbm93biBDaXR5MREw
DwYDVQQKDAhUZXN0IE9yZzESMBAGA1UECwwJVGVzdCBVbml0MRAwDgYDVQQDDAdU
ZXN0IENBMB4XDTE3MDIyODAyNTIwN1oXDTE3MDMzMDAyNTIwN1owcjELMAkGA1UE
BhMCVU4xEzARBgNVBAgMClNvbWUgU3RhdGUxFTATBgNVBAcMDFVua25vd24gQ2l0
eTERMA8GA1UECgwIVGVzdCBPcmcxEjAQBgNVBAsMCVRlc3QgVW5pdDEQMA4GA1UE
AwwHVGVzdCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArtAsOS/uNlIP
TGGT3if2yM00BMkjdiMUUpIH4BqzryFz8y5Q4V0x7E5NeLjwMlHcGpvHOyqMadi1
FoWT5nvJzeBvvwQwL4JwN1LLpqZyITmIRh8Ps7mfGbUX87phKig16Qc4o9jlH5y5
+i2lGJWx3ByENo3dFaHcTvXS0vrPZCUCAwEAATANBgkqhkiG9w0BAQUFAAOBgQB3
Ij4727A9yZQKF5S8YRTSiA1+8G7lFm+BQu9uBJw5cm/+TL2UsJPn96Asy8EUfD9k
SI685uGxRg90CAf5DYZ2gZe4LAP79KFmPlJKjbaVl8QuaFUmur9x5cR6aLCRBBLH
5UW4OxLmPBJGk0FwpVf9fXJooh7W4wt4cJW1SlNrZQ==
-----END CERTIFICATE-----

2. The attached JSSECertPathCheck.java is a SSL test which depends on SSLSocketTemplate.
It contains a SHA1 end entity certificate, which is issued by the above SHA1 CA, and uses constraint "SHA1 jdkCA & usage TLSServer" for jdk.certpath.disabledAlgorithms.
The test should fail on C/S communication, but it doesn't.
Comments
Just uploaded SSLServer.java and SSLClient.java for further investigation. Both of the classes need JSSECertPathCheck.java to create ssl context. After imported the SHA1 cert in the description of this issue into cacerts, run SSLServer and SSLCient in sequence. The validation sill doesn't fail even though dev's patch [1] is applied. [1] http://cr.openjdk.java.net/~ascarpino/8176350/webrev/
10-03-2017