Frage Generieren eines selbstsignierten Zertifikats mit openssl, das in Chrome 58 funktioniert


Ab Chrome 58 werden keine selbstsignierten Zertifikate mehr akzeptiert Common Name: https://productforums.google.com/forum/#!topic/chrome/zVo3M8CgKzQ;context-place=topicsearchin/chrome/category$ 3ACanary% 7Csort: Relevanz% 7Cspell: false

Stattdessen muss es verwendet werden Subject Alt Name. Ich habe diesen Leitfaden bisher zum Generieren eines selbstsignierten Certs verwendet: https://devcenter.heroku.com/articles/ssl-certificate-self Das hat super funktioniert, weil ich das benötigt habe server.crt und server.key Dateien für das, was ich mache. Ich muss jetzt neue Zertifikate erstellen, die die einschließen SAN Alle meine Versuche haben jedoch mit Chrome 58 nicht funktioniert.

Hier ist was ich getan habe:

Ich folgte den Schritten auf dem oben genannten Heroku-Artikel, um den Schlüssel zu generieren. Ich habe dann eine neue OpenSSL-Konfigurationsdatei geschrieben:

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name
req_extensions      = san
extensions          = san
[ req_distinguished_name ]
countryName         = US
stateOrProvinceName = Massachusetts
localityName        = Boston
organizationName    = MyCompany
[ san ]
subjectAltName      = DNS:dev.mycompany.com

Dann erzeugt die server.crt mit folgendem Befehl:

openssl req \
-new \
-key server.key \
-out server.csr \
-config config.cnf \
-sha256 \
-days 3650

Ich bin auf einem Mac, also habe ich die geöffnet server.crt Datei mit Schlüsselbund, fügte es zu meinen Systemzertifikaten hinzu. Ich stelle es dann auf Always Trust.

Mit Ausnahme der Konfigurationsdatei zum Festlegen des SAN-Werts waren dies ähnliche Schritte, die ich in früheren Chrome-Versionen verwendet habe, um das selbstsignierte Zertifikat zu erstellen und ihm zu vertrauen.

Aber danach bekomme ich immer noch die ERR_CERT_COMMON_NAME_INVALID in Chrome 58.


39
2018-04-21 13:50


Ursprung




Antworten:


Meine Lösung:

openssl req \
    -newkey rsa:2048 \
    -x509 \
    -nodes \
    -keyout server.key \
    -new \
    -out server.crt \
    -subj /CN=dev.mycompany.com \
    -reqexts SAN \
    -extensions SAN \
    -config <(cat /System/Library/OpenSSL/openssl.cnf \
        <(printf '[SAN]\nsubjectAltName=DNS:dev.mycompany.com')) \
    -sha256 \
    -days 3650

Status: Funktioniert für mich


49
2018-04-21 15:55



großer Einsatz von Subshell. Ich denke du kannst es ein wenig vereinfachen: -config <(cat /System/Library/OpenSSL/openssl.cnf ; printf '[SAN]\nsubjectAltName=DNS:dev.mycompany.com') - jrwren
Ich erhalte den Subject Alt Name Fehler nicht mehr, aber jetzt bekomme ich eine Fehlermeldung über den allgemeinen Namen, und das heruntergeladene cert auf "immer vertrauen" zu setzen funktioniert nicht. Irgendwelche Gedanken? @ bcardarella - rugbert
Mit der Aktualisierung auf Chrome 59 zeigt das Zertifikat einen Fehler wie den folgenden: Es gibt Probleme mit der Zertifikatskette der Site (net :: ERR_CERT_COMMON_NAME_INVALID). - theHarsh
ich habe mich verändert dev.company.name zu localhost und das funktionierte für die lokale Entwicklungsumgebung von localhost. Auf MacOS musste ich das Zertifikat auch zu Keychain hinzufügen und SSL auf "Always Trust" setzen. - Daniel M.
Das ist bei weitem die einfachste Lösung und erfordert keine Verschmelzung mit sslconf oder Installation einer CA. - bp.


Speichern Sie dieses Skript in Windows in Ihrem SSL-Ordner als makeCERT.bat. Es erstellt diese Dateien: example.cnf, example.crt, example.key

@echo off

