Selbstsigniertes Zertifikat für Domain und Subdomains erstellen - NET :: ERR_CERT_COMMON_NAME_INVALID

82

Ich habe dieses Tutorial zum Erstellen signierter SSL-Zertifikate unter Windows für Entwicklungszwecke befolgt und es hat für eine meiner Domänen hervorragend funktioniert (ich verwende die Hosts-Datei, um DNS zu simulieren). Dann dachte ich mir, dass ich viele Subdomains habe, und das wäre eine Qual, ein Zertifikat für jede von ihnen zu erstellen. Daher habe ich versucht, ein Zertifikat mithilfe eines Platzhalters im CommonFeld zu erstellen, wie in einigen Antworten bei Serverfault vorgeschlagen. So was:

Common Name: *.myserver.net/CN=myserver.net

Nach dem Import dieses Zertifikats in die Trusted Root Certification Authority wird NET::ERR_CERT_COMMON_NAME_INVALIDin Chrome jedoch eine Fehlermeldung für die Hauptdomäne und alle ihre Subodmains angezeigt, z. B.: https://sub1.myserver.netUnd https://myserver.net.

Dieser Server konnte nicht beweisen, dass es sich um myserver.net handelt. Das Sicherheitszertifikat stammt von * .myserver.net / CN = myserver.net.

Dies kann durch eine Fehlkonfiguration oder einen Angreifer verursacht werden, der Ihre Verbindung abfängt.

Stimmt im Feld "Allgemeiner Name" etwas nicht, das diesen Fehler verursacht?

ssl  dns  openssl  windows-7-x64 
— Zed
quelle
Verbrachte viel Zeit damit, dies ebenfalls zu beheben. Siehe meine Antwort hier stackoverflow.com/questions/42816218/…
— Alex Vasilev

Antworten:

20

Wie Rahul sagte, handelt es sich um einen häufigen Chrome- und einen OSX-Fehler. Ich hatte in der Vergangenheit ähnliche Probleme. Tatsächlich hatte ich es endlich satt, die 2 [ja, ich weiß, es sind nicht viele] zusätzlichen Klicks zu machen, wenn ich eine lokale Site auf Arbeit testete.

Für eine mögliche Problemumgehung [unter Windows] würde ich eines der vielen verfügbaren Dienstprogramme für selbstsignierende Zertifikate verwenden .

Empfohlene Schritte:

  1. Erstellen Sie ein selbstsigniertes Zertifikat
  2. Zertifikat in Windows Certificate Manager importieren
  3. Zertifikat in Chrome
    importieren Certificate Manager HINWEIS: In Schritt 3 wird das Problem behoben , das auftritt, sobald Google den Fehler behoben hat. In Anbetracht der veralteten Zeit gibt es in absehbarer Zeit keine ETA. **

    So oft ich Chrome lieber verwende Entwicklung habe ich mich in letzter Zeit in der Firefox Developer Edition wiedergefunden . welches dieses Problem nicht hat.

    Hoffe das hilft :)
— Thomas.Donnelly
quelle
Der Fehler, mit dem Sie verlinkt haben, ist A) nur für OS X gültig und B) betrifft Domänen mit einem nachgestellten ".", Von denen keine für @Zed gültig ist.
— Philip
Hmm welcher Link wäre das?
— Thomas.Donnelly
Der Link zum Chrom-Bug (98627)
— Philip
Unabhängig davon funktioniert das von mir vorgeschlagene Update auch unter Windows, da ich es schon oft verwendet habe.
— Thomas.Donnelly
"So sehr ich Chrome für die Entwicklung bevorzuge, habe ich mich in letzter Zeit in der Firefox Developer Edition wiedergefunden, die dieses Problem nicht hat." Ich kann hier nicht mehr zustimmen.
— Ash
26

Eine Problemumgehung besteht darin, die Domänennamen hinzuzufügen, die Sie als "subjectAltName" (X509v3 Subject Alternative Name) verwenden. Dies können Sie tun, indem Sie Ihre OpenSSL-Konfiguration ( /etc/ssl/openssl.cnfunter Linux) ändern und den v3_reqAbschnitt so ändern , dass er folgendermaßen aussieht:

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.net
DNS.2 = sub1.myserver.net

Vergessen Sie in diesem Fall nicht, den -extensions v3_reqSchalter beim Generieren Ihres neuen Zertifikats zu verwenden. (Siehe auch Wie kann ich mit SubjectAltName mit OpenSSL ein selbstsigniertes Zertifikat erstellen? )

