That is the self-signed certificate problem. The code here will download the certificate and install it in the keystore for the JVM it is running in: http://code.google.com/p/educationau-utils/source/browse/trunk/java/EdAuUtils/src/main/java/au/edu/educationau/opensource/ssl/InstallCert.java
This code is useful for debugging SSL problems in Java: http://code.google.com/p/educationau-utils/source/browse/trunk/java/EdAuUtils/src/main/java/au/edu/educationau/opensource/ssl/SSLPoke.java Nick On Fri, May 25, 2012 at 7:59 AM, Greg <z-launch...@brim.net> wrote: > It is mostly the likely the self-signed certificate issue you suspected. Java > (and other languages) are pretty notorious for rejecting such unless you > configure them just right. I haven't worked with Java in 10 years, so my > knowledge of how to fix that is pretty useless, hopefully another will speak > up and help. You probably had to use -k with curl right? That would confirm > the self-signed issue. > > Just as a note, the SSL capabilities for the Swift proxy server are truly for > basic testing only. You might want to start with non-SSL and then lock it > down after you get things working otherwise. > > For SSL capabilities, an SSL-terminating load balancer in front of the Swift > proxy servers is recommended. You /could/ use DNS-round-robin balancing to > proxies with SSL turned on, but like I mentioned, that's really just for > testing purposes. In a production deployment, you'd definitely want SSL > terminated at the load balancer(s). > > Now, which load balancers to use is a whole other email thread, so I won't > mention that for now, you may already have particular requirements in mind > anyway. > > > On May 24, 2012, at 3:03 PM, Shawn Heisey wrote: > >> This question is probably more appropriate for the Swift mailing list, but I >> could not figure out how to subscribe to that list, so it's going here. I'm >> OK with moving it there, if someone can tell me how to get subscribed, or if >> I'm in completely the wrong place, let me know. >> >> I am attempting to evaluate Swift for our environment. I have set up a >> Swift cluster using the ubuntu multi-server HOWTO and I can use the >> commandline utilities to upload and download files. Now I need to do a test >> using the Java API. I downloaded java-cloudfiles and I can't seem to make >> it work. It fails at the login() step. >> >> FilesClient client = new FilesClient(username, password, authUrl, >> null, 10000); >> if (client.login()) >> { >> >> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated >> at >> com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352) >> at >> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128) >> at >> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:397) >> at >> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148) >> at >> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:150) >> at >> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121) >> at >> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:575) >> at >> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425) >> at >> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820) >> at >> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754) >> at >> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:732) >> at >> com.rackspacecloud.client.cloudfiles.FilesClient.login(FilesClient.java:278) >> at com.REDACTED.swiftest.Main.main(Main.java:50) >> >> This all works with the curl command using the same auth URL. I've got the >> default user/password set up from the HOWTO. >> >> Initially I suspected that the problem was due to the self-signed >> certificate, but watching syslog on the primary proxy server, I don't see >> any requests logged, but I do see a conversation happen on port 8080 with >> tcpdump. How can I troubleshoot this? >> >> Thanks, >> Shawn >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
