FULL PRODUCT VERSION :
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)

(Installed from CentOS yum repositories)

ADDITIONAL OS VERSION INFORMATION :
Observed on CentOS 7.4 7.4.1708 but likely applicable everywhere

A DESCRIPTION OF THE PROBLEM :
A recent commit (http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/bd40efd56b45) introduced stricter X509 Name Constraints checking on certificates. (*)

In short, our internal certificates (both server and client) are issued from an intermediate which has 3 DNS name constraints on it. The intermediate was created years ago, and no software (including OpenSSL) we encountered at the time had a problem with any of the certificates we issued, as they didn't validate the CN field of the subject line against the name constraints - only the Subject Alt Names, when present.

Our client certificates don't have subject alt names and the change given above introduces validation of the CN where subject alt names are not present. This means our client certificates are rejected as invalid since the CN field on these certificates holds service names (things like "api" or "frontend-server") and not valid subdomains of the name constraints.

We recognise that our client certificates are technically issued incorrectly but many programs had incorrect name constraint validation for years and so for a long time this was not an issue, meaning that the change broke backwards compatibility. We also recognise the need to implement name constraints correctly and we do intend to migrate our issuance infrastructure to correctly handle name constraints (or indeed remove name constraints entirely).

Is it possible to remove the backport of the name constraints checking for the older JDKs (7, 8) (and perhaps keep it for the newer JDK9)? This removes the backwards-incompatible changes which break our existing deployments, while presenting a clear incentive to improve for the future.


(*) (Running "hg diff -r 12388 -r 12516 src/share/classes/sun/security/provider/certpath/ConstraintsChecker.java" where 12388 and 12516 are the revisions corresponding to 8u144 and 8u151 respectively does seem to confirm that this change was added between 8u144 and 8u151.)

REGRESSION. Last worked in version 8u144

ADDITIONAL REGRESSION INFORMATION:
java-1.8.0-openjdk 1.8.0.144-1.b01 (from CentOS version)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Make a request under 8u151 with a client certificate with no subject alt names and a CN of "hello", issued by an intermediate certificate with name constraints of "DNS:example.com"

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
A TLS connection is established successfully - this has been the case for years.
ACTUAL -
The certificate is rejected as invalid with a message saying "certificate_unknown"

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Rolling back to an older JDK release