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= -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, 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?


I'm now using the req.conf

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

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.

1 Answer 1

  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

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.

  • Thanks for the tips! I tried adding SAN info, but the problem persists. I gave an update in the OP
    – B T
    Oct 3, 2019 at 17:58
  • You put (copied?) entry type DNS (DNS.1, but OpenSSL ignores the .1) in SAN. As I said, for an IPaddress you must use entry type IP. Personally for a single entry I'd use the inline syntax not the @section syntax, but both work. PS: x509_extensions in the [req] section of the config, and -extensions on the commandline, do exactly the same thing; you don't need both. Oct 4, 2019 at 6:35
  • Ah. Ok, I changed to using IP.0 instead of DNS.1 (Updated the OP). But I still see the same problem.
    – B T
    Oct 6, 2019 at 1:17
  • After restarting chrome on windows, I got that to work fine. Android is still a pain.
    – B T
    Oct 6, 2019 at 3:17
  • So it seems like making chrome happy with the cert wasn't necessary to do what I wanted, and I figured it out. But the SAN advice was very helpful! Thanks!
    – B T
    Oct 6, 2019 at 17:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .