My app runs on all devices and simulators Except Samsung SM-A500W. It just failed to update the database. The access to the database is through php scripts stored in a TLD secure domain (Access only through httpS).
The failure is because it thinks the expiration date of the certificate is passed....not true. See LogCat.
10-25 11:07:18.381 25547-25617/uro2.tradersmicro.com.uro2 D/Uploadi16: Exception jb: com.android.org.bouncycastle.jce.exception.ExtCertPathValidatorException: Could not validate certificate: Certificate expired at Sat Feb 18 18:59:59 EST 2017 (compared to Thu Oct 25 11:07:18 EDT 2018) javax.net.ssl.SSLHandshakeException: com.android.org.bouncycastle.jce.exception.ExtCertPathValidatorException: Could not validate certificate: Certificate expired at Sat Feb 18 18:59:59 EST 2017 (compared to Thu Oct 25 11:07:18 EDT 2018)
BTW. One of the fragments of my app uses a WebView. The secure database access in this part is normal.
Is there a way to avoid this error?
The way I found to circumvent this problem is to copy the php scripts to a Non Secure Domain, and ensure that they get updated as the scripts are updated.
At run time:- in the try...catch of the database access to change the domain to the insecure one. So far works like a charm.
Of course the database access occurs in an Async task, it seems ok to call the method again, recursively from the catch code.
I would suggest trying to update the device security provider using the Google Play Service:
https://developer.android.com/training/articles/security-gms-provider
import com.google.android.gms.security.ProviderInstaller;
// ....
try {
ProviderInstaller.installIfNeeded(getContext());
} catch (GooglePlayServicesRepairableException e) {
// TODO handle error
}
Related
We are facing some issues in connecting to Google’s GCM API (https://android.googleapis.com/gcm/send ) for Android push notifications from our server (SSLHandshakeException).
From 28th February to 8th March 2018 the issue was intermittent(push sent sometimes, SSL handshake error otherwise). From 9th March 2018 the issue is continuous.
Please see the logs below. Would like to know if there was any changes to the issued certificates.
com.sun.jersey.api.client.ClientHandlerException: 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.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:151)
I do not fully understand the details, but when I update our push provider/server "External Services Certs" and add the cert below.. my push started working again. So even though the Equifax cert that I originally installed 2 years ago was working until a few weeks ago, something changed on the GCM server and that cert was no longer valid. It has an expiration date of Aug 2018, which is near, but should not expire till that date.
I did notice that the new cert is SHA256 and the original is SHA1, so maybe this is a required security upgrade. It kind of screws me since my push content providers are distributed, not in a single location where it is easy to update the cert :(
The cert that fixed my issue is:
-----BEGIN CERTIFICATE-----
MIIEXDCCA0SgAwIBAgINAeOpMBz8cgY4P5pTHTANBgkqhkiG9w0BAQsFADBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEGA1UEChMKR2xvYmFs
U2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjAeFw0xNzA2MTUwMDAwNDJaFw0yMTEy
MTUwMDAwNDJaMFQxCzAJBgNVBAYTAlVTMR4wHAYDVQQKExVHb29nbGUgVHJ1c3Qg
U2VydmljZXMxJTAjBgNVBAMTHEdvb2dsZSBJbnRlcm5ldCBBdXRob3JpdHkgRzMw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKUkvqHv/OJGuo2nIYaNVW
XQ5IWi01CXZaz6TIHLGp/lOJ+600/4hbn7vn6AAB3DVzdQOts7G5pH0rJnnOFUAK
71G4nzKMfHCGUksW/mona+Y2emJQ2N+aicwJKetPKRSIgAuPOB6Aahh8Hb2XO3h9
RUk2T0HNouB2VzxoMXlkyW7XUR5mw6JkLHnA52XDVoRTWkNty5oCINLvGmnRsJ1z
ouAqYGVQMc/7sy+/EYhALrVJEA8KbtyX+r8snwU5C1hUrwaW6MWOARa8qBpNQcWT
kaIeoYvy/sGIJEmjR0vFEwHdp1cSaWIr6/4g72n7OqXwfinu7ZYW97EfoOSQJeAz
AgMBAAGjggEzMIIBLzAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUH
AwEGCCsGAQUFBwMCMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHfCuFCa
Z3Z2sS3ChtCDoH6mfrpLMB8GA1UdIwQYMBaAFJviB1dnHB7AagbeWbSaLd/cGYYu
MDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AucGtpLmdv
b2cvZ3NyMjAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnBraS5nb29nL2dz
cjIvZ3NyMi5jcmwwPwYDVR0gBDgwNjA0BgZngQwBAgIwKjAoBggrBgEFBQcCARYc
aHR0cHM6Ly9wa2kuZ29vZy9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEA
HLeJluRT7bvs26gyAZ8so81trUISd7O45skDUmAge1cnxhG1P2cNmSxbWsoiCt2e
ux9LSD+PAj2LIYRFHW31/6xoic1k4tbWXkDCjir37xTTNqRAMPUyFRWSdvt+nlPq
wnb8Oa2I/maSJukcxDjNSfpDh/Bd1lZNgdd/8cLdsE3+wypufJ9uXO1iQpnh9zbu
FIwsIONGl1p3A8CgxkqI/UAih3JaGOqcpcdaCIzkBaR9uYQ1X4k2Vg5APRLouzVy
7a8IVk6wuy6pm+T7HT4LY8ibS5FEZlfAFLSW8NwsVz9SBK2Vqn1N0PIMn5xA6NZV
c7o835DLAFshEWfC7TIe3g==
-----END CERTIFICATE-----
I obtained it by running this openssl cmd and it is the second one in the chain. That CAfile parm is robably not needed, since I did not have that file and there was a complaint, but the required cert chain was still displayed.
openssl s_client -connect gcm-http.googleapis.com:443/gcm/send -debug -showcerts -CAfile entrust_2048_ca.cer
The issue was due to GeoTrust to GoogleTrust migration of the SSL certificates for googleapis.com. Issue got fixed when we imported new certificate from the URL: https://android.googleapis.com and added to our server's trust store.
Kari - that is what I figured. Thanks for replying.. but the URL you list gives 404.. can you double check and update if you have the correct URL.
I am seeing the same issue and the same SSL error. Any more discussion on this?
Just out of the blue, my app started getting this error when making calls to a REST API via https. I was working on a mod that added an Intent to handle opening files of a certain file extension but I doubt that that was the cause.
Instead, the problem is similar to this one:
Invalid certificate received from server
My cert is also by Comodo and has been installed since April of this year. The solution of disabling the COMODO RSA Certification Authority did not work.
The server is a VPS that the host underwent a hardware upgrade during the time that this error started to appear but I'm also not sure that that would be the reason since the browser shows SSL as fine and the iOS version of the app is also working fine.
The code in the app that makes the call to the server is in a utility class and I did not change that code at all. The minor change that I did was to add an intent which I then removed and the error is still there.
Here are the error messages including the inner exceptions and the stack trace:
System.Net.WebExceptionStatus.TrustFailure
ex.InnerException.Message - The authentication or decryption has failed.
ex.InnerException.InnerException.InnerException.Message - Invalid certificate received from server. Error code: 0xffffffff800b010b
ex.InnerException.InnerException.StackTrace
at Mono.Security.Protocol.Tls.RecordProtocol.EndReceiveRecord (System.IAsyncResult asyncResult) [0x0003a] in /Users/builder/data/lanes/3511/501e63ce/source/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/RecordProtocol.cs:430
at Mono.Security.Protocol.Tls.SslClientStream.SafeEndReceiveRecord (System.IAsyncResult ar, System.Boolean ignoreEmpty) [0x00000] in /Users/builder/data/lanes/3511/501e63ce/source/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/SslClientStream.cs:256
at Mono.Security.Protocol.Tls.SslClientStream.NegotiateAsyncWorker (System.IAsyncResult result) [0x00071] in /Users/builder/data/lanes/3511/501e63ce/source/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/SslClientStream.cs:418
ex.InnerException.StackTrace
at Mono.Security.Protocol.Tls.SslStreamBase.EndRead (System.IAsyncResult asyncResult) [0x00051] in /Users/builder/data/lanes/3511/501e63ce/source/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/SslStreamBase.cs:883
at Mono.Net.Security.Private.LegacySslStream.EndAuthenticateAsClient (System.IAsyncResult asyncResult) [0x00011] in /Users/builder/data/lanes/3511/501e63ce/source/mono/mcs/class/System/Mono.Net.Security/LegacySslStream.cs:475
at Mono.Net.Security.Private.LegacySslStream.AuthenticateAsClient (System.String targetHost, System.Security.Cryptography.X509Certificates.X509CertificateCollection clientCertificates, System.Security.Authentication.SslProtocols enabledSslProtocols, System.Boolean checkCertificateRevocation) [0x00000] in /Users/builder/data/lanes/3511/501e63ce/source/mono/mcs/class/System/Mono.Net.Security/LegacySslStream.cs:445
at Mono.Net.Security.MonoTlsStream.CreateStream (System.Byte[] buffer) [0x0004e] in /Users/builder/data/lanes/3511/501e63ce/source/mono/mcs/class/System/Mono.Net.Security/MonoTlsStream.cs:106
I'm using the standard port 443. I checked the bindings and there are no issues, it says that the cert is 'ok' when I view the certification path status.
I am getting the error when using an actual device, not an emulator.
Any help is appreciated.
***** update
I called Comodo's support and found out the issue is with Android's certificate store not being up to date and using the old legacy SHA. So the certification path 2 was coming back to the client with a 'Extra Download' status. There supposedly is a cert named 'COMODO RSA Certification Authority' in my server expiring in 2036 that interferes with 'COMODO RSA Certification Authority' intermediate certificate expiring in 2020. Here are the details of that cert:
[Root] Comodo RSA Certification Authority (SHA-2)
Serial Number: 4c:aa:f9:ca:db:63:6f:e0:1f:f7:4e:d8:5b:03:86:9d
Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Certification Authority
Validity (Expires) : Jan 18 23:59:59 2038 GMT
However, I couldn't find out in both local computer and current user. Since this is a VPS/virtual machine, the problem may be that the host machine may be adding this in the virtual network communication/response back to the client. The problem now is that the hosting company doesn't want to disable the cert in the host machine.
I got it working. As I mentioned in my update above, the issue is with Android's certificate store not being up to date and using the old legacy SHA. So the certification path 2 was coming back to the client with a 'Extra Download' status. There is a cert named 'COMODO RSA Certification Authority' in expiring in 2036 that interferes with 'COMODO RSA Certification Authority' intermediate certificate expiring in 2020. I had already deleted it that's why I couldn't find it anymore.
The fix is to find & disable or delete this cert, replace it with new certs downloaded from Comodo's website, and rebooting the machine.
Here are the details of the cert to disable/delete:
[Root] Comodo RSA Certification Authority (SHA-2)
Serial Number: 4c:aa:f9:ca:db:63:6f:e0:1f:f7:4e:d8:5b:03:86:9d
Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Certification Authority
Validity (Expires) : Jan 18 23:59:59 2038 GMT
The new certs are:
comodorsadomainvalidationsecureserverca.crt
comodorsaaddtrustca.crt
addtrustexternalcaroot.crt
I can't find the page where I downloaded all three from, the Comodo tech support rep helped me navigate to this page.
To disable the cert, go into Certification Manager from the MMC, right click to open, click on the Details tab, click on the Edit Properties button and in the Certificate Purposes area, choose the 'Disable for all purposes' radio option.
Import the new certs and reboot.
And instead of using SSLChecker, I recommend SSL Server Test by Qualys SSL Labs (https://www.ssllabs.com/ssltest/index.html) as it's more accurate & detailed.
I created ibm-mobilefirst-starter:latest container in bluemix. And I am able to access the MFS console.I can see MobileFirstStarter run time its working fine. Now I uploaded new .wlapp and one http .adapter file into MFS console and they are visible in Console. When I try to access the Adapter from Common Resources I am getting Error :
[http://134.168.31.10:9080/MobileFirstStarter/authorization/v1/clients/preview] failure. state: 404, response: The server was unable to process the request from the application. Please try again later.
Client registration failed with error: {"responseHeaders":{"Date":"Tue, 01 Mar 2016 12:35:44 GMT","Connection":"Close","X-Powered-By":"Servlet/3.0","Content-Length":"0","Content-Language":"en-US"},"status":404,"responseText":"","errorCode":"UNEXPECTED_ERROR","errorMsg":"The server was unable to process the request from the application. Please try again later.","invocationContext":null}
I tried with Android environment and tested in device. Couldn't see any response from adapter.
Thanks in Advance.
There is no preview available from the console in non-development environments (i.e. MobileFirst Studio plug-in for Eclipse).
It is unclear from your question if only the preview failing or also from a device/emulator.
I'm running CouchDB with Yocto Dizzy on a LogicPD Torpedo with a 1GHz processor. I have multiple Android devices connected, making changes, and syncing with this database through some Java and Nodejs code. For the most part, it looks like the database is replicating properly across all devices.
However, I do have a frequent issue where a device will fall out of sync and the Android app on that device will have to be restarted. By "fall out of sync" I mean that changes are being made on one device, synced to the database, and not showing up on another device. I'm trying to troubleshoot this problem and I haven't been able to find any errors on the Android side. The errors I'm seeing in the CouchDB log are:
[Fri, 25 Sep 2015 14:47:59 GMT] [error] [<0.222.0>] ** Generic server <0.222.0> terminating
** Last message in was {'EXIT',<0.217.0>,killed}
** When Server state == {state,"http://X.XXX.X.X:XXXX/task/",20,[],
[<0.338.0>],
{[],[]}}
** Reason for termination ==
** killed
[Fri, 25 Sep 2015 14:47:59 GMT] [error] [<0.222.0>] {error_report,<0.31.0>,
{<0.222.0>,crash_report,
[[{initial_call,
{couch_replicator_httpc_pool,init,['Argument__1']}},
{pid,<0.222.0>},
{registered_name,[]},
{error_info,
{exit,killed,
[{gen_server,terminate,7,
[{file,"gen_server.erl"},{line,804}]},
{proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,237}]}]}},
{ancestors,
[<0.217.0>,couch_replicator_job_sup,
couch_primary_services,couch_server_sup,<0.32.0>]},
{messages,[]},
{links,[<0.338.0>]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,610},
{stack_size,27},
{reductions,390}],
[]]}}
[Fri, 25 Sep 2015 14:48:06 GMT] [error] [<0.130.0>] Error in replication `b16486bad369b219600dbd5bf0478e81+continuous+create_target` (triggered by document `9be140c9aa6334820aed80fa910275e4`): timeout
Restarting replication in 5 seconds.
[Fri, 25 Sep 2015 14:48:06 GMT] [error] [<0.88.0>] {error_report,<0.31.0>,
{<0.88.0>,supervisor_report,
[{supervisor,{local,couch_replicator_job_sup}},
{errorContext,shutdown_error},
{reason,killed},
{offender,
[{pid,<0.157.0>},
{name,
"98e4832e6f31a0962493d26092b5fe4e+continuous+create_target"},
{mfargs,{gen_server,start_link,undefined}},
{restart_type,temporary},
{shutdown,250},
{child_type,worker}]}]}}
When running the same programs and database on CentOS with an i7, it all works perfectly. I've tried mucking with tcp/ip kernel settings, as well as CouchDBs settings (local.ini, specifically os_process and timeout options).
Does anyone have any experience in this area? Any help would be greatly appreciated!
I'm trying to run an os.system() call from my Python class to source a file I have stored in the file. I am connecting to a server from an Android application and running a method in Django to run a system call. The server is running Apache with mod_wsgi to deploy Django. This is the Django method:
def post_try(request):
os.chdir("/usr/local/src")
response = os.system("source sourceme")
return HttpResponse(response)
The code works fine as far as syntax goes, all necessary imports are done, however I keep getting a 256 error code back instead of the expected 0. I check the error in the Apache log and this is what I get:
[Sun Aug 18 19:43:23 2013] [notice] caught SIGTERM, shutting down
[Sun Aug 18 19:43:24 2013] [warn] mod_wsgi: Compiled for Python/2.7.2+.
[Sun Aug 18 19:43:24 2013] [warn] mod_wsgi: Runtime using Python/2.7.3.
[Sun Aug 18 19:43:24 2013] [notice] Apache/2.2.22 (Ubuntu) mod_wsgi/3.3 Python/2.7.3 configured -- resuming normal operations
[Sun Aug 18 19:46:04 2013] [notice] caught SIGTERM, shutting down
[Sun Aug 18 19:46:05 2013] [warn] mod_wsgi: Compiled for Python/2.7.2+.
[Sun Aug 18 19:46:05 2013] [warn] mod_wsgi: Runtime using Python/2.7.3.
[Sun Aug 18 19:46:05 2013] [notice] Apache/2.2.22 (Ubuntu) mod_wsgi/3.3 Python/2.7.3 configured -- resuming normal operations
sh: line 0: source: sourceme: file not found
I cannot figure out what is going on. I have the sourceme file clearly in the /usr/locals/src/ folder, which I have verified many times using ls. I do not know what is happening. I used os.getcwd() to check that the directory is being changed correctly, but the file still cannot be found. Please let me know if there is anything that I am missing, as I am very frustrated at this problem that I can just not realize.
Thank you
Your approach currently does not make sense:
os.system creates a child process of the WSGI process, while the environment of the parent is passed on to the child, the environment of the child is not passed back/shared with the parent.
Also, source is not a binary, but a built-in function of the shell itself.
If you want to set environment variables us os.environ which is a dictionary of the variables.
Since you are using python, it would be much more sensible to use python program instead of some os.system calls. That is, create python program with the environment variables, add it to your PYTHONPATH and import it in your django code.