REM IN YOUR SSL FOLDER, SAVE THIS FILE AS: makeCERT.bat
REM AT COMMAND LINE IN YOUR SSL FOLDER, RUN: makecert
REM IT WILL CREATE THESE FILES: example.cnf, example.crt, example.key
REM IMPORT THE .crt FILE INTO CHROME Trusted Root Certification Authorities
REM REMEMBER TO RESTART APACHE OR NGINX AFTER YOU CONFIGURE FOR THESE FILES

REM PLEASE UPDATE THE FOLLOWING VARIABLES FOR YOUR NEEDS.
SET HOSTNAME=example
SET DOT=com
SET COUNTRY=US
SET STATE=KS
SET CITY=Olathe
SET ORGANIZATION=IT
SET ORGANIZATION_UNIT=IT Department
SET EMAIL=webmaster@%HOSTNAME%.%DOT%

(
echo [req]
echo default_bits = 2048
echo prompt = no
echo default_md = sha256
echo x509_extensions = v3_req
echo distinguished_name = dn
echo:
echo [dn]
echo C = %COUNTRY%
echo ST = %STATE%
echo L = %CITY%
echo O = %ORGANIZATION%
echo OU = %ORGANIZATION_UNIT%
echo emailAddress = %EMAIL%
echo CN = %HOSTNAME%.%DOT%
echo:
echo [v3_req]
echo subjectAltName = @alt_names
echo:
echo [alt_names]
echo DNS.1 = *.%HOSTNAME%.%DOT%
echo DNS.2 = %HOSTNAME%.%DOT%
)>%HOSTNAME%.cnf

openssl req -new -x509 -newkey rsa:2048 -sha256 -nodes -keyout %HOSTNAME%.key -days 3560 -out %HOSTNAME%.crt -config %HOSTNAME%.cnf

10
2018-05-18 18:30





Hier ist eine Lösung, die für mich funktioniert:

Erstellen Sie einen CA-Schlüssel und ein Zertifikat

# openssl genrsa -out server_rootCA.key 2048
# openssl req -x509 -new -nodes -key server_rootCA.key -sha256 -days 3650 -out server_rootCA.pem

Erstellen Sie server_rootCA.csr.cnf