— Fabian S.
quelle
1
Die Verwendung von hat subjectAltName = @alt_namesmein Problem total gelöst. Ich hatte zuvor die DNS-Identität an meine Domain gebunden, indem ich sie bereitgestellt hatte CN=*.example.com. Einstellen DNS.1 = example.comund DNS.2 = *.example.comden Trick gemacht. Seltsame Sache (für mich) war, dass alles bis zum 17.03.2017 funktionierte und einen Tag später aufhörte (hatte eine große Menge von Windows-Udates ausgeführt). Unter Linux ist für mich nichts kaputt gegangen, dies war nur Chrome , Firefox unter Windows .
— Bossi
@bossi: Leider habe ich dieses Problem auf Chrome / Ubuntu. Und cert ist nichts Besonderes, einzelner Host, einzelner DN (internes GitLab-Repository).
— Pawel Kraszewski
Es hat vor ungefähr einer Woche funktioniert, auf dem Server hat sich nichts geändert. 2 andere Server begannen zu schimpfen, weil Groß- und Kleinschreibung nicht übereinstimmten (Zertifikat ist Großbuchstaben, Chrome löscht Adresse in Kleinbuchstaben)
— Pawel Kraszewski
2
@bossi Ich wette, deine Windows-Version befindet sich in der Beta-Phase, oder? Chrome hat Zertifikate ohne ein subjectAltName ab Chrome 58, das sich derzeit in der Beta befindet, veraltet . Das hat mich hart gebissen, weil ich nicht nur nichts davon gesehen hatte, sondern der Fehlername auch sehr irreführend ist (es ist nicht der gebräuchliche Name, der ungültig ist!). Ich war das Gegenteil von dir. Es passierte nur unter Linux für mich, also habe ich stundenlang versucht, meinen lokalen Zertifikatspeicher dort zu reparieren.
— Tobias J
2
@TobyJ ist 58.0.3029.19 beta (64-bit)es. Ich habe den Zertifikatsbaum mit den korrekten subjectAltName-s neu generiert und jetzt funktioniert alles. Und ich stimme zu, die Fehlermeldung ist sehr irreführend, da sie nicht CommonNameungültig ist. Wenn die Nachricht "Zertifikat fehlt ein richtiges subjectAltName" lautete , wären alle viel glücklicher.
— Pawel Kraszewski
16

openssl.confDatei erstellen :

[req]
default_bits = 2048
default_keyfile = oats.key
encrypt_key = no
utf8 = yes
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no

[req_distinguished_name]
C = US
ST = Cary
L = Cary
O  = BigCompany
CN = *.myserver.net

