Android 7.0 can't establish ssl connection

Help
1

My domain is: starline.ru

I ran this command: android 7.0 can't connect

It produced this output:

Caused by: javax.net.ssl.SSLProtocolException: SSL handshake terminated: ssl=0x76a8eb8a00: Failure in SSL library, usually a protocol error error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE (external/boringssl/src/ssl/s3_pkt.c:641 0x76a8e2b0a0:0x00000001) error:1000009a:SSL routines:OPENSSL_internal:HANDSHAKE_FAILURE_ON_CLIENT_HELLO (external/boringssl/src/ssl/s3_clnt.c:800 0x76d2e2c253:0x00000000)
at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:364)

SSLV3 - wrapper string, actualy sslv3 not use

My web server is (include version):

nginx version: nginx/1.14.1
built with OpenSSL 1.1.0f  25 May 2017 (running with OpenSSL 1.1.0l  10 Sep 2019)
TLS SNI support enabled

The operating system my web server runs on is (include version): Debian GNU/Linux 9.13 (stretch)

Previously, the RSA private key was generated. And everything worked.
Now a private key has been generated as EC and application (with okhttp3 https://square.github.io/okhttp or direct use ssl) on Android 7.0 - cannot connect (application using android webclient backend is working).

1 Like
2

You're almost certainly running into this issue:

The only way to fix this is by NOT using an EC certificate. Right now you can work around by switching to P-256, but as the future E1 intermediate is P-384, that's not a long term solution.

1 Like
3

That server is using a P-384, elliptic curve certificate, which Android 7.0 doesn't support.

As least according to @Nummer378 in another thread:

Android 7.0 has a bug, where the only supported elliptic curve is P-256 , meaning that the P-384 curve used by Let's Encrypts E1/X2 certs cannot be handled by this Android version. The Android version advises ECC support though, so I presume that this scenario will simply break (handshakes usually fail with "illegal parameter" TLS alert from my tests). 7.1 is fixed though, this seems to only affect 7.0. Older than 7.0 (e.g 6.x and below) as well as 7.1 and newer works fine.

So you need to use the P-256 elliptic curve (at least as long as it's still signed by the RSA intermediate, as that is supposed to change eventually to be signed by a P-384 intermediate that will break on Android 7.0 anyway), so stick with RSA if you need to support older android versions.

(And once again, @Nummer378 is faster than I.)

2 Likes
4

The only way to fix this is by NOT using an EC certificate.

How I can generate RSA instead EC?

1 Like
5

Well, how do you get your certificate for the server? Or are you just in control of the client but not the server?

2 Likes
6

I control servers. Problem have on clients after planned update lets encrypt certs on servers.
Current setting on nginx:

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

#        ssl_ecdh_curve prime256v1:secp384r1;
#        ssl_ecdh_curve prime256v1;
#        ssl_ecdh_curve X25519:P-256:P-384:P-224:P-521;
        ssl_ecdh_curve P-256;
1 Like
7

So, you need to configure whatever ACME client you're using to generate an RSA key instead of an EC one. It's still not clear to me what ACME client you're using. Most of them will use RSA by default and wouldn't switch to EC without somebody specifically telling them to.

1 Like
8

Thank you! I use dehydrate script - it have
--algo (-a) rsa|prime256v1|secp384r1 Which public key algorithm should be used? Supported: rsa, prime256v1 and secp384r1
Now I will try to generate new certs.

I generate new certs with prime256v1 - now Android 7.0 is work.
Thanks all!

2 Likes
9

Glad to hear that's working for you. But do be aware that some other old systems might not support prime256v1 either, and you might need to switch to RSA. And at some point (possibly quite a while from now so old Android may not have as much market share), prime256v1 (P-256) keys will be signed by a P-384 intermediate, which Android 7.0 also won't like. RSA is the most backward-compatible, if that's something you're concerned with.

2 Likes
10

Once again I regenerated the certificate with the RSA, since ApplePay also had problems.

1 Like
11

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