0 Replies Latest reply on Aug 23, 2013 1:23 PM by DanielePizzagalli

    CA chain and NetscapeCertType bits

    DanielePizzagalli

      Hello OTN Community.

       

      I'm seeking some advice or tips about a fatal exception I am getting when I try load my WebStart application.

      I have a Jar containing a simple main class, and a JNLP like the following:

      <?xml version="1.0" encoding="UTF-8"?>
      <jnlp spec="1.0+" codebase="http://localhost:50000" href="/client/test.jnlp">
        <information>
          <title>My Application</title>
          <vendor>Vendor S.p.A.</vendor>
          <homepage href="myTest.html"/>
          <description>Description</description>
        </information>
        <security>
          <all-permissions/>
        </security>
        <update check="always"/>
        <resources>
          <j2se version="1.5+" max-heap-size="512M" java-vm-args="-XX:MaxPermSize=512m"/>
          <jar href="/client/com.my.jar.jar" main="true" download="eager"/>
        </resources>
        <application-desc main-class="com.my.jar.mainClass">
        </application-desc>
      </jnlp>
      

       

      If I sign my certificate with a self-signed certificate, the application works perfectly on any client running any version of Java (we tried from 1.4 to 1.8 (beta), including all updates).

      Without changing any code from the Jar, we then bought a trusted certificate from a certification authority (including CA chain and such) and used it to sign this Jar instead of the self-signed.

      Now, the application works perfectly only from Java 1.4 to 1.6 included, and since Java 1.7.0_0 the application will not run. (Note: we didnt changed any code from the Jar, including manifest entries, and with the self-signed certificate it works even in 1.7).

      The JRE fails asserting "Failed to validate certificate, the application will not be executed." with the following exception:

       

      sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Check netscape bits 5,6,7 value failed in certificate 
       at sun.security.validator.PKIXValidator.doValidate(Unknown Source) 
       at sun.security.validator.PKIXValidator.doValidate(Unknown Source) 
       at sun.security.validator.PKIXValidator.engineValidate(Unknown Source) 
       at sun.security.validator.Validator.validate(Unknown Source) 
       at sun.security.validator.Validator.validate(Unknown Source) 
       at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source) 
       at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source) 
       at sun.plugin.security.PluginClassLoader.getPermissions(Unknown Source) 
       at java.security.SecureClassLoader.getProtectionDomain(Unknown Source) 
       at java.security.SecureClassLoader.defineClass(Unknown Source) 
       at java.net.URLClassLoader.defineClass(Unknown Source) 
       at java.net.URLClassLoader.access$000(Unknown Source) 
       at java.net.URLClassLoader$1.run(Unknown Source) 
       at java.security.AccessController.doPrivileged(Native Method) 
       at java.net.URLClassLoader.findClass(Unknown Source) 
       at sun.applet.AppletClassLoader.findClass(Unknown Source) 
       at java.lang.ClassLoader.loadClass(Unknown Source) 
       at sun.applet.AppletClassLoader.loadClass(Unknown Source) 
       at java.lang.ClassLoader.loadClass(Unknown Source) 
       at sun.applet.AppletClassLoader.loadCode(Unknown Source) 
       at sun.applet.AppletPanel.createApplet(Unknown Source) 
       at sun.plugin.AppletViewer.createApplet(Unknown Source) 
       at sun.applet.AppletPanel.runLoader(Unknown Source) 
       at sun.applet.AppletPanel.run(Unknown Source) 
       at java.lang.Thread.run(Unknown Source)
      Caused by: java.security.cert.CertPathValidatorException: Check netscape bits 5,6,7 value failed in certificate 
       at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(Unknown Source) 
       at sun.security.provider.certpath.PKIXCertPathValidator.doValidate(Unknown Source) 
       at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(Unknown Source) 
       at java.security.cert.CertPathValidator.validate(Unknown Source)
      ...
      

       

      Using jarsigner -verify, the output is simply "Jar verified." without any warnings.

      Turning off all securty options inside Java Control Panel, the problem still persists.

       

      Reading Java's source code (DeployCertPathChecker.java) I can see that the exception is launched because this check fails:

      // Check Netscape certificate type extension
                  if (xcert.getExtensionValue(OID_NETSCAPE_CERT_TYPE) != null)
                  {
                    // Require either bits 5,6 are false or that at least bit 7 be true
                    if ((CertUtils.getNetscapeCertTypeBit(xcert, NSCT_SSL_CA) == true ||
                         CertUtils.getNetscapeCertTypeBit(xcert, NSCT_S_MIME_CA) == true) &&
                         CertUtils.getNetscapeCertTypeBit(xcert, NSCT_OBJECT_SIGNING_CA) == false)
                    {
                       Trace.msgSecurityPrintln("trustdecider.check.basicconstraints.bitvalue");
                       msg = ResourceManager.getMessage("trustdecider.check.basicconstraints.bitvalue");
                       throw new CertPathValidatorException(msg);
                    }
                  }
      

       

      Reading then this BUG REPORT, seems that the problem highlighs the fact that

      [...]
      EVALUATION
      After some investigation, the behavior in JDK7 is correct, the certificate which sign the worldclock.jar file is suppose to be used for email signing, not code signing certificate, that is why the basic constraint check is failed.
      It looks like it might be a bug in JDK6 which we skip the basic constraint check for this certificate, therefore the application still able to run.
      

       

      This is a verbose of my keytool command of my certificate chain about Netscape bits.

      In my "end-point" certificate:
      #8: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
      NetscapeCertType [
         Object Signing
      ]
      
      Then the CA who gave us this certificate:
      #6: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
      NetscapeCertType [
         Object Signing CA
      ]
      
      Then the next certificate over the chain:
      #5: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
      NetscapeCertType [
         SSL CA
      ]
      

       

      It seems to me that the java code above throws the exception for the third certificate in the chain, having SSL_CA true, S_MIME_CA false and OBJECT_SIGNING_CA false.

      But why? Is that a bug? I cant find any BUG reports online.

      Still, online I cant find any documentation about this Netscape Bits check, and I dont know if the problem is really the certificate or something I am missing. My CA says that my certificate is able to sign this jar and the problem should not be due to that.

      How can I be sure if my certificate is really able to sign that Jar? Where can I find any documentation about why Java is applying that check over those bits in 1.7 and not 1.6 (the same code with a no-certificate chain CA works even with 1.7 and 1.8).

       

      Thank you, I really hope I will be able to solve this mistery with your help.