3 Replies Latest reply: Jun 30, 2011 7:22 PM by 800207 RSS

    Basic constraints check fails

      My code is using sun PKIX provider to check a CertPath object which contains a client certificate and a intermediate CA. The intermediate CA has basic constraints as "critical,CA:true,pathlen:0"
      The check passes on JRE 1.6.17 but on 1.6.21. I got the following error:

      java.security.cert.CertPathValidatorException: basic constraints check failed: this is not a CA certificate
           at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:139)
           at sun.security.provider.certpath.PKIXCertPathValidator.doValidate(PKIXCertPathValidator.java:328)
           at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:178)
           at java.security.cert.CertPathValidator.validate(CertPathValidator.java:250)

      I don't understand why the check failed. Because the intermediate CA directly sign the client certificate. So the constraint has been meet. Additional information: the intermediate CA is signed by a self-signed root CA and it is not in the CertPath object, but it's passed as a trusted CA in PKIXParameters. The root doesn't have basic constraints. Is there more check added since 1.6.17. I searched the bug database, and didn't find anything related. Need someone to help to figure out what went wrong.
        • 1. Re: Basic constraints check fails
          I found the answer myself. Found the following changes from openJDK website explaining the error I had:

          231 // RFC5280: If certificate i is a version 3 certificate, verify
          232 // that the basicConstraints extension is present and that cA is
          233 // set to TRUE. (If certificate i is a version 1 or version 2
          234 // certificate, then the application MUST either verify that
          235 // certificate i is a CA certificate through out-of-band means
          236 // or reject the certificate. Conforming implementations may
          237 // choose to reject all version 1 and version 2 intermediate
          238 // certificates.)
          239 //
          240 // We choose to reject all version 1 and version 2 intermediate
          241 // certificates except that it is self issued by the trust
          242 // anchor in order to support key rollover or changes in
          243 // certificate policies.
          244 int pathLenConstraint = -1;
          245 if (currCert.getVersion() < 3) {    // version 1 or version 2
          246 if (i == 1) {                   // issued by a trust anchor
          247 if (X509CertImpl.isSelfIssued(currCert)) {
          248 pathLenConstraint = Integer.MAX_VALUE;
          249 }
          250 }
          251 } else {
          252 pathLenConstraint = currCert.getBasicConstraints();
          253 }

          But the problem is that currCert.getVersion() will return 2 for version3 because the number starts from 0. I think it's a bug.
          • 2. Re: Basic constraints check fails
            I bring this topic back because there is a bug report associated with this topic.

            According the specification of X509Certificate.getVersion(), 3 rather than 2 should be returned for version 3 certificate. And the JDK implementation apply to this specification.

            Would you please reproduce the issue with Java VM option "-Djava.security.debug=certpath", and patch the debugger log?
            • 3. Re: Basic constraints check fails
              It looks like a bug to me also, but I think you need to report the bug somewhere else other than here. It seems that http://bugreport.sun.com/bugreport/ was once the place to do it.