Closed Bug 732629 Opened 8 years ago Closed 7 years ago

crash report failed to send due to : javax.net.ssl.SSLException: Not trusted server certificate

Categories

(Infrastructure & Operations Graveyard :: WebOps: Other, task)

ARM
Android
task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nhirata, Assigned: nmaul)

References

Details

Attachments

(1 file)

Attached file full logcat
1. crashed due to doing some perf migration testing on droid 2.  Looked in logcat and found that the report didn't initially send due to untrusted server certificate.  Not sure if this makes a difference but the droid 2 is connected to Mozilla Mobile

03-02 16:13:20.747 I/GeckoCrashReporter( 2664): sendReport: /data/data/org.mozilla.fennec/files/mozilla/Crash Reports/pending/609d04ee-7645-5fb0-54a1f565-6eaf602b.dmp
03-02 16:13:20.747 I/GeckoCrashReporter( 2664): server url: https://crash-reports.mozilla.com/submit?id={aa3c5121-dab2-40e2-81ca-7ea25febc110}&version=13.0a1&buildid=20120302031112
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): exception during send: 
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): javax.net.ssl.SSLException: Not trusted server certificate
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): 	at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:382)
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): 	at org.apache.harmony.luni.internal.net.www.protocol.http.HttpConnection.getSecureSocket(HttpConnection.java:168)
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): 	at org.apache.harmony.luni.internal.net.www.protocol.https.HttpsURLConnectionImpl$HttpsEngine.connect(HttpsURLConnectionImpl.java:399)
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): 	at org.apache.harmony.luni.internal.net.www.protocol.http.HttpURLConnectionImpl.getOutputStream(HttpURLConnectionImpl.java:1253)
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): 	at org.apache.harmony.luni.internal.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:263)
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): 	at org.mozilla.fennec.CrashReporter.sendReport(CrashReporter.java:258)
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): 	at org.mozilla.fennec.CrashReporter.access$300(CrashReporter.java:69)
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): 	at org.mozilla.fennec.CrashReporter$2.run(CrashReporter.java:170)
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): 	at java.lang.Thread.run(Thread.java:1096)
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): Caused by: java.security.cert.CertificateException: java.security.cert.CertPathValidatorException: TrustAnchor for CertPath not found.
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): 	at org.apache.harmony.xnet.provider.jsse.TrustManagerImpl.checkServerTrusted(TrustManagerImpl.java:168)
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): 	at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:377)
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): 	... 8 more
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): Caused by: java.security.cert.CertPathValidatorException: TrustAnchor for CertPath not found.
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): 	at org.bouncycastle.jce.provider.PKIXCertPathValidatorSpi.engineValidate(PKIXCertPathValidatorSpi.java:149)
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): 	at java.security.cert.CertPathValidator.validate(CertPathValidator.java:202)
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): 	at org.apache.harmony.xnet.provider.jsse.TrustManagerImpl.checkServerTrusted(TrustManagerImpl.java:164)
03-02 16:13:36.490 E/GeckoCrashReporter( 2664): 	... 9 more
03-02 16:13:36.536 W/WidgetAidService( 1914): BroadcastReceiver onReceive called
That's crazy. :-/ If you load https://crash-reports.mozilla.com/submit in the stock browser, does it give you an SSL error? I don't know what any of that Java spew means.
Duplicate of this bug: 738650
Duplicate of this bug: 753321
Seeing the same error on 2.2.1

(In reply to Ted Mielczarek [:ted] from comment #1)
> If you load https://crash-reports.mozilla.com/submit in
> the stock browser, does it give you an SSL error? I don't know what any of
> that Java spew means.
Yes, stock browser also gives "This certificate is not from a trusted authority" on crash-stats domain. http://code.google.com/p/android/issues/detail?id=10807 might be useful.
Okay, it sounds like we'd need to configure crash-reports.mozilla.org to have more intermediate certs in its cert chain.
Assignee: nobody → server-ops
Component: Breakpad Integration → Server Operations
Product: Toolkit → mozilla.org
QA Contact: jdow
Version: unspecified → other
Assignee: server-ops → server-ops-webops
Component: Server Operations → Server Operations: Web Operations
QA Contact: jdow → cshields
First off, please everyone be careful about the exact domain... it looks like there's been some confusion in previous comments with respect to com vs org, stats vs reports, etc. :)

I'm not sure what we can do here. crash-stats.mozilla.com and crash-reports.mozilla.com are both configured to return multiple intermediate certs:

Both certs are signed by "GeoTrust SSL CA"
"GeoTrust SSL CA" is signed by "GeoTrust Global CA"
"GeoTrust Global CA" is signed by Equifax

Zeus is configured to return both intermediates, for both sites.

The GeoTrust Global CA is included in most things, but not Android 2.2. However, supposedly the Equifax cert *is*... so it should work. :/


Another site which uses the same cert chain is bugzilla.mozilla.org. How does that work for you?


With the Android emulator running the 2.2 (Froyo) SDK, I'm able to use crash-stats.mozilla.com, crash-reports.mozilla.com, and bugzilla.mozilla.org over SSL without any warnings. It could be the emulator uses a non-standard CA store as compared to what phones actually ship with... don't know.


I found an even higher-level intermediate cert and included it for crash-reports.mozilla.com. I don't think it will help though... it's not really an intermediate cert, but a root cert. It is self-signed by Equifax. But in any case, let us know if this (https://crash-reports.mozilla.com/submit) is fixed now. If it is and bugzilla.mozilla.org and crash-stats.mozilla.com are both still broken, we can do the same thing to them.
Okay, it is in fact crash-reports.mozilla.com that we use in the client:
http://mxr.mozilla.org/mozilla-central/source/build/application.ini.in#44

Jake: this is clearly not an issue on all Android devices, since I've never hit it in my own testing. I'd guess that there are just a few poorly-configured devices shipping that hit this problem. Naoki is in Mountain View most of the time, so you might be able to track him down and get the phone he originally found the issue on.
I dont't get this stack in logcat any more.

I'm still confused though. Logcat showed me
 I/GeckoCrashReporter(14558): server url: https://crash-reports.mozilla.com/submit?id={aa3c5121-dab2-40e2-81ca-7ea25febc110}&version=17.0a1&buildid=20120726052803
after last crash, but I'm unable to find this crash (too early?). Can someone confirm that it actually made it to crash-stats? There is no related output after that line..
That line doesn't give you enough information to find the crash. The UUID in there is the application ID of Firefox.
In light of comment 7 and comment 8, I'm going to close this as resolved. If anyone can still replicate an SSL issue with either crah-stats or crash-reports, please re-open with details. Thanks!
Assignee: server-ops-webops → nmaul
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.