S3ServiceException, caused by SSLHandshakeException

773 views
Skip to first unread message

casimir

unread,
May 6, 2009, 4:01:54 AM5/6/09
to JetS3t Users, l...@colorjinn.com
Please can anyone help, or explain:

My application connects to the database of an instance on EC2, using
SSL.
It uses some info from that database and next it needs to upload files
to AmazonS3, using jets3t.

Strange enough when I try to list the bucket in my S3 account,
before I connect to the database, everything works fine.
But if I first create a connection to the database and than create a
service object and try:
bucket = service.getBucket(mybucket);

I get the following error:

(BTW, I use Mac OSX 10.5 and use java 1.5, which is the highest
version I can install on this mac)

6-mei-2009 0:51:30 org.apache.commons.httpclient.HttpMethodDirector
executeWithRetry
INFO: I/O exception (javax.net.ssl.SSLHandshakeException) caught when
processing request: sun.security.validator.ValidatorException: PKIX
path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
6-mei-2009 0:51:30 org.apache.commons.httpclient.HttpMethodDirector
executeWithRetry
.....
INFO: Retrying request
6-mei-2009 0:51:31 org.jets3t.service.utils.RestUtils$1 retryMethod
WARNING: Retried connection 6 times, which exceeds the maximum retry
count of 5

org.jets3t.service.S3ServiceException: S3 GET connection failed for
'/'
at
org.jets3t.service.impl.rest.httpclient.RestS3Service.performRequest
(RestS3Service.java:491)
at
org.jets3t.service.impl.rest.httpclient.RestS3Service.performRestGet
(RestS3Service.java:727)
at
org.jets3t.service.impl.rest.httpclient.RestS3Service.listAllBucketsImpl
(RestS3Service.java:1010)
at org.jets3t.service.S3Service.listAllBuckets(S3Service.java:1329)
at org.jets3t.service.S3Service.getBucket(S3Service.java:1506)
at sites.editsite.aws.AmazonS3Uploader.<init>(AmazonS3Uploader.java:
50)
at documentbuilder.DefaultView$1.stateChanged(DefaultView.java:66)
at javax.swing.JTabbedPane.fireStateChanged(JTabbedPane.java:290)
at javax.swing.JTabbedPane$ModelListener.stateChanged
(JTabbedPane.java:222)
at javax.swing.DefaultSingleSelectionModel.fireStateChanged
(DefaultSingleSelectionModel.java:116)
at javax.swing.DefaultSingleSelectionModel.setSelectedIndex
(DefaultSingleSelectionModel.java:50)
at javax.swing.JTabbedPane.setSelectedIndexImpl(JTabbedPane.java:478)
at javax.swing.JTabbedPane.setSelectedIndex(JTabbedPane.java:464)
at apple.laf.CUIAquaTabbedPane$MouseHandler.mouseReleased
(CUIAquaTabbedPane.java:834)
at java.awt.Component.processMouseEvent(Component.java:5602)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3135)
at java.awt.Component.processEvent(Component.java:5367)
at java.awt.Container.processEvent(Container.java:2010)
at java.awt.Component.dispatchEventImpl(Component.java:4068)
at java.awt.Container.dispatchEventImpl(Container.java:2068)
at java.awt.Component.dispatchEvent(Component.java:3903)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:
4256)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:
3936)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866)
at java.awt.Container.dispatchEventImpl(Container.java:2054)
at java.awt.Window.dispatchEventImpl(Window.java:1801)
at java.awt.Component.dispatchEvent(Component.java:3903)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy
(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForHierarchy
(EventDispatchThread.java:190)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:
184)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:
176)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
Caused by: 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
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:
150)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal
(SSLSocketImpl.java:1518)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:
174)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:
168)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate
(ClientHandshaker.java:848)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage
(ClientHandshaker.java:106)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop
(Handshaker.java:495)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record
(Handshaker.java:433)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord
(SSLSocketImpl.java:818)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake
(SSLSocketImpl.java:1030)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord
(SSLSocketImpl.java:622)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write
(AppOutputStream.java:59)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:
65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at
org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream
(HttpConnection.java:828)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager
$HttpConnectionAdapter.flushRequestOutputStream
(MultiThreadedHttpConnectionManager.java:1565)
at org.apache.commons.httpclient.HttpMethodBase.writeRequest
(HttpMethodBase.java:2116)
at org.apache.commons.httpclient.HttpMethodBase.execute
(HttpMethodBase.java:1096)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry
(HttpMethodDirector.java:398)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod
(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod
(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod
(HttpClient.java:323)
at
org.jets3t.service.impl.rest.httpclient.RestS3Service.performRequest
(RestS3Service.java:325)
... 32 more
Caused by: sun.security.validator.ValidatorException: PKIX path
building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:
221)
at sun.security.validator.PKIXValidator.engineValidate
(PKIXValidator.java:145)
at sun.security.validator.Validator.validate(Validator.java:203)
at
com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted
(X509TrustManagerImpl.java:172)
at
com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted
(SSLContextImpl.java:320)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate
(ClientHandshaker.java:841)
... 50 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild
(SunCertPathBuilder.java:236)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:194)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:
216)
... 55 more


