Home / server / Questions / 986586
Accepted
B T
Asked: 2019-10-03 19:43:23 +0800 CST

Chrome desktop and android refuses to accept trusted self-signed cert

  • 772

I created a self-signed certificate using the following command using OpenSSL 1.1.1b (26 Feb 2019):

openssl req -nodes -new --days 900 -subj /CN=192.168.0.104:8080 -x509 -keyout server.key -out server.crt

I then used windows mmc imported the resulting server.crt into Console Root -> Certificates - Current User -> Trusted Root Certification Authorities -> Certificates

When I go to the page in chrome tho at 192.168.0.104:8080, it tells me the page is "Not Secure" (tho if I look at the certificate info, the Certificate Status under Certification path says "This certificate is OK."

I did a similar process on my android phone, uploading it to my phone, adding the certificate in the Encryption & credentials settings section.

However, when I go to the page, it tells me the "server's certificate does not match the URL".

What am I doing wrong here?

Update:

I'm now using the req.conf

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = CA
L = Belmont
O = N/A
OU = N/A
CN = 192.168.0.104
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.0 = localhost
IP.0 = 192.168.0.104

And creating the certificate and key with:

openssl req -x509 -nodes -days 999 -newkey rsa:2048 -keyout server.key -out server.crt -config req.conf

Then I restarted chrome on windows (I can't believe restarting programs for settings to take effect is still necessary in 2019). Windows chrome then recognizes it fine.

However on android, I can't even install this certificate - it tells me "Private key required to install a certificate". This is even more confusing.

ssl-certificate

1 Answers

  1. Best Answer
    1. Chrome requires SAN. For two years now, Chrome has used the Subject Alternative Name (SAN) extension in a certificate, NOT the CommonName (CN) attribute in the Subject as was used last century. (Other browsers, TTBOMK all, and nearly all clients today prefer SAN, but will fall back to Subject CN if necessary; Chrome won't.) You don't tell us what is in your OpenSSL config file, or what version you use. OpenSSL 1.1.1 now has a commandline option -addext to req -new -x509, but otherwise you need to set SAN in the config file at least logically -- although on Unix, and I believe WSL, you can have the shell create that config file as an automatic temporary file with <(commands) (or in zsh =(commands)). See:

    Generating a self-signed cert with openssl that works in Chrome 58
    Can not get rid of `net::ERR_CERT_COMMON_NAME_INVALID` error in chrome with self-signed certificates
    https://security.stackexchange.com/questions/172440/generate-x509-err-cert-common-name-invalid
    https://security.stackexchange.com/questions/74345/provide-subjectaltname-to-openssl-directly-on-command-line
    https://security.stackexchange.com/questions/158632/burp-suite-although-my-configurations-are-correct-still-chrome-doesnt-allows

    but note those Qs are about a cert for a domainname, which uses SAN entry type DNS; for an IPadddress you need to use IP instead.

    1. Omit the port. Even for browsers/clients that still use Subject CN, it should be the host name or IPaddress without the port. (For SAN you can't get it wrong because the SAN syntax only allows DNS:dommainname or IP:IPv4or8addr and no port.)

    PS: 8080 is normally used for alternate HTTP, and 8443 for alternate HTTPS. Using 8080 for HTTPS is confusing.

    • 5