JDK-4653099 : Cannot set up certs for trusted CAs [for KeyGenerator.getInstance("DESede")]
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt,windows_2000
  • CPU: x86
  • Submitted: 2002-03-14
  • Updated: 2002-04-04
  • Resolved: 2002-04-04
Description

Name: nt126004			Date: 03/14/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
Windows NT Version 4.0

ADDITIONAL OPERATING SYSTEMS :
Red Hat Linux release 7.0 (Guinness)
Kernel 2.2.16-22 on an i686


A DESCRIPTION OF THE PROBLEM :
The test program will produce
"Cannot set up certs for trusted CAs"
WHEN the SUN provider is NOT in

#
# List of providers and their preference orders (see above):
#
security.provider.1=com.trustpoint.security.provider.Trustpoint
#security.provider.2=sun.security.provider.Sun

section in jdk\jre\lib\security\java.security.


Same result for both JDK1.2.2 and JDK1.3.1.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Execute the test program as follow:
D:\work\learn>java -Djava.compiler=NONE
-Dtrustpoint.preferred.security.providers=SUN,Trustpoint -classpath
d:\jce1.2.1\lib\jce1_2_1.jar;d:\jce1.2.1\lib\local_policy.jar;
d:\jce1.2.1\lib\US_export_policy.jar;d:\jce1.2.1\lib\sunjce_provider.jar;
d:\work\build\trustpoint\lib\TrustpointProviders.jar;
d:\work\build\trustpoint\lib\ecc_all.jar;.;
d:\work\build\trustpoint\lib\TrustpointAll.jar jceKeyGenTest

2.
3.

EXPECTED VERSUS ACTUAL BEHAVIOR :
==========================
java -Djava.compiler=NONE jceTest <provider> <cipherAlg>
<keyAlg>
default alg:DESede
==========================
alg:DESede
Provider is NOT set
kg from provider:Trustpoint

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.lang.ExceptionInInitializerError: java.lang.Secu
rityException: Cannot set up certs for trusted CAs
        at javax.crypto.b.<clinit>([DashoPro-V1.2-120198])
        at
        at jceKeyGenTest.keyGenTest(jceKeyGenTest.java:28)
        at jceKeyGenTest.main(jceKeyGenTest.java:43)

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.security.Key;
import java.security.AlgorithmParameters;
import java.security.SecureRandom;
import java.security.spec.AlgorithmParameterSpec;
import java.security.spec.KeySpec;

import javax.crypto.Cipher;
import javax.crypto.KeyGenerator;
import javax.crypto.SecretKeyFactory;
import javax.crypto.spec.DESKeySpec;
import javax.crypto.spec.DESedeKeySpec;

public class jceKeyGenTest {
  private static String ALG = "DESede";
  private static String CIPHER_ALG = "DESede/CBC/NoPadding";
  private static String KEY_ALG = "DESede";

  static public void keyGenTest(String alg, String provider) {
    try {
      System.out.println("==========================");
      System.out.println("alg:" + alg);
      KeyGenerator kg;
      if (provider != null) {
        System.out.println("Provider:" + provider);
        kg = KeyGenerator.getInstance(alg, provider);
      } else {
        System.out.println("Provider is NOT set");
        kg = KeyGenerator.getInstance(alg);
      }
      System.out.println("kg from provider:" + kg.getProvider().getName());
    } catch (Exception e) {
      e.printStackTrace();
    }
  }

  static public void main(String[] args) {
    System.out.println("==========================");
    System.out.println("java -Djava.compiler=NONE jceTest <provider> <cipherAlg>
<keyAlg>");
    System.out.println("default alg:" + ALG);
    try {

      if (args.length == 0) {
        keyGenTest(ALG, null);
      } else if (args.length == 1) {
        keyGenTest(ALG, args[0]);
      } else if (args.length == 2) {
        keyGenTest(args[1], args[0]);
      }
    } catch (Exception e) {
      e.printStackTrace();
    }
  }
}
---------- END SOURCE ----------

CUSTOMER WORKAROUND :
Add the SUN provider in java.security file.
(Review ID: 139539) 
======================================================================

Name: nt126004			Date: 03/15/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :Microsoft Windows 2000
[Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
When installing a new Security provider, if you change the
ordering so that the default security provider is not Sun,
when you try to initialize a javax.crypto.KeyGenerator
object the VM throws the following Exception:
java.lang.ExceptionInInitializerError
	at javax.crypto.KeyGenerator.getInstance(DashoA6275)
	at
org.aowms.core.security.CryptographyManager.main(CryptographyManager.java:78)
Caused by: java.lang.SecurityException: Cannot set up certs
for trusted CAs: java.security.InvalidKeyException: Public
key presented not for certificate signature
	at javax.crypto.SunJCE_b.<clinit>(DashoA6275)
	... 2 more

This works:
security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.net.ssl.internal.ssl.Provider
security.provider.3=com.sun.rsajca.Provider
security.provider.4=com.sun.crypto.provider.SunJCE
security.provider.5=sun.security.jgss.SunProvider
security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider

This does not work:
security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.2=sun.security.provider.Sun
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.rsajca.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.Add a new Security provider to the java.security file
2.Change the security provider preferences so that the new
Security Provider is first
3.Try to create an instance of javax.crypto.KeyGenerator

EXPECTED VERSUS ACTUAL BEHAVIOR :
I didn't expect the VM to get fussy about which Provider
comes first.  The logic behind having a numbering scheme is
to allow you to set a default provider and add additional
providers as necessary without explicit coding.  This
simplifies coding because I don't have to manually code in
which provider I wan't to default to.  I don't want the Sun
provider to be my default provider and I should be able to
specify that via the java.security file without writing more
code.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.ExceptionInInitializerError
	at javax.crypto.KeyGenerator.getInstance(DashoA6275)
	at org.aowms.core.security.CryptographyManager.main(CryptographyManager.java:78)
Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs:
java.security.InvalidKeyException: Public key presented not for certificate
signature
	at javax.crypto.SunJCE_b.<clinit>(DashoA6275)
	... 2 mor

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.crypto.*;

/**
Note: The main method of this test case class is the exact same method of the
CryptographyManager class listed in the StackTrace of the 'Error Messages' field.
line 78 of the CryptographyManager class is line 3 of this test case class.
*/
public class CyrptoCrash
{
   public static void main( String[] args ) throws Exception
    {
        KeyGenerator keyGenerator = KeyGenerator.getInstance( "Blowfish", "BC" );
        keyGenerator.init( 128 );
        SecretKey key = keyGenerator.generateKey();
        System.out.println( keyGenerator.getProvider().getName() );
    }
}
---------- END SOURCE ----------

CUSTOMER WORKAROUND :
Don't re-order the security providers if adding a new one.
Add the new one to the end.
(Review ID: 144089)
======================================================================

Comments
EVALUATION ###@###.### 2002-04-03 Again, this is due to the chick-n-egg (signed) provider loading problem. Since this occurs during JCE's static security checkings, the exception is captured and reported as JCE "cannot setup certs" error. However, the real cause is bug#4504355 and once 4504355 is fixed, this bug will go away too. Given the above reason, I'll close this bug as a duplicate of 4504355.
01-09-2004