Codehaus have changed their root CA for their SSL certificates to SmartCom. Unfortunately, SmartCom is not one of the default trusted CAs in the JDK. This causes problems with Grails 1.2, which attempts to download plugins via HTTPS. So if a plugin is not cached locally, you get an SSLHandshakeException.
The SSL certficate also affects both 1.2.x and 1.3.x when publishing a plugin to the central Grails Plugin Repository.
Codehaus have changed their root CA for their SSL certificates to SmartCom. Unfortunately, SmartCom is not one of the default trusted CAs in the JDK. This causes problems with Grails 1.2, which attempts to download plugins via HTTPS. So if a plugin is not cached locally, you get an SSLHandshakeException.
The SSL certficate also affects both 1.2.x and 1.3.x when publishing a plugin to the central Grails Plugin Repository.
A solution is provided in this post: http://forum.startcom.org/viewtopic.php?f=15&t=1815
I don't see how the proposed solution is workable since we don't currently depend on commons-ssl or commons-httpclient. Seems a bit brute force to introduce a new dependency to solve the problem
Graeme Rocher added a comment - 05/Jul/10 9:18 AM I don't see how the proposed solution is workable since we don't currently depend on commons-ssl or commons-httpclient. Seems a bit brute force to introduce a new dependency to solve the problem
We may have to use Commons HttpClient so that Ivy can work against repositories that require authentication. I thought there was a related issue, but I can't find it.
Peter Ledbrook added a comment - 05/Jul/10 9:57 AM We may have to use Commons HttpClient so that Ivy can work against repositories that require authentication. I thought there was a related issue, but I can't find it.
Graeme Rocher added a comment - 05/Jul/10 10:28 AM I wonder if there is a way to test this, maybe adding the codehaus repository using https:// as a protocol?
I'm not sure this is something we can do with automated tests. Adding dependencies to external servers is asking for trouble. We could include some tests as part of a manual step (automated running of tests, but requiring manual initiation). Perhaps we could use VMs to help here? Create a VM image with Artifactory and a Subversion repository set up, then run the tests against that. Once the tests have completed, revert back to the original image.
Peter Ledbrook added a comment - 05/Jul/10 10:53 AM I'm not sure this is something we can do with automated tests. Adding dependencies to external servers is asking for trouble. We could include some tests as part of a manual step (automated running of tests, but requiring manual initiation). Perhaps we could use VMs to help here? Create a VM image with Artifactory and a Subversion repository set up, then run the tests against that. Once the tests have completed, revert back to the original image.
Stefan gets this output with HEAD when publishing a plugin from Ubuntu:
Committing code. Please wait...
Committed revision 63353.
Preparing to publish the release...
Tagging version release, please wait...
Copied trunk to https://svn.codehaus.org/grails-plugins/grails-neo4j/tags/RELEASE_0_3 with revision 63355 on Fri Jul 30 17:29:35 CEST 2010
Tagging latest release, please wait...
Copied trunk to https://svn.codehaus.org/grails-plugins/grails-neo4j/tags/LATEST_RELEASE with revision 63356 on Fri Jul 30 17:29:46 CEST 2010
[get] Getting: https://svn.codehaus.org/grails-plugins/.plugin-meta/plugins-list.xml
[get] To: /home/stefan/.grails/1.3.4.BUILD-SNAPSHOT/plugins-list-default.xml
[get] Error getting https://svn.codehaus.org/grails-plugins/.plugin-meta/plugins-list.xml to /home/stefan/.grails/1.3.4.BUILD-SNAPSHOT/plugins-list-default.xml
Error reading remote plugin list [javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target], building locally...
Plugins list cache doesn't exist creating..
Plugins list cache has expired. Updating, please wait ...
Note that the plugin was successfully released once the plugin list was rebuilt. It seems that SvnKit has no problem with Codehaus' new certificate, I suspect because it doesn't require SSL certificates to be trusted, simply valid.
It would be good to fix the problem with the plugin list though. There's no need to fetch it via SSL.
Peter Ledbrook added a comment - 30/Jul/10 11:14 AM Stefan gets this output with HEAD when publishing a plugin from Ubuntu:
Committing code. Please wait...
Committed revision 63353.
Preparing to publish the release...
Tagging version release, please wait...
Copied trunk to https://svn.codehaus.org/grails-plugins/grails-neo4j/tags/RELEASE_0_3 with revision 63355 on Fri Jul 30 17:29:35 CEST 2010
Tagging latest release, please wait...
Copied trunk to https://svn.codehaus.org/grails-plugins/grails-neo4j/tags/LATEST_RELEASE with revision 63356 on Fri Jul 30 17:29:46 CEST 2010
[get] Getting: https://svn.codehaus.org/grails-plugins/.plugin-meta/plugins-list.xml
[get] To: /home/stefan/.grails/1.3.4.BUILD-SNAPSHOT/plugins-list-default.xml
[get] Error getting https://svn.codehaus.org/grails-plugins/.plugin-meta/plugins-list.xml to /home/stefan/.grails/1.3.4.BUILD-SNAPSHOT/plugins-list-default.xml
Error reading remote plugin list [javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target], building locally...
Plugins list cache doesn't exist creating..
Plugins list cache has expired. Updating, please wait ...
Note that the plugin was successfully released once the plugin list was rebuilt. It seems that SvnKit has no problem with Codehaus' new certificate, I suspect because it doesn't require SSL certificates to be trusted, simply valid.
It would be good to fix the problem with the plugin list though. There's no need to fetch it via SSL.
At least for Ubuntu Lucid: Ubuntu manages cacertificates by package ca-certificates and ca-certificates-java. These packages store the ca certs in /etc/ssl/certs/java/cacerts. But java-6-sun basically uses /etc/java-6-sun/security/cacerts. So when symlinking /etc/java-6-sun/security/cacerts to /etc/ssl/certs/java/cacerts the SSL exception is gone.
Stefan Armbruster added a comment - 30/Jul/10 11:26 AM At least for Ubuntu Lucid: Ubuntu manages cacertificates by package ca-certificates and ca-certificates-java. These packages store the ca certs in /etc/ssl/certs/java/cacerts. But java-6-sun basically uses /etc/java-6-sun/security/cacerts. So when symlinking /etc/java-6-sun/security/cacerts to /etc/ssl/certs/java/cacerts the SSL exception is gone.
Tomas Lin added a comment - 20/Aug/10 6:56 AM - edited In Cygwin on Windows, same commands as Lari's above, except make sure you surround the $JAVA_HOME with ""
keytool -import -alias StartComCA -keystore "$JAVA_HOME/jre/lib/security/cacerts" -storepass changeit -file ca.pem
keytool -import -alias StartComClass2PrimaryIntermediateServerCA -keystore "$JAVA_HOME/jre/lib/security/cacerts" -storepass changeit -file sub.class2.server.ca.pem
Tomas, did you get an SSLHandshakeException when trying to publish your plugin? I'm trying to work out whether this is still an issue or not. There should be no reason for users to get the SSHandshakeException any more.
Peter Ledbrook added a comment - 20/Aug/10 10:39 AM Tomas, did you get an SSLHandshakeException when trying to publish your plugin? I'm trying to work out whether this is still an issue or not. There should be no reason for users to get the SSHandshakeException any more.
Tomas Lin added a comment - 23/Aug/10 4:12 AM Peter, yes, I got the SSLHandshakeException on both Grails 1.3.3. and Grails 1.3.4 on Windows Vista. My JDK version is
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode, sharing)
and my environment is Windows 7 Home Premium.
I don't see how the proposed solution is workable since we don't currently depend on commons-ssl or commons-httpclient. Seems a bit brute force to introduce a new dependency to solve the problem