5

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.

B T
  • 155
  • 2
  • 8

1 Answers1

5
  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.

xnumad
  • 3
  • 2
dave_thompson_085
  • 3,100
  • 1
  • 15
  • 14
  • Thanks for the tips! I tried adding SAN info, but the problem persists. I gave an update in the OP – B T Oct 03 '19 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. – dave_thompson_085 Oct 04 '19 at 06: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 06 '19 at 01:17
  • After restarting chrome on windows, I got that to work fine. Android is still a pain. – B T Oct 06 '19 at 03: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 06 '19 at 17:17
  • (BT) I'm not an Android expert, but my phone has separate items for 'user credentials' (which are used to prove yourself and thus need private key) and 'trusted credentials' (which are used to verify others, and shouldn't) -- are you using the latter? – dave_thompson_085 Oct 07 '19 at 05:00
  • Hmm, so I'm looking under settings -> security (Advanced) -> Encryption & Credentials. The only place I can see to add a certificate is the "Install from storage" item. – B T Oct 08 '19 at 03:43