We help IT Professionals succeed at work.

Validate an SSL Certificate from a Smatphone App.

Last Modified: 2018-12-08
Question about how SSL Certificates work on a mobile phone app.

We are setting up a 2-factor authentication for our remote access.  The process involves enrolling your smartphone with your user account for remote access.  Very much like how Duo Mobile works ( https://duo.com ); but, we cannot add our smartphones because the when scanning the QR code to enroll the smartphone an error comes up stating that the Smartphone App does not trust the certificate.

We have a Certificate a respected Certificate Authority (THAWTE) on our Authentication server.  The consultant informed me that we have 2 options.

1.  Change the certificate to another CA on the server.
        a.  He said GoDaddy or Verisign will work for sure(its working in his test lab).
        b.  Try to get a refund on the THAWTE certificate that we purchased.

2.  Wait for the certificate trust anchors to get updated by the Application.
        a.  But who knows when that will happen.

The consultant stated that if he browses to the web url that the QR code is referencing (for example, https://whatever.com) there is no certificate error prompt and I verified that I do not see any certificate errors either(from a browser).

My manager thinks that the consultant should include the certificate in the authentication chain on the new Authentication server; but, I am not sure how that part actually works.  

I also discovered another web article describing the same problem with apps vs browsers: https://stackoverflow.com/questions/26226713/moved-ssl-cert-now-getting-java-security-cer-certpathvalidatorexception

This error came about because the certificate I had installed on my server was a primary cert with no chain. I concatenated the secondary cert with the primary into a single file, installed on the server, and Android accepted the SSL connection.

If it does not work in the app but works in the browser it is often the problem, that the site uses server name indication (SNI) to have multiple certificates on a single IP address. This is supported by all modern browsers, but not by the old Apache HTTP client shipped with Android.

Quesiton1:  Can someone explain to my how authentication chains work with SSL certificates?

Quesion2:  Can someone explain to me what our options are and if all that needs to be done is for the consultant to add the SSL Cert in the Authentication chain or not?
      a.  Or must we do something else instead like get another SSL certificate?
Watch Question

David FavorFractional CTO
Distinguished Expert 2019

Sigh... Best you hire someone to help you with this, as SSL is far more complex than it appears on the surface.

I'll tell you how I'd fix this.

1) Only use free (supported by all devices) https://LetsEncrypt.org certs.

2) Setup your server side system to auto renew certs by running certbot-auto --post-hook="restart any SSL services here"... so, something like...

0 */1 * * * (echo '#####' && date && certbot-auto renew --non-interactive --post-hook "service apache2 reload;service dovecot restart") >> /var/log/ssl-renewals.log 2>&1

Open in new window

I run this code every hour, because resources are only required if a cert actually must renew.

Also, there is a rate limit on number of certs which you can renew in a day + how many cert renewal failures you're allowed in an hour. If you renew at a 1 hour granularity, all these rate limits are avoided, even if you have 100s-1000s of certs on a machine to renew.

3) Do not run your own CA Authority, so you updating trust chains is no longer required, as this will fail in oddball ways of the course of many years.

You can't really do this with a public App because no one will recognize any private CA chain, so you'd somehow have to do some sort of root jailbreak of every imaginable device + OS to install your private CA chain, as no mobile devices will allow this with default security enforced + most don't allow any changes to default security.

4) On your server site, use a pure LAMP Stack. No Windows. No proxies (NGINX, HAProxy, SQUID, Varnish). Keep your setup clean + simple, so debugging is fast.

5) You must do the exact following or many mobile + desktop Apps will fail connecting today + eventually all will fail connecting, if this is incorrect.

Your SSL Config should disable protocols SSL2, SSL3, TLSv1.0, TLS1.1 + enable TLSv1.2+ (so this will also pickup TLSv1.3 when available).

6) Minimal software versions to install to support TLSv1.3 which is best done now, as there's already talk about completely deprecating TLSv1.2 when TLSv1.3 is commonly available. Since all TLSv1.3 code is now stable + in use many places, the date of common availability will be soon.


Open in new window

These are minimal code versions to get TLSv1.3 working well.

7) Keep in mind iOS 8 currently has an SSL bug, which requires you ensure your SSL config will talk with iOS 8. Most default SSL configs currently break iOS 8 connections. Use this tester to ensure your SSL config allows iOS 8 connections.


Make sure you see iOS 8 + TLSv1.2 works correctly. Best to retest this again when next iOS 8 version releases. iOS versions above 8 are not effected.
PkafkasNetwork Engineer


I still have to read through Mr. Favor's respose; but, just in case this will help, I will type the error code that comes up when trying to enroll our smartphones from the NetIQ App.

Please ask your admin if this error will be repeated:  Device add error: java.security.cert.CertPathValidator:Trust anchor for certification path not found.

NetIQ provides the following feedback:  https://www.netiq.com/documentation/advanced-authentication-60/smartphone-applications/data/enrollment_cant_be_performed.html

