SSL Certificate – Why Is My SSL Certificate Untrusted on Android?

mod-sslopensslssl-certificate

The SSL certificate is trusted on most Desktop computers, but only some Android devices. However, even on Android devices where the certificate is untrusted, the root certificate is installed.

I must have tried a hundered ways of resolving this problem, but I think it has something to do with the AddTrust External CA Root (perhaps to do with the SHA-256 fingerprint, which is missing?).

The cause does not appear to be an incorrect Certificate Authority Bundle.
The cause does not appear to be related to time.
All online SSL checker tools I've used (e.g., https://www.ssllabs.com) say the SSL certificate is installed correctly.
The root certificate is located on my Android device and on my Desktop computer (see the SHA1 fingerprint in the two screenshots, which is identical).

EDIT 1

I believe I have included the new intermediary certificate in my certificate chain, but SSL labs is still reporting that it's not present (even after clicking the "Clear cache" button).

EDIT 2

To be explicit about what I've done:

I've signed into to WHM and clicked the "Install an SSL Certificate on a Domain" option.
I've entered the domain name "www.angusaustralia.com.au".
I've entered the IP address "27.124.127.2".
I've entered the certificate issued to me.

I've entered the private key (not listed below).
I've entered the following certificate key chain (many combinations of the below, but I believe this "longer" keychain should work, as per the discussion on the SSLLabs website). This keychain includes the older "USERTrust RSA Certification Authority", which should be trusted by older devices.

Now, it appears as if SSLLabs is caching the old result, because when I clear everything from Chrome on my Mac (from the "beginning of time"), the new certificate chain above is detected, as per my previous edit.

EDIT 3

The answer Michael Hampton gave was correct. However, the reason why the solution he proposed didn't work was because WHM has a bug with updating the certificate authority bundle. When this bug occurs, no matter what text you paste into the Certificate Authority Bundle field (on the SSL/TLS -> Install an SSL Certificate on a Domain page), the contents will be replaced with a different CA bundle despite WHM giving you a success message.

Best Answer

Your domain's certificate has two paths to two different root certificate authorities.

On modern desktop browsers such as Google Chrome, as well as on newer Android versions, the path being taken is to the more recent USERTrust RSA Certification Authority root certificate. (I get this on Android 7.0 NPD90G.)

On older Android versions, the path being taken is to the older AddTrust External CA Root root certificate.

On this second path, you are missing an intermediate certificate. This is the one shown in the SSL Labs test as an "Extra download". In order to resolve the problem, you need to obtain this intermediate certificate and add it to the certificate chain in your web server.

Related Solutions

SSL Error – Unable to Read Server Certificate from File

Is it possible that the lines are ^M-terminated? This is a potential issue when moving files from Windows to UNIX systems. One easy way to check is to use vi in "show me the binary" mode, with vi -b /etc/apache2/domain.ssl/domain.ssl.crt/domain.com.crt.

If each line ends with a control-M, like this

you've got a file in Windows line-terminated format, and apache doesn't love those.

Your options include moving the file over again, taking more care; or using the dos2unix command to strip those out; you can also remove them inside vi, if you're careful.

Edit: thanks to @dave_thompson_085, who points out that this answer no longer applies in 2019. That is, Apache/OpenSSL are now tolerant of ^M-terminated lines, so they don't cause problems. That said, other formatting errors, several different examples of which appear in the comments, can still cause problems; check carefully for these if the certificate has been moved across systems.

SSL Error: self signed certificate in certificate chain

You don't need the root certificate in the chain (though I don't believe having it hurts anything).

That error is more of a warning from openssl in this case I think. I believe what it means is just that openssl doesn't know that it should trust the root certificate of that chain. If you pull out just the root certificate from that bundle and point that openssl command at it with the -CAfile argument I expect that "error" should go away.

Inside the sf_bundle.crt file you should see two

-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----

blocks (possibly with plain text above each block showing what certificate the block contains). If you split each of those blocks into its own file so you end up with block1.crt and block2.crt you should be able to run openssl x509 -noout -subject -in <file.crt> on each of them to get their respective certificate subject lines.

Assuming that block2.crt has a subject line of /C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority you should then be able to run openssl s_client -CAfile block2.crt -connect imap.domain.ltd:465 and that should, hopefully, connect without giving you the self-signed certificate error.

Best Answer

Related Solutions

SSL Error – Unable to Read Server Certificate from File

SSL Error: self signed certificate in certificate chain

Related Topic