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