Laxmilal Menaria

unread,
May 6, 2009, 8:31:39 AM5/6/09
to JetS3t Users
Please upgrade to Java 6 and try again.

-LM

James Murty

unread,
May 6, 2009, 12:45:39 PM5/6/09
to jets3t...@googlegroups.com, l...@colorjinn.com
It sounds like the Java cacerts database on your EC2 instance is either corrupted, or is outdated and doesn't have the latest top-level CA certificates necessary to verify Amazon's certificate.

Alternately, you may be running your app within some software (eg. a web app container) which uses a non-default cacerts database?

Regardless of the cause, the solution will be much the same. Identify the cacerts database file and ensure it has the latest top-level CA cert used by Amazon (Verisign I think?). This problem isn't specific to JetS3t -- it will affect any Java-based software that communicates with Amazon's secure services.

Here are some links I've googled up which may help:

http://solutions.amazonwebservices.com/connect/message.jspa?messageID=57320

http://groups.google.com/group/typica/browse_thread/thread/db040615f6330ac1

James

---
http://www.jamesmurty.com

casimir

unread,
May 6, 2009, 4:32:50 PM5/6/09
to JetS3t Users
I can't run Java 6 on my Mac, Java 5 is the highest version...

casimir

unread,
May 6, 2009, 5:01:32 PM5/6/09
to JetS3t Users
First of all I like to thank you James, although your research didn't
solve my problem.

But I am a little further: currently I can run the app!
I edited the jets3t.properties: s3service.https-only=false
After that the app runs, But is this a good idea?...

Still I don't understand the following:
If I set: s3service.https-only=true
I can run my java class (S3Uploader.java) to access my buckets.
Also I can access my database on an EC2 instance if I run separately:
DBconnector.java.

But only if I use both java files in one application
(MyApplication.java uses: S3Uploader.java and DBconnector.java)
I get the error mentioned above and I do need to set: s3service.https-
only=false

Can anyone explain?


On 6 mei, 18:45, James Murty <jamu...@gmail.com> wrote:
> It sounds like the Java cacerts database on your EC2 instance is either
> corrupted, or is outdated and doesn't have the latest top-level CA
> certificates necessary to verify Amazon's certificate.
>
> Alternately, you may be running your app within some software (eg. a web app
> container) which uses a non-default cacerts database?
>
> Regardless of the cause, the solution will be much the same. Identify the
> cacerts database file and ensure it has the latest top-level CA cert used by
> Amazon (Verisign I think?). This problem isn't specific to JetS3t -- it will
> affect any Java-based software that communicates with Amazon's secure
> services.
>
> Here are some links I've googled up which may help:
>
> http://solutions.amazonwebservices.com/connect/message.jspa?messageID...
>
> http://groups.google.com/group/typica/browse_thread/thread/db040615f6...
>
> James
>
> ---http://www.jamesmurty.com

