Certificate not trusted under Android 7 (LG G6)

Hi guys,

I switched from an old phone with LineageOs to a new LG G6 with stock Android 7.
Unfortunately the phone doesn’t accept my server’s certificate (no problems on my old phone).

I have several services running on my server (caldav, cardav, seafile, etc.). I can’t connect to any of them because of the certificate issue. I already searched the forums, but nothing really applied or solved this issue.

Nginx SSL Config

ssl_certificate /etc/letsencrypt/live/example.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.de/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/example.de/fullchain.pem;
ssl_dhparam /etc/ssl/private/dhparams_4096.pem;
ssl_ecdh_curve secp384r1;

ssl_protocols TLSv1.2 TLSv1.3;

ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AE$
ssl_prefer_server_ciphers on;

ssl_session_timeout 1d;
ssl_buffer_size 4k;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 10s;

proxy_set_header X-Forwarded-For $remote_addr;

add_header Strict-Transport-Security “max-age=31536000; includeSubdomains”;
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection “1; mode=block”;

Best regards!!

The “ssl_trusted_certificate” statement doesn’t seem correct to me - but I may not be all that familiar with it.

Can you show the error message? or the actual domain name?

you have TLS 1.3 enabled but no TLS 1.3 ciphers, also a dhparam without having a DHE cipher, why?
Beside that i think your device is the problem and not your server config, maybe your device don’t trust the LE CA

The ssl_ciphers line has truncated by a console text editor (notice the $ at the end) so much of it is missing. You are most likely still correct about the TLSv1.3 ciphers though.

@broken.pipe please post your configuration as output by cat so your editor doesn’t truncate things. Also if you could provide the affected domain we could examine it for issues. The combination of what you configure + what your openssl supports determines what ciphers/etc. are actually on your server so the only way to be sure about things is to run some tests against the server itself.

1 Like

Thanks for your help guys! I was able to fix it by adding the missing ciphers.

before:
ssl_ciphers ‘ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256’;

now:
ssl_ciphers ‘ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS’;

Well, that’s a bad idea.

Ciphers and certificates are not very related, as long as you have the same algorithm (e.g. RSA) in the certificate as wel as in the ciphers. And you did have ECDSA as wel as RSA before.

Now you’ve added a lot of insecure ciphers to your list. Which shouldn’t have fixed any certificate problem at all.

I recommend going back to the previous cipher list and see if it still works. It probably does. If it does, the problem was something else and you fixed it somehow in another way. If it doesn’t: please tell us the actual domain name, so we can take a look what’s really going on.

I switched back and it stopped working.

active config:
ssl_protocols TLSv1.2;
ssl_ciphers ‘ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256’;
ssl_prefer_server_ciphers on;

You’ve got an A+ rating on SSLLabs. Including the Android 7 client test.

Can you make a screenshot of the actual error message when it’s not working?

On another note: your server is completely down from my point of view (The Netherlands). I can ping the IP, but can’t make a connection on either port 80 nor port 443.

Thanks for testing! :slight_smile: I already did this check while setting up nginx and striving for A+. (Due to security issues there’s a geo location block. All subdomains are only accessible from germany.)

This is basically the error

Non-trusted connection.
certificate issued for: not available
fingerprints: not available
period of validity: not available

I can’t really say it’s the app which causes the error. It’s working flawlessly on every device (iphone 4,5,6,7, ipad, desktop devices, browsers etc.) except this phone.

Well, that's not exactly a Let's Encrypt certificate. It's rather weird it's complaining about the certificate while it doesn't actually show a certificate. What app is this? Can the app show the actual certificate?

This is the seafile android app. The only app which shows any error message. I also sync contacts using Baikal and DavDroid. Here, I don’t even get an access or error log on nginx.

I enabled the ciphers in the nginx log. I need to supply “AES128-GCM-SHA256” and “DHE-RSA-AES128-SHA”. Those are the preferred ciphers by all apps. Probably this is hardcoded into this Android Rom.

That’s the Mozilla Intermediate configuration. There’s nothing wrong with it except for maybe 3DES.

SSLLabs reports the cipher suites for the stock browser in AOSP/Nexus builds but phone vendors can and have used different openssl/boringssl/bouncycastle/etc builds so it doesn’t reliably tell you what will or will not be supported with a particular device.

It also doesn’t surprise me that the wacky stock browsers some phones ship instead of Chrome do a poor job at reporting the right error.

Given the circumstances, a cipher mismatch seems like the most likely issue, especially given that adding some fixed it.

I would recommend running a few tests to determine which set gets your phone to work.
Use the original cipher list and add in the following ciphers individually:

test one (secure - when using primes with bit strengths >= key strength):
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256

test two (no forwarding secrecy):
AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-SHA256
AES256-SHA256

test three (SHA1 weakness):
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA

test four (multiple weaknesses):
ECDHE-ECDSA-DES-CBC3-SHA
ECDHE-RSA-DES-CBC3-SHA
EDH-RSA-DES-CBC3-SHA
AES128-SHA
AES256-SHA

after which you can better decide which set (or individual ciphers) you are willing to add to get things working while maintaining an acceptable level of security.

I hope it’s not relevant to Android 7, but obsolete Java clients are incompatible with secure DH parameters… You could run into the same issue, or different issues, pushing DHE cipher suites.

It’s not about Android itself… LG and Samsung both ship configurations of Android that have removed support for the latest ciphers. This is true for Android versions 5 and 6 provided by those two companies as well.

We used to use the ciphers suggested by http://cipherli.st/ in its default (strict) configuration, but Samsung and LG phones would not connect. We had to switch to the “legacy” settings for those phones to work.

Interestingly, while we have seen this with every single Samsung phone we tested, only some LG phone models have the issue. (Of course, although the recent “Nexus” phones were made by LG, they do not have the issue because they run totally stock Android versions.)

What ciphers did they remove exactly?

I haven’t had time to do a one-by-one test to answer that. All I know is that the default settings from cipherli.st do not allow (all) Samsung and (some) LG phones to connect but they work perfectly with every other Android device I have tried, including Google Nexus, HTC, and Lenovo.

I'm not sure that we should be putting all the blame on Android.

I have no idea if the Google Chrome app adds or removes support for anything, but here are the results of running the SSL Labs Browser Test on multiple devices:

Samsung Galaxy S6 Edge

TLS_GREASE_4A (0x4a4a)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) *WEAK*

Google Nexus 5X

TLS_GREASE_7A (0x7a7a)
TLS_AES_128_GCM_SHA256 (0x1301)
TLS_AES_256_GCM_SHA384 (0x1302)
TLS_CHACHA20_POLY1305_SHA256 (0x1303)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) *WEAK*

These ciphers are not present on the Samsung.

  • TLS_AES_128_GCM_SHA256 (0x1301)
  • TLS_AES_256_GCM_SHA384 (0x1302)
  • TLS_CHACHA20_POLY1305_SHA256 (0x1303)
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)

Note that Google Chrome (63.0.3239.59) on Windows 10 desktop has the same list as the Nexus 5X, except that TLS_GREASE_9A (0x9a9a) replaces TLS_GREASE_7A (0x7a7a).

I will add the results of more devices later today and tomorrow.

Google Chrome uses its own SSL engine. The only issue you’ll have with it is people running older versions because they’re low on storage.

Try the Samsung Browser or a browser that uses the built-in webview like Firefox Focus or Dolphin Browser.