Technical description of the problem ------------------------------------ Certificates signed with root keys with keylengths greater than 2048 bits are not recognized by all software that runs in the Tomcat containers and using glite trustnamager as the certificate verfying engine. This was confirmed with JDK 1.4 and Tomcat 5.x, the current versions of web-service containers and utility software in gLite and LCG2. Human-understandable description of the problem ----------------------------------------------- Certificates - that have their keylength to be greater than 2048 bits (no known EGEE-Grid examples yet) or - that are signed by the CA root key with the keylength greater than 2048 bits (old Russian DataGrid CA and SiGNET CA are the known examples) will be rejected with the weird error by all services that are using Java 1.4 and Tomcat 5.x. No such certificates can be used to authenticate user to such services and there is no user-side workaround, only the server-side one exists. What middleware is affected --------------------------- gLite 1.x, gLite 3.x, LCG2 2.x in their parts where webservices are used. Possible workarounds -------------------- It was discovered that installation of the "unlimited jurisdiction" JCE profiles and addition of BouncyCastle cryptoprovider to the stack of Java cryptoproviders enable users with the certificates, signed with the 4096 bit root keys, to establish SSL context with the web-services of the gLite 1.2. It is not known by me (Eygene Ryabinkin) wheither this hack affects some functionality of the underlying software, so it needs further testing by gLite developers. Here are the steps to be done to enable successful SSL negotiation: 1) Let the directories /usr/java/j2sdk1.4.2_08/jre/ and /usr/java/j2re1.4.2_08/ will be denoted as 2) Install BouncyCastle CryptoProvider jar (mine is bcprov-jdk14-129.jar) into /lib/ext 3) Install unlimited jurisdiction files into /lib/security 4) Change the file /lib/security/java.security and make the providers to be security.provider.1=sun.security.provider.Sun security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider 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 If I put BC provider as a provider number one, it is refusing to connect, saying that there are no common encryption algorithms. Putting it to be provider >= 3 it refuses to handle long keys. What was done ------------- This problem was raised a lengthy descussion between me (Eygene Ryabinkin), Joni Hankala, John White, Ian Nelson and Elena Slabospitskaya. During it was confirmed that the problem lies in the keylength of the root key, rather then in some specifics of the Russian DataGrid CA certificates. The last message sent to Joni Hankala and John White contained the request to check the proposed workaround for this bug. There were no response since the start of August 2005. In the middle of the 2006 Joni Hankala responded, that the RFC recommendations are telling that the sensible key lengths for the CA keys are no longer than 2048 for the next decade, so it is not wise to support longer keys. -- Eygene Ryabinkin, RRC KI