Der Fehler "net :: ERR_CERT_COMMON_NAME_INVALID" in Chrome mit selbstsignierten Zertifikaten kann nicht behoben werden


19

Es gibt zahlreiche Fragen im Internet, bei denen es schwierig ist, selbstsignierte Zertifikate für die Verwendung im internen Netzwerk einzurichten.

Um nur ein paar zu verlinken:
Chrome dazu zu bringen, selbstsigniertes localhost-Zertifikat zu
akzeptieren Chrome selbstsigniertes localhost-Zertifikat zu akzeptieren Mit
openssl ein selbstsigniertes Zertifikat erstellen, das in Chrome funktioniert 58
StartCom-Zertifikat Fehler: ERR_CERT_AUTHORITY_INVALID

Ich habe jeden einzelnen von ihnen durchlaufen, kann den (net::ERR_CERT_COMMON_NAME_INVALID).Fehler aber immer noch nicht beseitigen .

Schritte befolgt:

  • Schlüssel- und Zertifikaterstellung auf dem 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
    
  • Einrichten des Serverprozesses (Apache) zur Verwendung des neu generierten Zertifikats und der Schlüsseldatei für sichere Verbindungen

  • Exportieren der Zertifikatdatei vom Server auf den Client, indem Sie über Chrome Dev Tools zu https://192.168.0.1:3122 navigieren und die Option Exportieren verwenden
  • Hinzufügen der Zertifizierungsstelle zur Liste der bekannten Zertifizierungsstellen (unter Fedora 26) mit
    • certutil
    • sudo cp file.crt /etc/pki/ca-trust/source/anchors; sudo upate-ca-trust
  • Chrome neu starten

Ich habe auch verschiedene Werte für das versuchte CNFeld oben wie: hostname, common.name.com, Common Name,192.168.0.1

Auch nach all dem bleibt der Fehler bestehen, wenn ich zu https://192.168.0.1:3122 navigiere und nicht mehr weiß, was ich tue.

Die Textdarstellung sieht ähnlich aus wie:

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

Bitte beachten Sie, dass ich zum ersten Mal SSL / TLS-Zertifikate für solche Zwecke einrichte. Bitte geben Sie Hinweise, wie Sie den Fehler beheben können.


Fügen Sie Ihrer Frage eine Textdarstellung Ihres Zertifikats hinzu. Verwenden Sie openssl x509 -noout -text -in <filename>.
garethTheRed

Ich habe die Textdarstellung hinzugefügt.
Ashesh Kumar Singh

Ich denke, Chrome erwartet, dass die IP-Adresse als IP-Adresse in der SAN-Erweiterung codiert wird, nicht als DNS-Name.
Crypt32

Antworten:


25

Chrome 58+ stimmt nicht mehr mit dem allgemeinen Namen ( CN) in Zertifikaten überein.

Jetzt werden SANstattdessen alternative Antragstellernamen ( ) verwendet.

SANmuss richtige DNSoder IPeintrag enthalten.

  • Bei Verwendung von DNS sollte es sich um einen auflösbaren FQDN-Namen handeln.
  • Wenn eine IP-Adresse verwendet wird, sollte diese innerhalb der SANKette explizit als solche angegeben werden .

Das heißt, dies sollte funktionieren:

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

1
Dies liegt insbesondere an tools.ietf.org/html/rfc6125#section-5.7.3.1, in dem angegeben ist, dass bei der TLS-Authentifizierung mit X.509-Zertifikaten eine Identität aus dem DNS-Namespace auf jede vorhandene subjectAltName-Erweiterung vom Typ dNSName überprüft werden muss Wenn keine solche Erweiterung vorhanden ist, MUSS die Identität mit dem (spezifischsten) allgemeinen Namen im Feld "Betreff" des Zertifikats verglichen werden. " Wenn also ein SAN vorhanden ist, wird der CN nicht überprüft.
Jason Martin

7
Korrigieren Sie mich, wenn ich falsch liege, aber Chrome akzeptiert keine Zertifikate mehr, die auf den allgemeinen Namen zurückgreifen. Selbst wenn kein SAN vorhanden ist, wird der CN nicht überprüft. Das SAN scheint also obligatorisch zu sein.
krisFR

@krisFR ist richtig, weil ich bereits mit Zertifikaten ohne die SAN-Erweiterung versucht habe, was fehlgeschlagen ist. Das Festlegen des IP-Felds war die Lösung.
Ashesh Kumar Singh

1
Lebensretter. Für alle, die dies unter Windows ausprobieren, wird Cygwin mit einer Kopie der Datei openssl.cnf geliefert:. \ Cygwin \ etc \ defaults \ etc \ pki \ tls \ Außerdem musste ich meine Zeilen CN = hostname und DNS: hostname ändern localhost statt hostname
abelito

Perfekt funktioniert! Musste das Zertifikat mit diesem Verfahren hinzufügen: corvil.com/kb/…
yota
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.