Certificate is untrusted on some Android cell phone

I found that the Letsencrypt SSL certificate is untrusted on some Android cell phone, But it works fine on IOS device and browsers.

I check the SSL security online .the result shows that it is failed on java 6u45 and java 7u80.

below is my nginx config

ssl_certificate /data/letsencrypt/www.haoshiqi.net/fullchain.cer;
ssl_certificate_key /data/letsencrypt/www.haoshiqi.net/www.haoshiqi.net.key;
include /data/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /data/letsencrypt/ssl-dhparams.pem;

Could you please help me about this ? Thank you very much!

My domain is: www.haoshiqi.net
My web server is (include version): nginx/1.15.10
The operating system my web server runs on is (include version): CentOS Linux release 7.6.1810
I can login to a root shell on my machine (yes or no, or I don’t know): yes

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

1 Like

ssllab test says that you won't use traditional DH (your server doesn't allow that) and site only works with browsers that support SNI (but this supported from android 4.0) how old thoses android phones are?

1 Like

Client with java 6u45 version will definitely fail, since it does not support SNI, while your server is running with SNI.

what can I do to support java 6u45 client ?

Please share us your Nginx configuration file by using nginx -T.
Also please make sure you have full root access for the IP address, since you’ll need the “dedicated IP” if you want to support a client without SNI support.

Thanks

I am not sure. I encountered this problem several times on different cell phones . but I can’t reproduce this problem now

server {
        listen 443 ssl http2;

        server_name www.haoshiqi.net;
        root /data/app/h5.www/current;

        error_log /data/logs/nginx/h5.withoutwww.error.log error;
        access_log /data/logs/nginx/h5.withoutwww.access.log main;
    ssl_certificate /data/letsencrypt/www.haoshiqi.net/fullchain.cer;
    ssl_certificate_key /data/letsencrypt/www.haoshiqi.net/www.haoshiqi.net.key;
       include /data/letsencrypt/options-ssl-nginx.conf;
       ssl_dhparam /data/letsencrypt/ssl-dhparams.pem;


        location / {
                index hsq.html;
                add_header Content-Security-Policy upgrade-insecure-requests;
        }

}

server {

if ($host = "www.haoshiqi.net") {
    return 301 https://$host$request_uri;
}

listen 80;
server_name www.haoshiqi.net;
return 404;

}

I am not sure. I encountered this problem several times on different cell phones . but I can’t reproduce this problem now

it may be just a time scew so that cert was not yet valid on thoes clients, but as time goes it resloved itself. LE backdates cert an hour because of it, but it may be not enought if time difference is large enough

include /data/letsencrypt/options-ssl-nginx.conf

what it says?

below is the content of the file

# This file contains important security parameters. If you modify this file
# manually, Certbot will be unable to automatically provide future security
# updates. Instead, Certbot will print and log an error message with a path to
# the up-to-date file that you will need to refer to when manually updating
# this file.

ssl_session_cache shared:le_nginx_SSL:1m;
ssl_session_timeout 1440m;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;

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";

If you only wish to add support for devices doesn’t support SNI and you shared us your entire nginx configuration, add default_server next to the listen derivative for the nginx configuration.

server {
        listen 443 ssl http2 default_server;

        server_name www.haoshiqi.net;
        root /data/app/h5.www/current;

        error_log /data/logs/nginx/h5.withoutwww.error.log error;
        access_log /data/logs/nginx/h5.withoutwww.access.log main;
    ssl_certificate /data/letsencrypt/www.haoshiqi.net/fullchain.cer;
    ssl_certificate_key /data/letsencrypt/www.haoshiqi.net/www.haoshiqi.net.key;
       include /data/letsencrypt/options-ssl-nginx.conf;
       ssl_dhparam /data/letsencrypt/ssl-dhparams.pem;


        location / {
                index hsq.html;
                add_header Content-Security-Policy upgrade-insecure-requests;
        }

}

server {

if ($host = "www.haoshiqi.net") {
    return 301 https://$host$request_uri;
}

listen 80;
server_name www.haoshiqi.net;
return 404;

}

Keep in mind that theres only 1 possible non-SNI site per IP, means if you want to have more than 1 site that support devices without SNI, you’ll need to have more IP address.

Thanks

Thank you ,But there are lots of sites on one WEB server .It is realistic to allocate public IP address for each site

Hi @jessehuang

that's the wrong way. IPv4 addresses are limited.

And SNI is old, very old. So every "not too old" browser supports SNI.

Result: Ignore the devices without SNI.

In theory, you can create one certificate with all domain names and use that with all of your domains. But then max. 100 domain names allowed (50 domains with non-www and www).

1 Like

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