Causes / Solutions are given.  The consultant who installed the feature uses the same feature at his work place.  He is familiar with this web site and still believes getting another Cert from a different C.A. will work.  Can anyone confirm/deny or provide an alternative idea and explanation?
PkafkasNetwork Engineer


I will need to share this information with the consultant that is working on this problem; but, I do find SSL security fascinating.  I can tell you that we are:

1.  Using a linux Server for the Authoritative server.

2.  So far we have tested with 3 Android smartphones.

3.  Its been over 1 week and there has been no change in the certificate approval from THAWTE.
      a.  Who knows if and when the NetIQ App people will update their trusted certificate list.

I do not have anything to report from the consultant yet so I cannot give any results.  I will be sure to report back when I have information; but, with the holidays this weekend I might not report aback for 1 week or later.
David FavorFractional CTO
Distinguished Expert 2019

1) "Please ask your admin if this error will be repeated:  Device add error: java.security.cert.CertPathValidator:Trust anchor for certification path not found."

This means you're trying to use a private CA with public devices (random App users).

2) He is familiar with this web site and still believes getting another Cert from a different C.A. will work.

Technically this is correct.

Realistically this is incorrect.

Using private CA certs (no point doing this today, since all certs are free) will only work, if every single App user arranges to import the Trust Chain... every time any layer of the Trust Chain expires.

So initially, you'd have to convince all your App users to "trust you enough to import your private CA issuer chain" which will vary greatly depending on how your App is written.

To me... if a developer pitched me a hair brained scheme like this... I'd fire them, before I hired them.

Apps should work with zero extra effort from App users.

Importing, then re-importing an issuer chain each time the CA chain has to be regenerated, to me... might be okay for some sort of hobby App, not for an App you intent running to pay your bills.
PkafkasNetwork Engineer


I do not understand, THAWTE is a public Certificate Authority (CA) just like GoDAddy for example.
David FavorFractional CTO
Distinguished Expert 2019

Publish a URL using the same SSL cert as your App + likely someone can assist.

Messages about trust + issuer chain problems might mean something as simple as your App is using the incorrect cert, meaning the cert only file, rather than full chain file.

Or could mean your developer is using a private CA without telling you.

Rather than guessing, publish a URL using your SSL cert + any tester (like SSL Labs) will tell you instantly what's good + what's broken about your config.
PkafkasNetwork Engineer


Hello Mr. Favor,

Thank you so much for all of your help.  We already do have a url that is open to the public and that url has the SSL Certificate in question.  When browsing the url, then web browser shows to have a valid certificate.  

It has been about 2 weeks and the App has not updated their certificate information.  I think the solution will be to use an SSL cert from a different Certificate Authority.  I have attached 2 screen shots, to help explain.  Unless you are requesting something else, I will try to accommodate.

PkafkasNetwork Engineer


Is there another way to test if the SSL Certificate works from the browser?  Besides what I have done above?
PkafkasNetwork Engineer


Mr. Favor,

I navigated to: https://www.ssllabs.com/ssltest/

and I entered the public URL in the hostname section.  It recieved a 'B' rating.  Please see screen shot.  Does this satisfy the requirements that the Cert is valid?

David FavorFractional CTO
Distinguished Expert 2019

Okay. You only provided some of the SSL Labs test, so unable to give a complete answer.

For me I only deploy A+ SSL configs, never B or T. I doubt this is the root cause of your problem + I'd still rule this out by fixing your config.

Best to first target an SSL Labs report like https://www.ssllabs.com/ssltest/analyze.html?d=davidfavor.com so a minimum of an A+ with 4x 100 scores.

Note: It you have TLSv1.3 support enabled, I've only be able to get a 90 score for Cipher Strength right now. Bug tickets are open about this.

You chopped off the additional certificates section. This section should show good also.

As I said above, the message "Device add error: java.security.cert.CertPathValidator:Trust anchor for certification path not found." is very clear. The device where this message is generated is running an outdated version of either Java or the OS, which is missing an up to date Trust Chain for THAWTE.

To be clear, this is either a device problem or you're serving some other SSL cert (will show in secondary chain listing you redacted from your SSL Labs report).

Also, keep in mind this is likely easy to fix + you'll have to hire someone to help you, as they will have to delve deeply into exactly what's going on with your server side code + App code.

Nearly impossible to guess at, especially when you redact data of your URL, so many other tools can be used to check your setup.

And, you'll also have to audit your App code, so the problem could be Server side or App side or a specific set of devices/OSes which are the problem.
PkafkasNetwork Engineer


Ok, how about this"  https://www.ssllabs.com/ssltest/analyze.html?d=enroll.strattec.com&latest

I just wanted to be secretive on the company information.  But for the company all of this stuff is public knowledge anyway.  I hope the above website will provide enough information for the next step.  I am betting it is a problem with the App since this error happens on other smartphones as well.
Fractional CTO
Distinguished Expert 2019
This one is on us!
(Get your first solution completely free - no credit card required)
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.