43

There are numerous question on the web where people are having difficulty setting up self signed certificates for use on internal network.

Just to link a few:
Getting Chrome to accept self-signed localhost certificate
Chrome accept self-signed localhost certificate
Generating a self-signed cert with openssl that works in Chrome 58
StartCom certificate Error : ERR_CERT_AUTHORITY_INVALID

I have gone through each and every one of them but still can't get rid of the (net::ERR_CERT_COMMON_NAME_INVALID). error.

Steps followed:

  • key & certificate generation on server

    openssl req \          
-newkey rsa:2048 \
-x509 \
-nodes \
-keyout file.key \
-new \
-out file.crt \
-subj /CN=Hostname \
-reqexts SAN \
-extensions SAN \
-config <(cat /etc/ssl/openssl.cnf \
    <(printf '[SAN]\nsubjectAltName=DNS:192.168.0.1')) \
-sha256 \
-days 3650

  • setting up server process (apache) to use the newly generated certificate and key file for secure connections

  • exporting certificate file from the server on to the client by navigating to https://192.168.0.1:3122 through Chrome Dev Tools and using the Export option
  • adding the CA to list of known Certificate Authorities (on Fedora 26) using
    • certutil
    • sudo cp file.crt /etc/pki/ca-trust/source/anchors; sudo upate-ca-trust
  • restarting chrome

I have also tried various values for the CN field above like: hostname, common.name.com, Common Name, 192.168.0.1

Even after all this the error persists when I navigate to https://192.168.0.1:3122 and I no longer know what I am doing.

The text representation looks similar to:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            9e:ae:33:24:3a:2d:2b:e2
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = Hostname
        Validity
            Not Before: Oct 28 20:18:06 2017 GMT
            Not After : Oct 26 20:18:06 2027 GMT
        Subject: CN = Hostname
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a4:80:6c:3a:1b:5e:c4:e6:f6:7d:a5:be:d6:cd:
                    d9:23:bd:1a:b1:e6:f1:e3:b0:76:47:37:a3:d8:b0:
                    60:44:23:c3:8a:58:1c:c3:0a:99:3d:42:32:ca:8b:
                    ec:31:9d:a8:df:6c:13:43:e6:78:12:b8:24:04:5a:
                    9f:6e:11:24:2a:56:e3:20:36:78:a4:cc:ed:45:7c:
                    a3:c1:36:7b:25:f6:6b:2d:01:59:02:74:8b:7a:13:
                    ec:83:63:90:2e:a0:a3:aa:23:de:ea:f0:8e:1f:99:
                    b9:50:b1:5f:64:e4:c9:91:c0:0c:56:15:3c:c0:ff:
                    0f:bf:e1:af:7a:bf:51:40:37:b0:34:20:95:a1:05:
                    14:k2:35:20:e8:98:48:65:ad:26:cc:de:a2:50:48:
                    77:8c:e2:7a:d5:bd:83:96:86:ef:20:79:2f:15:a3:
                    07:48:f4:1f:c7:9d:a1:4b:bd:ee:47:83:51:f3:09:
                    27:ed:b7:09:c8:56:40:0c:68:25:92:d8:62:dc:14:
                    6c:fa:f1:e3:93:1b:79:3c:58:9c:53:69:ff:6a:0f:
                    ee:4c:9f:8e:22:2d:62:6b:b3:ae:22:d6:e3:d0:bd:
                    06:43:a7:c3:e1:1e:23:07:61:b0:4e:64:14:92:0c:
                    5b:f1:a8:c5:29:67:64:7d:65:10:b9:60:41:b8:3b:
                    1y:1f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:192.168.0.1
    Signature Algorithm: sha256WithRSAEncryption
         11:65:6d:86:04:7f:5a:b0:ce:b2:6e:95:7e:03:8c:fe:a9:d0:
         81:2c:6f:50:63:2e:91:77:79:cd:27:32:b0:19:2b:ac:ea:c0:
         4b:f7:56:d9:be:34:54:f1:a6:1d:bc:d0:3b:bb:bf:90:0e:2d:
         1d:83:28:97:8e:f8:37:5d:3e:00:5a:cd:3d:36:5d:c4:5d:a8:
         7e:a4:59:f0:91:3d:af:3d:28:03:3e:78:3b:5b:0a:fb:24:34:
         02:a2:09:ec:d6:0c:58:63:ab:69:26:5e:fe:1d:1f:19:54:0f:
         68:4e:31:f9:de:1e:de:86:81:3f:b7:62:c5:67:02:05:a2:7a:
         03:f4:b5:3b:ba:c4:ba:26:8e:a2:ee:1c:ef:69:63:07:b0:97:
         fd:a8:42:e2:11:6d:de:b5:70:a5:4a:62:d2:62:d9:5b:17:f4:
         d5:cd:6f:71:75:dd:35:33:55:52:2e:30:29:f8:42:ec:b9:d3:
         82:85:a1:e7:f6:f5:90:dd:cb:07:15:a7:44:70:1c:93:e6:ec:
         03:3a:be:41:87:3c:f0:a4:88:a5:65:d9:29:2c:78:de:90:b8:
         6a:8b:99:6e:d0:e5:8c:08:a4:71:51:fd:1d:e1:8c:0c:17:d5:
         b0:31:fc:7f:99:23:dd:1a:c4:0b:45:17:68:88:67:c6:22:df:
         2b:ac:ea:c0

