Problem connecting via SSL (self-signed certificate, custom port)

[tobedeleted 4]

I run my Emby server for external use over SSL. I use a self-signed certificate and a custom port for that. Everything is set up correctly. The certificate is imported into Android's internal certificate memory, so any app accepts it as genuine.

 

The Emby Android app worked fine until a few days ago. Now it claims that it cannot connect to the server (however connects fine if I point it to the unencrypted port). The server is up and running, as any device, including the Android apps, can connect to the SSL web page. Only the dedicated app does not work over SSL.

 

The only thing I can see in the logs of the Android app is a problem that it cannot connect to some in-app billing service. As I don't use Google apps (however own a lifetime supporter license of Emby), this is fine for me.

 

Has something changed in the Emby app concerning SSL connections?!

[Luke 37142]

Hi, no, please supply an app log:

 

http://emby.media/community/index.php?/topic/15638-how-to-report-an-android-problem/

 

Thanks.

[tobedeleted 4]

I'll post a log when I'm on the device again. However, as I said, there is no entry at all concerning the failing connection to the server in the log, only the error about in-app-billing.

[tobedeleted 4]

19:00:03.995 [main] INFO App - Searching for com.google.android.webview

19:00:04.004 [main] ERROR App - Android System WebView is not found

android.content.pm.PackageManager$NameNotFoundException

android.app.ApplicationPackageManager.getPackageInfo(ApplicationPackageManager.java:115)

com.mb.android.MainActivity.GetSystemWebViewChromiumVersion(MainActivity.java:174)

com.mb.android.MainActivity.enableSystemWebView(MainActivity.java:155)

com.mb.android.MainActivity.makeWebViewEngine(MainActivity.java:205)

org.apache.cordova.CordovaActivity.makeWebView(CordovaActivity.java:192)

org.apache.cordova.CordovaActivity.init(CordovaActivity.java:141)

org.apache.cordova.CordovaActivity.loadUrl(CordovaActivity.java:214)

com.mb.android.MainActivity.onCreate(MainActivity.java:123)

android.app.Activity.performCreate(Activity.java:5990)

android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1106)

android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2311)

android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2420)

android.app.ActivityThread.access$900(ActivityThread.java:154)

android.app.ActivityThread$H.handleMessage(ActivityThread.java:1321)

android.os.Handler.dispatchMessage(Handler.java:102)

android.os.Looper.loop(Looper.java:135)

android.app.ActivityThread.main(ActivityThread.java:5294)

java.lang.reflect.Method.invoke(Native Method)

java.lang.reflect.Method.invoke(Method.java:372)

com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:904)

com.android.internal.os.ZygoteInit.main(ZygoteInit.java:699)

de.robv.android.xposed.XposedBridge.main(XposedBridge.java:117)

19:00:04.005 [main] INFO App - Enabling Crosswalk due to older chromium version

19:00:04.036 [main] DEBUG App - AndroidSyncFileRepository started. syncPath: /storage/sdcard1/Android/data/com.mb.android/files

19:00:04.081 [main] INFO App - Searching for com.google.android.webview

19:00:04.082 [main] ERROR App - Android System WebView is not found

android.content.pm.PackageManager$NameNotFoundException

android.app.ApplicationPackageManager.getPackageInfo(ApplicationPackageManager.java:115)

com.mb.android.MainActivity.GetSystemWebViewChromiumVersion(MainActivity.java:174)

com.mb.android.MainActivity.enableSystemWebView(MainActivity.java:155)

com.mb.android.MainActivity.onCreate(MainActivity.java:130)

android.app.Activity.performCreate(Activity.java:5990)

android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1106)

android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2311)

android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2420)

android.app.ActivityThread.access$900(ActivityThread.java:154)

android.app.ActivityThread$H.handleMessage(ActivityThread.java:1321)

android.os.Handler.dispatchMessage(Handler.java:102)

android.os.Looper.loop(Looper.java:135)

android.app.ActivityThread.main(ActivityThread.java:5294)

java.lang.reflect.Method.invoke(Native Method)

java.lang.reflect.Method.invoke(Method.java:372)

com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:904)

com.android.internal.os.ZygoteInit.main(ZygoteInit.java:699)

de.robv.android.xposed.XposedBridge.main(XposedBridge.java:117)

19:00:04.085 [main] INFO App - Enabling Crosswalk due to older chromium version

19:00:04.851 [main] DEBUG App - Calling MediaSyncAdapter.updateSyncPreferences. syncPath: /storage/sdcard1/Android/data/com.mb.android/files

19:00:06.441 [JavaBridge] INFO App - Received instruction to updateCredentials

19:00:06.570 [JavaBridge] INFO App - AppVersion: 2.6.26

19:00:06.571 [JavaBridge] INFO App - DeviceId: 3ad38aa6-f457-67c8-3576-520677365358

19:00:06.571 [JavaBridge] INFO App - DeviceName: Xperia Z3C

19:00:06.947 [JavaBridge] INFO App - initStore called

19:00:06.949 [JavaBridge] DEBUG App - IAB helper created.

19:00:06.950 [JavaBridge] DEBUG App - Starting in-app billing setup.

19:00:06.952 [JavaBridge] ERROR App - Error intializing IAP Manager. Billing service unavailable on device. (response: 3:Billing Unavailable)

19:00:08.039 [JavaBridge] INFO App - initialize origin_scoped 2D4B1DA3 2D4B1DA3

