Android phone problems

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: dksti.com

I ran this command: https://dksti.com/ap/hello (from an Android app on mobile phone, not from a browser - it works fine from a browser, even from an Android phone).

It produced this output: Exception Message: “The SSL connection could not be established, see inner exception.”
Inner Exception Message: “Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED\n at /Users/builder/jenkins/workspace/archive-mono/2019-10/android/release/external/boringssl/ssl/handshake_client.c:1132”

My web server is (include version): nginx/1.10.3 (Ubuntu)

The operating system my web server runs on is (include version): Ubunti 16.04 LTS

My hosting provider, if applicable, is: Microsoft Azure

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.27.0

This seems to have started yesterday. Android apps (build using Xamarin) which used to have no problem are suddenly encountering the SSL failure. These are existing, unchanged apps. Nor has the server changed. The same mobile devices can access the same URL using a browser without difficulties. The equivalent iPhone apps work as well, only Android apps are experiencing sudden SSL failures.

1 Like
2

The cert being provided by the site is NOT from LE.
The problem(s) described are related to the configuration of the web server (or lack thereof).
Please see:
https://www.ssllabs.com/ssltest/analyze.html?d=dksti.com

1 Like
3

I understand what you say, but the check you suggested says there’s an expired cert in the chain (actually two, here’s the first one):

Subject USERTrust RSA Certification Authority
Fingerprint SHA256: 1a5174980a294a528a110726d5855650266c48d9883bea692b67b6d726da98c5
Pin SHA256: x4QzPSC810K5/cMjb05Qm4k3Bw5zBn4lTdO/nEW/Td4=
lid until Sat, 30 May 2020 10:48:38 UTC (expired 3 days, 14 hours ago) **EXPIRED
Key RSA 4096 bits (e 65537)

What can I do about that?

4

You need to get a different set of intermediate certificate(s) – likely referred to as a “CA bundle” – from your CA, Sectigo, and configure your web server to use it.

(The other solution is to use more flexible TLS clients that can work around expired CAs when path building.)

Your web server is sending both the famous expired AddTrust External CA Root certificate, and a less famous expired USERTrust RSA Certification Authority intermediate certificate.

(To be clear, your leaf certificate does not need to be replaced.)

https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020

1 Like
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.