Please note that this is my 1st time setting up SSL/TLS certificates for such purposes. Please advice on how to get rid of the error.

Improve this question
3
  • Add a text representation of your certificate to your question. Use openssl x509 -noout -text -in <filename>.
    – garethTheRed
    Oct 28, 2017 at 21:02
  • I have added the text representation.
    – Ashesh
    Oct 28, 2017 at 21:18
  • I think, Chrome expects IP address to be encoded as IP address in SAN extension, not a DNS name.
    – Crypt32
    Oct 28, 2017 at 21:46

2 Answers 2

Reset to default
48

Chrome 58+ no longer matches the Common Name (CN) in certs.

Now it uses Subject Alternative Names (SAN) instead.

SAN must contain proper DNS or IP entry.

  • When DNS is used, it should be a resolvable FQDN name.
  • When an IP address is used, it should be explicitely specified as such within the SAN chain.

That said, this should work :

openssl req \
-newkey rsa:2048 \
-x509 \
-nodes \
-keyout file.key \
-new \
-out file.crt \
-subj /CN=Hostname \
-reqexts SAN \
-extensions SAN \
-config <(cat /etc/ssl/openssl.cnf \
    <(printf '[SAN]\nsubjectAltName=DNS:hostname,IP:192.168.0.1')) \
-sha256 \
-days 3650
Improve this answer
6
  • 2
    Specifically, this is due to tools.ietf.org/html/rfc6125#section-5.7.3.1 which states "For TLS authentication with X.509 certificates, an identity from the DNS namespace MUST be checked against each subjectAltName extension of type dNSName present in the certificate. If no such extension is present, then the identity MUST be compared to the (most specific) Common Name in the Subject field of the certificate." So, if any SAN exists then the CN is not checked.
    – Jason Martin
    Oct 28, 2017 at 22:56
  • 10
    Correct me if i'm wrong, but Chrome no longer accepts certificates that fallback to common name. So even if a SAN does not exist, the CN is not checked. So the SAN seems mandatory.
    – krisFR
    Oct 28, 2017 at 23:07
  • 1
    @krisFR is right because I already tried with certificates without the SAN extension which failed. Specifying the IP field was the solution.
    – Ashesh
    Oct 29, 2017 at 14:24
  • 1
    Life saver. For anyone trying this out on Windows, Cygwin comes with a copy of openssl.cnf here: .\cygwin\etc\defaults\etc\pki\tls\ Also, I had to change my CN=hostname and DNS:hostname lines to be localhost instead of hostname
    – abelito
    Apr 17, 2019 at 11:15
  • Worked perfectly ! Had to add the certificate with this procedure : corvil.com/kb/…
    – yota
    Oct 18, 2019 at 8:31
0

In addition to krisFR's answer, newer versions of OpenSSL support injecting the subject alt name directly, compacting the command even further:

openssl req \
-newkey rsa:2048 \
-x509 \
-nodes \
-keyout file.key \
-new \
-out file.crt \
-subj /CN=Hostname \
-addtext 'subjectAltName=DNS:hostname,IP:192.168.0.1' \
-sha256 \
-days 3650
Improve this answer
1

You must log in to answer this question.

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