1

I have a piece of code in an Android application which sends data to my server (to an HTTPS url) as such:

private void sendData(String serverUrl, byte[] message) {

    HttpURLConnection conn = null;

    try {
        URL url = new URL(serverUrl);
        conn = (HttpURLConnection) url.openConnection();
        conn.setDoInput(true);
        conn.setDoOutput(true);
        conn.setRequestMethod("POST");
        conn.setFixedLengthStreamingMode(message.length);
        conn.setRequestProperty("Content-Type", "application/json;charset=utf-8");
        conn.setRequestProperty("X-Requested-With", "XMLHttpRequest");

        OutputStream os = new BufferedOutputStream(conn.getOutputStream());
        os.write(message);

        os.flush();
        conn.connect();

    } catch (Exception e) {
        //TODO: log exception and continue gracefully
    } finally {
        if (conn != null)
           conn.disconnect();
    }
}

However, I keep seeing the following exception occurring from time to time sporadically on some devices (usually Samsung with Jelly Beans versions [SDK 16, 17 or 18]):

org.apache.harmony.security.asn1.ASN1Exception: Wrong content for ASN.1 integer at [15].
An integer MUST be encoded in minimum number of octets
java.lang.RuntimeException: org.apache.harmony.security.asn1.ASN1Exception:
Wrong content for ASN.1 integer at [15]. An integer MUST be encoded in minimum number of octets
    at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.verifyCertificateChain(OpenSSLSocketImpl.java:586)
    at org.apache.harmony.xnet.provider.jsse.NativeCrypto.SSL_do_handshake(Native Method)
    at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:371)
    at libcore.net.http.HttpConnection.setupSecureSocket(HttpConnection.java:209)
    at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.makeSslConnection(HttpsURLConnectionImpl.java:478)
    at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.connect(HttpsURLConnectionImpl.java:433)
    at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:289)
    at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:239)
    at libcore.net.http.HttpURLConnectionImpl.connect(HttpURLConnectionImpl.java:80)
    at libcore.net.http.HttpURLConnectionImpl.getOutputStream(HttpURLConnectionImpl.java:188)
    at libcore.net.http.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:281)
    at com.myapp.Reporter.sendData(Reporter.java:45)

I've searched the internet and google high and low but could not figure out what this means or how to resolve it.

Anyone has any idea?

Ori Lentz
  • 3,668
  • 6
  • 22
  • 28
  • I will suggest you to use volley library for all your network calls. Its easy to use and less complicated.http://developer.android.com/training/volley/index.html – Arshad Feb 25 '16 at 08:48
  • Thanks. However my code resides as a third party in the application, I can't assume it uses volley and I don't want to add it as a dependency. – Ori Lentz Feb 25 '16 at 08:49

2 Answers2

0

What the error is telling you is that some bad data has been encountered, apparently in a security certificate. There error is telling you that ASN.1 requires a particular integer value to be encoded in the minimum number of octets (bytes) possible. Either that has not been done (the certificate data is incorrect) or else Harmony is incorrectly reporting an error.

Kevin
  • 1,876
  • 12
  • 17
  • Yeah, thanks, I understood that. I'm just not clear about *why* this is happening. None of the other [https] network requests throw this exception. – Ori Lentz Feb 27 '16 at 14:40
0

Okay, I've finally figured it out.

The problem was with my server's SSL Certificate, which is why I was the only third party in the applications getting this error (my counterparts didn't come across this issue).

Basically, the problem is my certificate was purchased by GeoTrust Root CA, which was not installed as a trusted authority on some Jelly Bean devices, which is why I only saw this exception from APIs 16-18, a.k.a Android Jelly Bean.

I've also found confirmation for it in a comment posted to an answer of another SO question, which tackled the issue from a whole other perspective (I had no idea this was about certificates).

Seeing as I can't (= don't want to) install a certificate on someone's device, as seeing as the error occurs sporadically on old devices and at most 5-6 times a day (usually once or twice is the norm), I saw not need in purchasing another certificate from an authority that is defined as trusted in Jelly Bean devices. Also, for these reasons, I've decided to not handle the problem and basically lose data coming from these devices, seeing as they amount to less than 1% of users. I should note, of course, that I am catching these exceptions and sending them to me, but they are not crashing the app, which is why I feel more comfortable not handling this matter.

Community
  • 1
  • 1
Ori Lentz
  • 3,668
  • 6
  • 22
  • 28