19:00:08.039 [JavaBridge] INFO App - lastAppId 2D4B1DA3

19:00:08.525 [JavaBridge] INFO App - Received instruction to updateCredentials

19:00:08.651 [JavaBridge] INFO App - Received instruction to updateCredentials

19:00:25.828 [JavaBridge] INFO App - Received instruction to updateCredentials

19:00:27.948 [JavaBridge] INFO App - Received instruction to updateCredentials

19:00:28.970 [JavaBridge] INFO App - Received instruction to updateCredentials

[tobedeleted 4]

I tried it several times: The app seemingly does not even log why it can't connect to the SSL server. It just claims that the server is unreachable (which is wrong, as Firefox running in parallel on the same device connect...).

[tobedeleted 4]

Update: Chromium claims that the website has a certificate which is valid for a too long time (roughly translated, I guess my expiration date is too far in the future). It then connects nevertheless. Maybe there was some change in the SSL code which now makes this situation a problem?! Then the app should have a checkbox to trust the certificate nevertheless.

[NomadCF 15]

Update: Chromium claims that the website has a certificate which is valid for a too long time (roughly translated, I guess my expiration date is too far in the future). It then connects nevertheless. Maybe there was some change in the SSL code which now makes this situation a problem?! Then the app should have a checkbox to trust the certificate nevertheless.

 

Technically the new (1 yr ago) max "standard" for the lifetime or length a SSL cert can be valid for is 39 months. And Chrome out of all of them is the strictest about it's SSL certs and standards. That  all being said doesn't mean you can't have a cert that's declared valid for longer than 39 months (3 years). But that some software applications might have an issue with it (like chrome) where other won't like say when the OS is using a radius or proxy authority certs.

 

A lot (if not almost all) of software that isn't a browser hides any connection information from the user like if the cert is valid,self signed, etc. And if written to auto accept and cert "blindly". (speculation to fallow) Which is what I be-leave the how the Emby apps are written. 

[tobedeleted 4]

However, when a connection fails, I guess any application should give the user a reason why this is so. Only claiming that the server the user has typed in is not reachable, while other applications connect fine on the same device at the same time, seems to be to much "hiding of connection information"....

[NomadCF 15]

However, when a connection fails, I guess any application should give the user a reason why this is so. Only claiming that the server the user has typed in is not reachable, while other applications connect fine on the same device at the same time, seems to be to much "hiding of connection information"....

 

If it knows why sure,  But think of it like this. You go to friends house and "knock" on the door and he or shes doesn't answer. At that exact you have no idea truly why they didn't answer the door. It could be he or she isn't home, are the bathroom, didn't hear the "knocking" at the door, etc. Connecting to a remote device is the same way. Some times you don't know why they didn't answer, just only that they didn't answer. 

 

That is not to say that's always the case. There our a lot of times where you do know why you (the application) couldn't connect. Like the "hostname"  couldn't be resolved, there's no route to host, the host never responded (answered the connection but never said anything, an example would be iptables drop VS a reject which would answer and hang up also known as a response),  or like in the case of a secure connection invalid cert, keys not matching (ssh), etc.

[tobedeleted 4]

Trust me, I have enough experience with networks to claim that failing a connection without giving any reason why it fails, and not the slightest log entry, isn't exactly what you'd call best practise. I really don't get your argument at all.

[Luke 37142]

He is partially right. If the connection fails due to the server refusing it for some reason, then that is a scenario in which we can generally capture some detail as to what is going on. On the other hand, if it's just a failure of point A to reach point B, then in most cases we're only going to get a general network error or timeout error.

[NomadCF 15]

Trust me, I have enough experience with networks to claim that failing a connection without giving any reason why it fails, and not the slightest log entry, isn't exactly what you'd call best practise. I really don't get your argument at all.

 

It wasn't an argument. It was Clarification (maybe even a justification). There are many many times when the connecting party (Program,User,etc) has no idea why they couldn't connect. Just that they couldn't. Ever had your cell phone just dump you into a voicemail box of a person your trying to call AND where able to see them to know they didn't send you to voicemail. Did your phone tell you why you got sent to voice mail ? Or take a lan line. Have you ever gotten a busy signal ? Did the phone company tell you why the line was busy or didn't through (line was down, the receiver didn't have call waiting and was on the phone, etc) ? 

 

Well the same all goes for networks (as you know). If you can not connect to device there is only so much the sender (caller) can figure out (like Is there a route/path to the receiver and weather or not the connections was rejected or times out). And the same goes for the receiver (where is the highest/last point point in my network or setup I did see the connection come in (if at all)). Trouble shooting a connection with out seeing whats happening on both end is PIA at best. As you know you can have client side, carrier/isp issues, host, and receiver side issues... some times all at once.  

 

And I never said any thing about "best practice", Just that most of the time the log would be useless. But I do agree it would be useful to have at least those few things we can find out about the connect not being accepted logged somewhere. 

[tobedeleted 4]

As the server is reachable, there must be something else wrong. It is no timeout, as the error occurs too fast for that. If there is a certificate problem, the app should know about that and tell the user (as does Chromium, e.g.).

 

I guess there are lots more of informations which could help find the reason for the problem than the info "server cannot be contacted".

 

However, the log does not even contain any hint about the fact that the app tried to connect to a server(!!!!). Which makes it really difficult to find out what's going wrong (and was still working a few weeks ago).