HowTo make Java 1.4 play nicely with the APACGrid CA

The problem

Upon installation of new host certs issued by the APACGrid CA, the site began failing the R-GMA Secure Connector SFT. From a WN, the following command is run:

/opt/edg/sbin/edg-java-security-tomcat-test.sh lcg-monitor.hpc.unimelb.edu.au 8443

which results in the following error:

javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: CA cert [Email=camanager@vpac.org,CN=APACGrid,OU=CA,O=APACGrid,C=AU] not found, rejecting certificate for [CN=lcg-monitor.hpc.unimelb.edu.au,OU=The University of Melbourne,O=APACGrid,C=AU]
at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA12275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA12275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA12275)
at org.edg.security.trustmanager.tomcat.TryAuthentication.main(TryAuthentication.java:166)
Caused by: java.security.cert.CertificateException: CA cert [Email=camanager@vpac.org,CN=APACGrid,OU=CA,O=APACGrid,C=AU] not found, rejecting certificate for [CN=lcg-monitor.hpc.unimelb.edu.au,OU=The University of Melbourne,O=APACGrid,C=AU]
at org.edg.security.trustmanager.ProxyCertPathValidator.check(ProxyCertPathValidator.java:205)
at org.edg.security.trustmanager.CRLFileTrustManager.checkClientTrusted(CRLFileTrustManager.java:114)
at org.edg.security.trustmanager.CRLFileTrustManager.checkServerTrusted(CRLFileTrustManager.java:161)
at com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(DashoA12275)
... 8 more

SSL handshake failed, reason: java.security.cert.CertificateException: CA cert [Email=camanager@vpac.org,CN=APACGrid,OU=CA,O=APACGrid,C=AU] not found, rejecting certificate for [CN=lcg-monitor.hpc.unimelb.edu.au,OU=The University of Melbourne,O=APACGrid,C=AU]

Trying to find more info...

Server sent cert chain:
CN=lcg-monitor.hpc.unimelb.edu.au,OU=The University of Melbourne,O=APACGrid,C=AU

Did not receive any CA names for handshake

Cipher being used = Unknown 0x0:0x0

Info finding failed, reason: peer not authenticated
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificateChain(DashoA12275)
at org.edg.security.trustmanager.tomcat.TryAuthentication.main(TryAuthentication.java:237)

The problem is that the APACGrid CA root public key is 4096 bits. However, standard JAVA-1.4 doesn't like keys greater than 1024 bits.

The Solution

SUN offers an updated:

Java Cryptography Extension (JCE)
Unlimited Strength Jurisdiction Policy Files 1.4.2

However, it turns out that it can only handle keys up to 2048 bits.

So - with certs issued by the APACGrid CA we still have issues.

As this problem is on the client side, any client which uses JAVA-1.4 to check the authenticity of certs issued by the APACGrid CA has 2 options:
1. upgrade to Java-1.5: by default it can handle the 4096 bit keys (maybe also longer but haven't checked).
2. force java to use the bouncycastle cryptography extensions.

To do this, edit the file: "/usr/java/j2sdk1.4.2_08/jre/lib/security/java.security" applying the following patch (produced by diff -u ${original version} ${new version}):

--- java.security.ORIG  2006-12-09 13:56:53.000000000 +0000
+++ java.security       2006-10-29 05:55:31.000000000 +0000
@@ -45,10 +45,11 @@
 # List of providers and their preference orders (see above):
 #
 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.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

 #
 # Select the source of seed data for SecureRandom. By default an

That should fix all the problems!

As an aside: None of the hosts in the Australian T2 can currently download grid-mapfiles from lcg-voms.cern.ch as the authentication fails when the VOMS server receives the T2 hostcerts (I'm assuming it uses Java-1.4 without the aforementioned fix).