Title: Message Title
|
|
|
|
|
|
The first time you build (mvn package) the DSpace Replication Task Suite (dspace-replicate), it may fail with the following error:
Could not transfer artifact org.duracloud:storeclient:pom:2.3.1 from/to duracloud-releases (https://m2.duraspace.org/content/repositories/releases): sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
...
Caused by: org.apache.maven.wagon.TransferFailedException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Unfortunately, the problem is with the current "m2.duraspace.org" SSL Certificate. https://m2.duraspace.org is the only place the DuraCloud APIs are currently available via Maven (and the Replication Task Suite uses these APIs to communicate with DuraCloud, when it is configured as the backend).
The problematic SSL certificate is a SHA-2 certificate signed by GoDaddy, and unfortunately these certificates have known issues with Java/Maven. The reason is that GoDaddy has failed to add their signing certificate to the default Java Truststore. So, while our SSL Certificate is completely valid, Java will not trust it as it cannot validate the certificate using the default truststore.
Here are others who have encountered this same issue with GoDaddy-signed SHA-2 certificates and Java:
* http://stackoverflow.com/a/21117993
* http://tomcat.10.x6.nabble.com/Valid-certificate-chain-failing-with-quot-unable-to-find-valid-certification-path-to-requested-quot-td5015340.html
To complicate things, GoDaddy has announced that they are no longer supporting SHA-1 certificates (which work correctly with Java). Because of this new requirement, our certificate was updated from SHA-1 to SHA-2 automatically on the last renewal: http://support.godaddy.com/help/article/4818/information-about-requiring-the-sha-2-hash-function?locale=en
The only known workaround is to manually add the GoDaddy certificates to your local server's truststore. Unfortunately this must be done on each individual computer/server. Here's details on how to manually install the proper GoDaddy certificate into your 'cacerts' file on each computer:
http://notes.richdougherty.com/2013/09/adding-godaddy-g2-root-cert-to-jdk-7.html
NOTE: the two certificates in question (gdroot-g2.crt and gdig2.crt) are both available for download here: https://certs.godaddy.com/anonymous/repository.pki
(UPDATE: I've found you should only need to manually install the 'gdig2.crt', named "GoDaddy Secure Server Certificate (Intermediate Certificate) - G2". The root certificate should already exist in the truststore by default.)
DuraSpace is getting in touch with GoDaddy about this issue. If we cannot get a better fix from them, we may consider moving to a different certificate authority. In the meantime, unfortunately using the above workaround seems to be the only way to resolve the issue with the dspace-replicate build process.
|
|
|
|
|
|
|
|
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