James Murty

unread,
May 6, 2009, 5:10:14 PM5/6/09
to jets3t...@googlegroups.com
I would guess it's some kind of path problem when you run the combined
application, though that's only a guess.

Try running your S3 code in the combined app without the DB code to
see if the problem is specific to the app as a whole, or is somehow
related to the DB connection process.

Running with Https disabled is not a good idea if you have sensitive
data, but for non-sensitive data it won't be a problem.

James

--
---
http://www.jamesmurty.com

casimir

unread,
May 12, 2009, 6:52:05 AM5/12/09
to JetS3t Users, l...@colorjinn.com
If I run S3 code in the combined app without the DB code I can use
https without problems.
So I think the problem is related to the DB connection process.

And the fact is that I only use non-sensitive data, so I could use
http.

But James, can you assure that next items are not accessible by others
if I do not use https?
DB: keyStore,trustStore and db passwords
S3: access and secret keys

Thanks in advance,
Casimir

James Murty

unread,
May 12, 2009, 12:43:59 PM5/12/09
to jets3t...@googlegroups.com, l...@colorjinn.com
If the data you are storing in S3 is not sensitive then you will be fine using HTTP. Your AWS access key will be revealed in non-secure S3 traffic, but your secret key is not revealed and will be safe.

I don't know anything about the database you are using or how you are connecting to it, so I can't comment on the security or otherwise of any data you store there.

My feeling is that something in your database accessing code or libraries must be screwy and, while it seems like it only affects HTTPS S3 connections now, there could be other side-effects that will bite you later. It's probably worth investing some effort to fix the underlying problem rather than just ignoring it.

James

James Murty

unread,
May 12, 2009, 1:09:57 PM5/12/09
to jets3t...@googlegroups.com, l...@colorjinn.com
Just a tip that might help you to figure this out...

If your database connection is indeed changing the default keystore file used for certificate verification, it is probably doing so by overwriting the following Java system properties:

javax.net.ssl.trustStore  (kestore with certificates of servers you trust, e.g. S3)
javax.net.ssl.keyStore   (your own certificates, probably not relevant here)

Try printing out these system property values after the DB connection. With luck the values will indicate which keystore file is actually being used *after* the DB code does its thing, in which case you can just import the S3 certificate (or preferably its root CA) into that file instead of the default Java one.

There is more info about the lookup path for the Java trust keystore here:
http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#X509TrustManager

Hope this helps,
James

casimir

unread,
May 12, 2009, 1:12:14 PM5/12/09
to JetS3t Users
Thanks again, James

I will check the database connection.

BTW:
I use a mysql database.
Library: mysql-connector-java-5.1.6-bin.jar.
Connection url = "jdbc:mysql://myHost/DB?useSSL=true&requireSSL=true";
The javax.net.ssl.keyStore and trustStore I got from the DB-
administrator.

Casimir

On 12 mei, 18:43, James Murty <jamu...@gmail.com> wrote:
> If the data you are storing in S3 is not sensitive then you will be fine
> using HTTP. Your AWS access key will be revealed in non-secure S3 traffic,
> but your secret key is not revealed and will be safe.
>
> I don't know anything about the database you are using or how you are
> connecting to it, so I can't comment on the security or otherwise of any
> data you store there.
>
> My feeling is that something in your database accessing code or libraries
> must be screwy and, while it seems like it only affects HTTPS S3 connections
> now, there could be other side-effects that will bite you later. It's
> probably worth investing some effort to fix the underlying problem rather
> than just ignoring it.
>
> James
>

James Murty

unread,
May 12, 2009, 1:18:34 PM5/12/09
to jets3t...@googlegroups.com
If you are using a custom keystore, that explains the issue. You will need to import the S3 certificate (or its root CA) into whichever truststore your application is using.
Reply all
Reply to author
Forward
0 new messages