Android Question SSL connection failures

[Lee Gillie CCP]

I have been running our last deployment without issue since Feb 2019. There are perhaps around 12 tablets, with our B4A app installed on:

• P00I - Asus
• VK700 - LGE
• SM-T597V - Samsung

Yesterday they all worked fine. Today, at first only the LGE failed, and it was all LGE tablets out there which failed. About an hour ago all tablets now fail to connect. My first thought was perhaps a new Android was just pushed. Or some other major news event because I have been out of the loop for a bit. I have an LGE at the office, but I am working remotely at present, so I can not get to the office. I cant reproduce and check the Android's log from there at the moment. These tablets all connect via Verizon. The server they attempt to connect to is a custom .NET service which provides web services API.

This one has me baffled, but maybe someone else started having similar issues today or very recently?

I know it is not much to go on, so grasping at straws here. I sure hope someone has an idea or two.

Best regards - Lee Gillie, CCP - Spokane, WA

 

[OliverA]

Perhaps you can give the suggestion to update to the leatist the last SSL version:

That's what the code above provided by @Erel does. It just uses the async version of the ProviderInstaller method, therefore the callback handler and the Wait For. Supposedly this ran on a LG tablet without solving the issue.

 

[MicroDrie]

To quote a part of OliverA point to the refered article

It's just interesting that your issues started June 1st. On May 30th a major root certificate expired causing some big problems out there: https://nakedsecurity.sophos.com/2020/06/02/the-mystery-of-the-expiring-sectigo-web-certificate/

And looking to

After all the actions taken, might the rickety LGE tablet software with a quick and dirty removal of all certificates (the complete chain) on the LGE tablet offer a solution?

 

[OliverA]

After all the actions taken, might the rickety LGE tablet software with a quick and dirty removal of all certificates (the complete chain) on the LGE tablet offer a solution?

Another solution is to use another SSL certificate from a different provider with a different root certificate. May be cheaper than buying a bunch of new tablets

 

[JohnC]

Since everything was working until 6/1, then I would highly suspect that it is an issue "related" with your certificate.

As I mentioned in post #2, the certificate of my server was not due to expire until 7/1/20, but a private B4A app in my phone that uses the SMTP object of the NET lib, gave an "Certifcate Expired" error starting on 5/31/20.

After some researching, the problem appeared to be a third-party root certificate - just as @OliverA stated in post #18 which did expire on 5/30/20. And apparently my server's certificate depended on that expired root certificate.

The solution was to simply buy a new SSL certificate for my server. My thinking is that the new certificate was generated to use a different root structure that would not route it through that expired root certificate.

You can always configure IIS to switch back to the old certificate if the new certificate doesn't fix the problem.

 

[JohnC]

This is a long shot (but might work without having to buy a new server certificate)...

Try going into one of the LG tablets and go into the "Security" settings, then view the list of "Trusted credentials".

Look for an entry that says "AddTrust" - there may be multiple entries.

Try disabling the one that says "AddTrust External CA Root"

Reboot the tablet and see if it will work now.

 

[Barb Kinkade]

I am Lee Gillie's co-worker and I have been working with him on the SSL connectivity issue on the LG tablets.

I really do appreciate all of you taking the time to try and help us figure out this problem!

We found that we could successfully connect to our server, using Chrome on the tablet, so that brought us back to realizing that it had to do something with our B4A app.

Occasionally we were getting this error on the tablet "Trust anchor for certification path not found" and I found this post on the forum.

https://www.b4x.com/android/forum/threads/https-get-post-request-error-trust-anchor-for-certification-path-not-found-solved.112826/

I did what was suggested in the post

And now the App on the LG tablets connects!

Question though. Are we less secure, now that we are using the HU2_ACCEPTALL option?

Thanks!

 

[JohnC]

Why don't you try undoing the change you did and try my idea in post #25.

Because if my idea works, then you won't need to reduce security with the ACCEPTALL method.

 

[Erel]

Question though. Are we less secure, now that we are using the HU2_ACCEPTALL option?

It means that your app is open to a man in the middle attack as it doesn't verify the certificate. It is still a bit more secure than calling a non-https url as the communication is encrypted.

 

[Barb Kinkade]

Why don't you try undoing the change you did and try my idea in post #25.

Because if my idea works, then you won't need to reduce security with the ACCEPTALL method.

I actually did try your idea posted in #25 and it didn't work. I have actually tried almost everything that was posted as suggestions in this thread.

Thanks

 

[MicroDrie]

Perhaps you can force the import of the certificate with a TrustManager described in Common problems verifying server certificates for this error:

javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.

 

[JohnC]

I actually did try your idea posted in #25 and it didn't work. I have actually tried almost everything that was posted as suggestions in this thread.

Thanks

If you didn't try my other solution in post #24, I would highly recommend trying it because with the ACCEPTALL method, your connection is not as secure as it was before you ran into this issue. (Remember, you can always switch back your current certificate if the new one doesn't fix the issue)

 

[Barb Kinkade]

If you didn't try my other solution in post #24, I would highly recommend trying it because with the ACCEPTALL method, your connection is not as secure as it was before you ran into this issue. (Remember, you can always switch back your current certificate if the new one doesn't fix the issue)

A new certificate would cost us about the same amount as buying a few new tablets.

We decided to go ahead with using the ACCEPTALL method. The data that we are passing from the tablet to the server is not really that sensitive of data. We feel that if someone was to figure out how to access the data that we are passing, that they really couldn't do much with that information.

We could probably spend a bunch more time on coming up with a solution that would allow us to not use the ACCEPTALL method, but time is money.

Thanks again for all of your input!

 

[udg]

A new certificate would cost us about the same amount as buying a few new tablets.

Did you know about ssl2buy offers? Or even the free ones like Let's Encrypt.
Out of curiosity, which special characteristics should a certificate needs to have in order to comply with your requirements?