[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.net
DNS.2 = *.myserver.net

Führen Sie diesen Befehl aus:

openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -keyout app.key -out app.crt  -config openssl.conf

Dateien ausgeben app.crtund app.keyfür mich arbeiten.

— Alykoff Gali
quelle
2
Es gibt einen Tippfehler DNS.1 = *.myserver.net. Sollte sein DNS.2 = *.myserver.net. Funktioniert gut für mich.
— Artem Stepin
2
Wenn Sie unter Windows arbeiten, können Sie OpenSL verwenden, das mit Git installiert wurde, indem Sie ein Cmd verwenden, das als Administrator ausgeführt wird, und den folgenden Speicherort verwenden: "C: \ Programme \ Git \ usr \ bin \ openssl.exe" req -x509 -sha256 -nodes -days 3650 -newkey rsa: 2048 -keyout app.key -out app.crt -config openssl.conf
— George
Ich habe CN = localhost, DNS.1 = localhost, DNS.2 = * .localhost: 8080 geschrieben und es funktioniert nicht für mich. Was soll ich noch ändern?
— Esqarrouth
13

Ihre Wildcard *.example.comist nicht decken die Root - Domain , example.comsondern deckt alle Varianten auf einem Unter -Domäne wie www.example.comodertest.example.com

Die bevorzugte Methode besteht darin, alternative Betreffnamen wie in Fabians Antwort festzulegen. Beachten Sie jedoch, dass Chrome derzeit verlangt, dass der allgemeine Name zusätzlich als einer der alternativen Betreffnamen aufgeführt wird (wie in seiner Antwort korrekt dargestellt). Ich habe dieses Problem kürzlich entdeckt, weil ich den allgemeinen Namen example.commit SANs hatte www.example.comund test.example.comdie NET::ERR_CERT_COMMON_NAME_INVALIDWarnung von Chrome erhalten habe. Ich musste eine neue Zertifikatsignierungsanforderung mit example.comdem allgemeinen Namen und einem der SANs generieren . Dann vertraute Chrome dem Zertifikat voll und ganz. Vergessen Sie nicht, das Stammzertifikat als vertrauenswürdige Instanz zur Identifizierung von Websites in Chrome zu importieren.

— Jeff Puckett
quelle
Wenn jemand, der dies liest, Pantheon für das Hosting verwendet, scheint er den allgemeinen Namen Ihres Zertifikats wiederherzustellen, wenn Sie es auf seine Plattform hochladen, wodurch dieses Problem entsteht. Sie müssen anhand der benutzerdefinierten statischen IP-Adresse testen, ob der allgemeine Name des Zertifikats während des Setups erhalten geblieben ist.
— Serraosays
1
Brillant! "Ihr Platzhalter * .example.com deckt nicht die Stammdomäne example.com ab, sondern alle Varianten einer Subdomain wie www.example.com oder test.example.com." Dies war genau das Problem in meinem Fall. Das Update bestand einfach darin, sowohl DNS.1 = example.comals auch DNS.2 = *.example.comunter [alt_names]einzuschließen openssl.cnf.
— Ben Johnson
5

Ich denke, es könnte ein Fehler in Chrom sein. Vor langer Zeit gab es ein ähnliches Problem: Siehe dies.

Versuchen Sie es in einem anderen Browser. Ich denke, es sollte gut funktionieren.

— Rahul Sreeram
quelle
1

Für alle, die darauf stoßen und das Risiko eingehen möchten, es zu testen, gibt es eine Lösung: Wechseln Sie in Chrome in den Inkognito-Modus, und öffnen Sie "Erweitert" und klicken Sie auf "Weiter zu some.url".

Dies kann hilfreich sein, wenn Sie eine Website überprüfen müssen, die Sie selbst pflegen und nur als Entwickler testen (und wenn Sie noch kein ordnungsgemäßes Entwicklungszertifikat konfiguriert haben).

Dies ist natürlich NICHT FÜR MENSCHEN, die eine Website in der Produktion verwenden, bei der dieser Fehler darauf hinweist, dass ein Problem mit der Website-Sicherheit vorliegt.

— bashmisch
quelle
0

Wenn Sie diesen Fehler satt haben. Sie können dafür sorgen, dass Chrome nicht so funktioniert. Ich sage nicht, dass es der beste Weg ist, nur zu sagen, dass es ein Weg ist.

Um dieses Problem zu umgehen, kann ein Windows-Registrierungsschlüssel erstellt werden, mit dem Google Chrome den allgemeinen Namen eines Serverzertifikats verwenden kann, um mit einem Hostnamen übereinzustimmen, wenn dem Zertifikat die Erweiterung subjectAlternativeName fehlt, sofern es erfolgreich validiert und an eine lokal installierte Zertifizierungsstelle gekettet wird Zertifikate.

Datentyp: Boolean [Windows: REG_DWORD] Windows-Registrierungsspeicherort: HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Google \ Chrome Windows / Mac / Linux / Android-Voreinstellungsname: EnableCommonNameFallbackForLocalAnchors Wert: 0x00000001 (Windows), true (Linux), true (Android), (Mac) Führen Sie die folgenden Schritte aus, um einen Windows-Registrierungsschlüssel zu erstellen:

Öffnen Sie Notepad Kopieren Sie den folgenden Inhalt und fügen Sie ihn in den Windows-Registrierungseditor Version 5.00 des Notepads ein

[HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Google \ Chrome] "EnableCommonNameFallbackForLocalAnchors" = dword: 00000001 Gehen Sie zu Datei> Als Dateiname speichern: any_filename.reg Als Typ speichern: Alle Dateien

Wählen Sie einen bevorzugten Speicherort für die Datei

Klicken Sie auf Speichern

Doppelklicken Sie auf die gespeicherte Datei, um sie auszuführen

Klicken Sie in der Warnung des Registrierungseditors auf Ja

Diese Informationen wurden auf der Symantec-Support-Seite gefunden: https://support.symantec.com/en_US/article.TECH240507.html

— beidhändig
quelle
0

Die Antworten haben bei mir (Chrome oder Firefox) beim Erstellen von PWA für die lokale Entwicklung und das Testen nicht funktioniert. NICHT FÜR DIE PRODUKTION VERWENDEN! Ich konnte Folgendes verwenden:

  1. Website für Online- Zertifikatstools mit folgenden Optionen:
    • Allgemeine Namen: Fügen Sie sowohl den "localhost" als auch die IP Ihres Systems hinzu, z. B. 192.168.1.12
    • Alternative alternative Betreffnamen: Fügen Sie "DNS" = "localhost" und "IP" = hinzu <your ip here, e.g. 192.168.1.12>
    • Dropdown-Optionen "CRS" auf "Selbstsignierung" eingestellt
    • Alle anderen Optionen waren Standardeinstellungen
  2. Laden Sie alle Links herunter
  3. Importieren Sie das .p7b-Zertifikat in Windows, indem Sie doppelklicken und "install" / OSX? / Linux?
  4. Der Knoten-App wurden Zertifikate hinzugefügt ... anhand des PWA-Beispiels von Google
    • fügen Sie const https = require('https'); const fs = require('fs');an die Spitze der server.js Datei
    • Kommentar return app.listen(PORT, () => { ... });am Ende der Datei server.js.
    • unten hinzufügen https.createServer({ key: fs.readFileSync('./cert.key','utf8'), cert: fs.readFileSync('./cert.crt','utf8'), requestCert: false, rejectUnauthorized: false }, app).listen(PORT)

Ich habe keine Fehler mehr in Chrome oder Firefox

— James Nelson
quelle
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.