# server_rootCA.csr.cnf
[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn

[dn]
C=DE
ST=Berlin
L=NeuKoelln
O=Weisestrasse
OU=local_RootCA
emailAddress=ikke@server.berlin
CN = server.berlin

Erstellen Sie die Konfigurationsdatei v3.ext

# v3.ext
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = server.berlin

Erstellen Sie den Serverschlüssel

# openssl req -new -sha256 -nodes -out server.csr -newkey rsa:2048 -keyout server.key -config <( cat server_rootCA.csr.cnf )

Erstellen Sie ein Server-Zertifikat

# openssl x509 -req -in server.csr -CA server_rootCA.pem -CAkey server_rootCA.key -CAcreateserial -out server.crt -days 3650 -sha256 -extfile v3.ext

Fügen Sie Zertifikat und Schlüssel zum Abschnitt Apache2-Site-Datei, HTTPS (Port 443) hinzu

SSLCertificateFile    /etc/apache2/ssl/server.crt
SSLCertificateKeyFile    /etc/apache2/ssl/server.key

Kopieren Sie server_rootCA.pem vom Server auf Ihren Rechner.

# scp you@server.berlin:~/server_rootCA.pem .

.. und fügen Sie es dem Chromium Browser hinzu

Chromium -> Setting -> (Advanced) Manage Certificates -> Import -> 'server_rootCA.pem'

Sie sind alle fertig! 

P.S. Anstatt ein funktionierendes CA & Server-Cert-Paar zu erstellen (gemäß den obigen Anweisungen), können Sie einfach HSTS-Header in Ihrer HTTP-Server-Konfiguration deaktivieren. Dadurch wird verhindert, dass Chrome HTTPS erzwingt, und Benutzer können auf "Erweitert → Weiter zu Ihrer.url (unsicheren)" klicken, ohne Ihr benutzerdefiniertes Zertifikat CA (server_rootCA.pem) beschaffen und installieren zu müssen. Mit anderen Worten: Wenn Sie HSTS deaktivieren müssen, wird Ihre Website öffentlich über HTTP und / oder eine unsichere HTTPS-Verbindung angezeigt (Vorsicht!).

Für Apache2 fügen Sie den folgenden Abschnitt zu site-file, HTTP (port 80) hinzu

Header unset Strict-Transport-Security
Header always set Strict-Transport-Security "max-age=0;includeSubDomains"

Getestet auf Debian / Apache2.4 + Debian / Chromium 59

https://ram.k0a1a.net/self-signed_https_cert_after_chrome_58


9
2017-08-10 00:53



Der Weg einer CA-Rootberechtigung, die später die einzelnen Zertifikate signiert, ist die einzige Möglichkeit, Chrome vollständig authentifizieren zu lassen. hat auch den Vorteil, dass ich nur Leute dazu bringen musste, ein einzelnes Zertifikat zu installieren. Vielen Dank - geoff
Kann mir bitte jemand erklären, warum alle in diesem Bereich Bashismen zu benutzen scheinen -config <( cat server_rootCA.csr.cnf ) statt nur -config server_rootCA.csr.cnf? - Caesar


Es gibt mehrere gute Antworten, die Beispiele geben, wie man das funktioniert, aber keine, die erklären, wo bei deinem Versuch etwas schief gelaufen ist. OpenSSL kann sein ziemlich oft nicht intuitiv, so dass es sich lohnt, durch zu gehen.

Zunächst ignoriert OpenSSL standardmäßig alle definierten Namenwerte Sie bieten in der Konfig. Wenn Sie sie verwenden möchten, müssen Sie hinzufügen prompt = nozu deiner Konfiguration. Außerdem erzeugt der Befehl, wie er geschrieben wurde, nur ein Zertifikat anfordern kein Zertifikat selbst, also die -days Befehl macht nichts.

Wenn Sie Ihre Zertifikatsanforderung mit diesem Befehl generieren, den Sie gegeben und überprüft haben Das Ergebnis, der Betreff Alt Name ist vorhanden:

$ openssl req -new -key server.key -out server.csr -config config.cnf -sha256
$ openssl req -text -noout -in server.csr
Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: C = US, ST = Massachusetts, L = Boston, O = MyCompany
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    ...
                Exponent: 65537 (0x10001)
        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name:
                DNS:dev.mycompany.com
    Signature Algorithm: sha256WithRSAEncryption
         ...

Aber dann, wenn Sie das Zertifikat mit dem Befehl in heroku Link generieren und Inspect das Ergebnis, der Subject Alt Name fehlt:

$ openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt
$ openssl x509 -text -noout -in server.crt
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            89:fd:75:26:43:08:04:61
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = Massachusetts, L = Boston, O = MyCompany
        Validity
            Not Before: Jan 21 04:27:21 2018 GMT
            Not After : Jan 21 04:27:21 2019 GMT
        Subject: C = US, ST = Massachusetts, L = Boston, O = MyCompany
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    ...
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption
         ...

Der Grund dafür ist, dass OpenSSL standardmäßig keine Erweiterungen aus der Anfrage kopiert zum Zertifikat. Normalerweise würde das Zertifikat von einer CA erstellt / signiert basierend auf einer Anfrage von einem Kunden, und einige Erweiterungen könnten die gewähren Zertifikat mehr Macht als die CA beabsichtigte, wenn sie blind vertrauen würden die in der Anfrage definierten Erweiterungen.

Es gibt Möglichkeiten, OpenSSL anzuweisen, die Erweiterungen zu kopieren, aber IMHO ist es mehr arbeiten, als nur die Erweiterungen in einer Konfigurationsdatei zur Verfügung zu stellen, wenn Sie das erstellen Zertifikat.

Wenn Sie versuchen, Ihre vorhandene Konfigurationsdatei zu verwenden, wird es nicht funktionieren, weil Die oberste Ebene ist markiert [req] Diese Einstellungen gelten nur für den Befehl req, nicht für den Befehl x509. Es ist nicht erforderlich, eine Schnittmarkierung der obersten Ebene zu verwenden, sodass Sie diese erste Zeile einfach entfernen können. Dann funktioniert sie sowohl für die Generierung von Anforderungen als auch für das Zertifikat.

$ openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt -extfile config.cnf

Alternativ können Sie die -x509 Argument zur req Befehl zum Generieren ein selbstsigniertes Zertifikat in einem einzigen Befehl, anstatt zunächst ein Anfrage und dann ein Zertifikat. In diesem Fall ist es nicht notwendig, das zu entfernen [req] Abschnittszeile, da dieser Abschnitt vom Befehl req gelesen und verwendet wird.

$ openssl req -x509 -sha256 -days 365 -key server.key -out server.crt -config config.cnf

Zur Erinnerung, hier ist die modifizierte Konfigurationsdatei, die in den obigen Befehlen verwendet wird:

default_bits        = 2048
distinguished_name  = dn
x509_extensions     = san
req_extensions      = san
extensions          = san
prompt              = no
[ dn ]
countryName         = US
stateOrProvinceName = Massachusetts
localityName        = Boston
organizationName    = MyCompany
[ san ]
subjectAltName      = DNS:dev.mycompany.com

3
2018-02-02 01:28





Meine Lösung ist, die Hauptsache zu behalten openssl.cnf wie es ist und nur am Ende, um einen neuen Abschnitt wie hinzuzufügen [ cert_www.example.com ] wo www.example.com ist die Website, für die ich ein Zertifikat erstellen möchte, und legen Sie die subjectAltName Ich würde (und alles andere) brauchen. Natürlich könnte der Abschnitt benannt werden, was immer Sie wollen.

Danach kann ich die openssl req Befehl wie zuvor, nur hinzufügen -extensions cert_www.example.com für seinen Inhalt abgeholt werden und ich füge hinzu -subj um alle DN-Informationen direkt hinzuzufügen.

Vergessen Sie nicht, den Zertifikatsinhalt nach seiner Erstellung und vor seiner Verwendung mit zu überprüfen openssl x509 -text


2
2018-04-23 22:36





Bash-Skript mit config eingebrannt

Als Shell-Skript, das mit bash plattformübergreifend funktionieren sollte. Geht davon aus HOSTNAME env für die Shell gesetzt oder einen Hostnamen Ihrer Wahl angeben, z. self_signed_cert.sh test

set -e

if [ -z "$1" ]; then
  hostname="$HOSTNAME"
else
  hostname="$1"
fi

local_openssl_config="
[ req ]
prompt = no
distinguished_name = req_distinguished_name
x509_extensions = san_self_signed
[ req_distinguished_name ]
CN=$hostname
[ san_self_signed ]
subjectAltName = DNS:$hostname, DNS:localhost
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = CA:true
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment, keyCertSign, cRLSign
extendedKeyUsage = serverAuth, clientAuth, timeStamping
"

openssl req \
  -newkey rsa:2048 -nodes \
  -keyout "$hostname.key.pem" \
  -x509 -sha256 -days 3650 \
  -config <(echo "$local_openssl_config") \
  -out "$hostname.cert.pem"
openssl x509 -noout -text -in "$hostname.cert.pem"

Das obige injiziert mehr oder weniger die minimale Konfigurationsdatei info openssl benötigt.

Hinweis, im Lieferumfang enthalten DNS:localhost als SAN, um das Testen über localhost einfacher zu ermöglichen. Entfernen Sie dieses zusätzliche Bit aus dem Skript, wenn Sie es nicht möchten.

Kredit

bcardarellas Antwort ist toll (kann nicht kommentieren / up-stimme wegen unzureichender rep). Die Antwort verwendet jedoch einen vorhandenen Speicherort der openssl-Konfigurationsdatei, der plattformspezifisch ist ...

Funktioniert bei mir

Offensichtlich müsste man einfach die openssl-Konfigurationsdatei für die eigene gegebene Plattform finden und den korrekten Speicherort ersetzen.

Prüfung

Für eine Möglichkeit zu testen, zu importieren test.cert.pem in Chroms Behörden in chrome://settings/certificates, und:

openssl s_server -key test.key.pem -cert test.cert.pem -accept 20443 -www &
openssl_pid=$!
google-chrome https://localhost:20443

Und nach dem Testen

kill $openssl_pid

1
2017-08-28 14:32