Grails

Codehaus changed root CA to untrusted SmartCom: affects plugin resolution and publishing

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Blocker Blocker
  • Resolution: Unresolved
  • Affects Version/s: 1.2.3, 1.3.2
  • Fix Version/s: 1.2.5
  • Component/s: Plugins
  • Description:
    Hide

    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

    Show
    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

Activity

Hide
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

Show
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
Hide
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.

Show
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.
Hide
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?

Show
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?
Hide
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.

Show
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.
Hide
Graeme Rocher added a comment - 30/Jul/10 8:00 AM

This problem was made worse by the fact we were publishing plugin download URLs with HTTPS instead of HTTP which has been fixed by this commit:

http://github.com/grails/grails-core/commit/2a9fa205db6359bec4537b74a50dd1ec84c910f4

Show
Graeme Rocher added a comment - 30/Jul/10 8:00 AM This problem was made worse by the fact we were publishing plugin download URLs with HTTPS instead of HTTP which has been fixed by this commit: http://github.com/grails/grails-core/commit/2a9fa205db6359bec4537b74a50dd1ec84c910f4
Hide
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.

Show
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.
Hide
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.

Show
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.
Hide
Lari Hotari added a comment - 11/Aug/10 5:22 AM

Importing StartCom certificates in unix:

wget http://www.startssl.com/certs/ca.pem
wget http://www.startssl.com/certs/sub.class2.server.ca.pem
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

Testing from command line:

groovy -e "println new URL('https://svn.codehaus.org/grails-plugins/.plugin-meta/plugins-list.xml').openConnection().date"
Show
Lari Hotari added a comment - 11/Aug/10 5:22 AM Importing StartCom certificates in unix:
wget http://www.startssl.com/certs/ca.pem
wget http://www.startssl.com/certs/sub.class2.server.ca.pem
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
Testing from command line:
groovy -e "println new URL('https://svn.codehaus.org/grails-plugins/.plugin-meta/plugins-list.xml').openConnection().date"
Hide
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

Show
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
Hide
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.

Show
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.
Hide
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.

Show
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.

People

Dates

  • Created:
    05/Jul/10 3:10 AM
    Updated:
    26/Aug/10 6:12 PM