SSLPeerUnverifiedException from DropboxAPI in Android

[William M.46]

I haven't tried all possible calls, but for both the metadata() and search() methods of the DropboxAPI class in Android, I am being hit with an SSLPeerUnverifiedException using both a Samsung Galaxy Tab Pro and an HTC One M8 device. Both are on relatively recent Android builds.

com.dropbox.client2.exception.DropboxSSLException: javax.net.ssl.SSLPeerUnverifiedException: No peer certificate
        at com.dropbox.client2.RESTUtility.execute(RESTUtility.java:420)
        at com.dropbox.client2.RESTUtility.execute(RESTUtility.java:339)
        at com.dropbox.client2.RESTUtility.streamRequest(RESTUtility.java:194)
        at com.dropbox.client2.RESTUtility.request(RESTUtility.java:124)
        at com.dropbox.client2.DropboxAPI.metadata(DropboxAPI.java:1919)
        at com.xxxx.DAL.DropBoxAuthenticator$DropboxLister.listFiles(DropBoxAuthenticator.java:262)
        at com.xxxx.DAL.DropBoxAuthenticator$DropboxLister.doInBackground(DropBoxAuthenticator.java:233)
        at com.xxxx.DAL.DropBoxAuthenticator$DropboxLister.doInBackground(DropBoxAuthenticator.java:227)
        at android.os.AsyncTask$2.call(AsyncTask.java)
        at java.util.concurrent.FutureTask.run(FutureTask.java)
        at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java)
        at java.lang.Thread.run(Thread.java)
 Caused by: javax.net.ssl.SSLPeerUnverifiedException: No peer certificate
        at com.android.org.conscrypt.SSLNullSession.getPeerCertificates(SSLNullSession.java)
        at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java)
        at com.dropbox.client2.SecureSSLSocketFactory.createSocket(SecureSSLSocketFactory.java:164)
        at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java)
        at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java)
        at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java)
        at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java)
        at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java)
        at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java)
        at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java)
        at com.dropbox.client2.RESTUtility.execute(RESTUtility.java:387)
        at com.dropbox.client2.RESTUtility.execute(RESTUtility.java:339)
        at com.dropbox.client2.RESTUtility.streamRequest(RESTUtility.java:194)
        at com.dropbox.client2.RESTUtility.request(RESTUtility.java:124)
        at com.dropbox.client2.DropboxAPI.metadata(DropboxAPI.java:1919)
        at com.xxxx.DAL.DropBoxAuthenticator$DropboxLister.listFiles(DropBoxAuthenticator.java:262)
        at com.xxxx.DAL.DropBoxAuthenticator$DropboxLister.doInBackground(DropBoxAuthenticator.java:233)
        at com.xxxx.DAL.DropBoxAuthenticator$DropboxLister.doInBackground(DropBoxAuthenticator.java:227)
        at android.os.AsyncTask$2.call(AsyncTask.java)
        at java.util.concurrent.FutureTask.run(FutureTask.java)
        at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java)
        at java.lang.Thread.run(Thread.java)

I searched the fora, and haven't seen this as a common problem.

One possibility is that my OAuth2 code is off, but that error doesn't seem to apply. I'm not clear why, but the Dropbox permission screen does not reliably return to my activity. Are there errors I can check for with my subsequent execution instance calls to the AndroidAuthSession(appKeyPair, oAuth2Token) constructor? My understanding is that I then pass that session to the DropboxAPI<AndroidAuthSession>() to get my DropboxAPI, but that I don't need to call DropboxApi.finishAuthentication() in this case. Correct?

[William M.46]

Greg, re: your screenshot at https://www.dropbox.com/s/r2u82pm61kakjr0/Screenshot%202015-01-05%2010.47.35.png?dl=0
That doesn't match the current webserver certificate. They have different expirations, for example, and it looks to me like the web one is via DigiCert. What is the endpoint matching the Dropbox REST calls?

The reason I ask/checked is that, deep in the annals of history, many mobile devices had trouble with GoDaddy certs when there was a missing intermediate that had not gotten installed into their ROMs. I figured perhaps an easy fix would be to install a missing certificate, but don't see one.

[Greg-DB]

Thanks for posting the details. Agreed that this probably isn't related to anything at the OAuth level, as it seems this is failing to create the secure connection in the first place.

Also, there are some cases where the app authorization flow can fail to return to your activity, but that should be unrelated to the SSL exception you're seeing here on the API calls themselves. (But yes, for reference, when you're explicitly setting the access token via that constructor, you don't need to call finishAuthentication.)

And yes, the certificates have changed. You can check the latest ones for the web server at www.dropbox.com. The /metadata and /search API calls run from api.dropbox.com, so you can check the certificates for the API there. From what I can see, everything is still being served with valid certificates.

You mentioned two devices where you're seeing this issue. To clarify, are you only seeing this on these two devices but have it working on others, or are these the only ones you've tried?

[William M.46]

Thanks, Greg. These are the only two devices I have immediately handy.

But... I think I've found a correlation. It seems to be a timing, or perhaps debugger, problem, not a certificate problem. Running the same code in a release build with no tracing or breakpoints behaves more as expected. It does sacrifice the ability to set breakpoints and debug, but at least I can avoid that particular error.