So erstellen Sie ein selbstsigniertes Zertifikat mit OpenSSL

Vermisse ich etwas? Ist dies der richtige Weg, um ein selbstsigniertes Zertifikat zu erstellen?

Es ist einfach, ein selbstsigniertes Zertifikat zu erstellen. Verwenden Sie einfach den Befehl openssl req. Es kann schwierig sein, einen zu erstellen, der von der größten Auswahl an Clients wie Browsern und Befehlszeilentools verwendet werden kann.

Es ist schwierig, weil die Browser ihre eigenen Anforderungen haben und restriktiver sind als die IETF . Die von Browsern verwendeten Anforderungen sind in den CA/Browser Forums (siehe Referenzen unten) dokumentiert. Die Einschränkungen treten in zwei Schlüsselbereichen auf: (1) Vertrauensanker und (2) DNS-Namen.

Moderne Browser (wie die Warez, die wir 2014/2015 verwenden) möchten ein Zertifikat, das an einen Vertrauensanker gebunden ist, und sie möchten, dass DNS-Namen im Zertifikat auf bestimmte Weise dargestellt werden. Und Browser richten sich aktiv gegen selbstsignierte Serverzertifikate.

Einige Browser machen es nicht einfach, ein selbstsigniertes Serverzertifikat zu importieren. In der Tat können Sie nicht mit einigen Browsern, wie Android-Browser. Die komplette Lösung ist also, Ihre eigene Autorität zu werden.

Wenn Sie nicht zu Ihrer eigenen Autorität werden, müssen Sie die richtigen DNS-Namen ermitteln, um dem Zertifikat die größten Erfolgschancen zu geben. Aber ich möchte Sie ermutigen, Ihre eigene Autorität zu werden. Es ist einfach, Ihre eigene Autorität zu werden, und es umgeht alle Vertrauensprobleme (wem kann man besser vertrauen als Ihnen selbst?).

Dies ist wahrscheinlich nicht die Seite, die Sie suchen!
Die Sicherheitszertifikat der Website ist nicht vertrauenswürdig!

Dies liegt daran, dass Browser eine vordefinierte Liste von Vertrauensankern verwenden, um Serverzertifikate zu validieren. Ein selbstsigniertes Zertifikat wird nicht an einen vertrauenswürdigen Anker gekettet.

Der beste Weg, dies zu vermeiden, ist:

1. Erstelle deine eigene Autorität (d. H. Werde ein CA )
2. Erstellen Sie eine Zertifikatsignierungsanforderung (Certificate Signing Request, CSR) für den Server
3. Signieren Sie den CSR des Servers mit Ihrem CA-Schlüssel
4. Installieren Sie das Serverzertifikat auf dem Server
5. Installieren Sie das CA-Zertifikat auf dem Client

Schritt 1 - Eine eigene Autorität erstellen bedeutet nur, ein selbstsigniertes Zertifikat mit CA: true und der richtigen Schlüsselverwendung zu erstellen. Das bedeutet, dass der Subject und der Issuer dieselbe Entität sind, CA ist in Basic Constraints auf true gesetzt ( Es sollte auch als kritisch markiert sein. Die Schlüsselverwendung ist keyCertSign und crlSign (wenn Sie CRLs verwenden), und die Subject Key Identifier (SKI) ist Entspricht dem Authority Key Identifier (AKI).

Informationen dazu, wie Sie Ihre eigene Zertifizierungsstelle werden können, finden Sie unter * Wie signieren Sie eine Zertifikatsignierungsanforderung bei Ihrer Zertifizierungsstelle? bei Stack Overflow. Importieren Sie anschließend Ihre Zertifizierungsstelle in den vom Browser verwendeten Trust Store.

Die Schritte 2 - 4 entsprechen in etwa den Schritten, die Sie jetzt für einen öffentlich zugänglichen Server ausführen, wenn Sie die Dienste einer Zertifizierungsstelle wie Startcom oder CAcert in Anspruch nehmen. Mit den Schritten 1 und 5 können Sie die Autorität eines Drittanbieters umgehen und als Ihre eigene Autorität handeln (wem können Sie besser vertrauen als Ihnen selbst?).

Die nächstbeste Möglichkeit, die Browserwarnung zu umgehen, besteht darin, dem Serverzertifikat zu vertrauen. Einige Browser, wie der Standardbrowser von Android, lassen dies jedoch nicht zu. Es wird also niemals auf der Plattform funktionieren.

Das Problem, dass Browser (und ähnliche Benutzerprogramme) nicht selbstsignierten Zertifikaten vertrauen, wird im Internet der Dinge (Internet of Things, IoT) ein großes Problem darstellen. Was passiert zum Beispiel, wenn Sie eine Verbindung zu Ihrem Thermostat oder Kühlschrank herstellen, um ihn zu programmieren? Die Antwort ist, was das Benutzererlebnis betrifft, nichts Gutes.

Die WebAppSec-Arbeitsgruppe des W3C beginnt sich mit dem Problem zu befassen. Siehe zum Beispiel Vorschlag: HTTP als nicht sicher markieren .

So erstellen Sie ein selbstsigniertes Zertifikat mit OpenSSL

Mit den folgenden Befehlen und der Konfigurationsdatei wird ein selbstsigniertes Zertifikat erstellt (außerdem wird gezeigt, wie eine Signaturanforderung erstellt wird). Sie unterscheiden sich in einer Hinsicht von anderen Antworten: Die für das selbstsignierte Zertifikat verwendeten DNS-Namen stehen im Subject Alternate Name (SAN) und nicht im Common Name (CN) ) .

Die DNS-Namen werden in der Konfigurationsdatei in SAN mit der Zeile subjectAltName = @alternate_names abgelegt (dies kann nicht über die Befehlszeile erfolgen). Dann gibt es einen Abschnitt alternate_names in der Konfigurationsdatei (Sie sollten dies nach Ihrem Geschmack einstellen):

[ alternate_names ]

DNS.1       = example.com
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# DNS.7       = 127.0.0.1

# IPv6 localhost
# DNS.8     = ::1

Es ist wichtig, den DNS-Namen in SAN und nicht in den CN einzufügen, da sowohl die IETF als auch die CA/Browser-Foren die Vorgehensweise festlegen. Sie geben auch an, dass DNS-Namen im CN veraltet sind (aber nicht verboten sind). Wenn Sie einen DNS-Namen in den CN eingeben, muss dieser im SAN unter den CA/B-Richtlinien enthalten sein . Daher können Sie die Verwendung des alternativen Antragstellernamens nicht vermeiden.

Wenn Sie keine DNS-Namen in das SAN einfügen, kann das Zertifikat unter einem Browser und anderen Benutzeragenten, die den Richtlinien von CA/Browser Forum entsprechen, nicht validiert werden.

Verwandte Themen: Browser befolgen die Richtlinien von CA/Browser Forum. und nicht die IETF-Richtlinien. Dies ist einer der Gründe, warum ein mit OpenSSL erstelltes Zertifikat (das im Allgemeinen der IETF folgt) manchmal nicht unter einem Browser gültig ist (Browser folgen der CA/B). Es handelt sich um unterschiedliche Standards, sie haben unterschiedliche Ausstellungsrichtlinien und unterschiedliche Validierungsanforderungen.

Erstellen Sie ein selbstsigniertes Zertifikat (beachten Sie die Hinzufügung der Option -x509):

openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes \
    -keyout example-com.key.pem -days 365 -out example-com.cert.pem

Erstellen Sie eine Signaturanforderung (beachten Sie das Fehlen der Option -x509):

openssl req -config example-com.conf -new -sha256 -newkey rsa:2048 -nodes \
    -keyout example-com.key.pem -days 365 -out example-com.req.pem

Drucken Sie ein selbstsigniertes Zertifikat aus :

openssl x509 -in example-com.cert.pem -text -noout

Eine Signaturanforderung drucken :

openssl req -in example-com.req.pem -text -noout

Konfigurationsdatei (wird mit der Option -config übergeben)

[ req ]
default_bits        = 2048
default_keyfile     = server-key.pem
distinguished_name  = subject
req_extensions      = req_ext
x509_extensions     = x509_ext
string_mask         = utf8only

# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
#   Its sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
countryName         = Country Name (2 letter code)
countryName_default     = US

stateOrProvinceName     = State or Province Name (full name)
stateOrProvinceName_default = NY

localityName            = Locality Name (eg, city)
localityName_default        = New York

organizationName         = Organization Name (eg, company)
organizationName_default    = Example, LLC

# Use a friendly name here because it's presented to the user. The server's DNS
#   names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
#   by both IETF and CA/Browser Forums. If you place a DNS name here, then you
#   must include the DNS name in the SAN too (otherwise, Chrome and others that
#   strictly follow the CA/Browser Baseline Requirements will fail).
commonName          = Common Name (e.g. server FQDN or YOUR name)
commonName_default      = Example Company

emailAddress            = Email Address
emailAddress_default        = [email protected]

# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]

subjectKeyIdentifier        = hash
authorityKeyIdentifier    = keyid,issuer

# You only need digitalSignature below. *If* you don't allow
#   RSA Key transport (i.e., you use ephemeral cipher suites), then
#   omit keyEncipherment because that's key transport.
basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage    = serverAuth, clientAuth

# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]

subjectKeyIdentifier        = hash

basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage    = serverAuth, clientAuth

[ alternate_names ]

DNS.1       = example.com
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# DNS.7       = 127.0.0.1

# IPv6 localhost
# DNS.8     = ::1

Möglicherweise müssen Sie für Chrome die folgenden Schritte ausführen. Andernfalls Chrome kann sich beschweren, dass ein Common Name ungültig ist (ERR_CERT_COMMON_NAME_INVALID) . Ich bin nicht sicher, wie die Beziehung zwischen einer IP-Adresse im SAN und einem CN in diesem Fall ist.

# IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

Für den Umgang mit DNS-Namen in X.509/PKIX-Zertifikaten gelten andere Regeln. In diesen Dokumenten finden Sie die Regeln:

• RFC 5280, Internet X.509-Infrastrukturzertifikat mit öffentlichem Schlüssel und Zertifikatssperrlistenprofil (Certificate Revocation List, CRL)
• RFC 6125, Darstellung und Überprüfung der domänenbasierten Identität von Anwendungsdiensten in der Infrastruktur für öffentliche Internetschlüssel mithilfe von X.509 (PKIX) -Zertifikaten im Kontext der Transportschichtsicherheit (TLS)
• RFC 6797, Anhang A, HTTP Strict Transport Security (HSTS)
• RFC 7469, Public Key Pinning Extension für HTTP
• CA/Browser Forum Grundanforderungen
• CA/Browser Forum Erweiterte Validierungsrichtlinien

RFC 6797 und RFC 7469 werden aufgelistet, da sie restriktiver sind als die anderen RFCs und CA/B-Dokumente. RFCs 6797 und 7469 erlauben ebenfalls keine IP-Adresse .

Hier sind die Optionen beschrieben in @ diegows Antwort , genauer beschrieben in die Dokumentation :

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX

req

PKCS # 10 Zertifikatanforderung und Dienstprogramm zur Zertifikatgenerierung.

-x509

diese Option gibt ein selbstsigniertes Zertifikat anstelle einer Zertifikatanforderung aus. Dies wird normalerweise zum Generieren eines Testzertifikats oder einer selbst signierten Stammzertifizierungsstelle verwendet.

-newkey arg

diese Option erstellt eine neue Zertifikatsanforderung und einen neuen privaten Schlüssel. Das Argument hat eine von mehreren Formen. rsa: nbits , wobei nbits die Anzahl der Bits ist, erzeugt ein Größe des RSA-Schlüssels nbit .

-keyout filename

dies gibt den Dateinamen an, in den der neu erstellte private Schlüssel geschrieben werden soll.

-out filename

Dies gibt den Ausgabedateinamen an, in den standardmäßig geschrieben werden soll, oder die Standardausgabe.

-days n

wenn die Option - x509 verwendet wird, gibt dies die Anzahl der Tage an, für die das Zertifikat zertifiziert werden soll. Der Standardwert beträgt 30 Tage.

-nodes

wenn diese Option angegeben ist, wird ein privater Schlüssel, der erstellt wird, nicht verschlüsselt.

Die Dokumentation ist detaillierter als die oben genannten; Ich habe es hier nur zusammengefasst.

Ab 2019 erfüllt der folgende Befehl alle Ihre Anforderungen, einschließlich SAN:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
  -keyout example.key -out example.crt -extensions san -config \
  <(echo "[req]"; 
    echo distinguished_name=req; 
    echo "[san]"; 
    echo subjectAltName=DNS:example.com,DNS:example.net,IP:10.0.0.1
    ) \
  -subj /CN=example.com

In OpenSSL ≥ 1.1.1 kann dies verkürzt werden auf:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
  -keyout example.key -out example.crt -subj /CN=example.com \
  -addext subjectAltName=DNS:example.com,DNS:example.net,IP:10.0.0.1

Es wird also ein Zertifikat erstellt

• gültig für die Domains example.com und example.net (SAN),
• gilt auch für die IP-Adresse 10.0.0.1 (SAN),
• relativ stark (Stand 2019) und
• gültig für 3650 Tage (~ 10 Jahre).

Es werden folgende Dateien erstellt:

• Privater Schlüssel: example.key
• Zertifikat: example.crt

Alle Informationen werden in der Befehlszeile bereitgestellt. Es gibt keine nervigen interaktiven Eingaben. Es wird nicht mit Konfigurationsdateien herumgespielt. Alle erforderlichen Schritte werden durch diesen einzelnen OpenSSL-Aufruf ausgeführt: von der Generierung des privaten Schlüssels bis zum selbstsignierten Zertifikat.

Anmerkung 1: Kryptoparameter

Da das Zertifikat selbstsigniert ist und von den Benutzern manuell akzeptiert werden muss, ist es nicht sinnvoll, einen kurzen Ablauf oder eine schwache Kryptografie zu verwenden.

In Zukunft möchten Sie möglicherweise mehr als 4096 Bits für den RSA-Schlüssel und einen Hash-Algorithmus verwenden, der stärker als sha256 ist. Ab 2019 sind dies jedoch vernünftige Werte. Sie sind ausreichend stark und werden von allen modernen Browsern unterstützt.

Bemerkung 2: Parameter "-nodes"

Theoretisch könnten Sie den Parameter -nodes weglassen (was "keine DES Verschlüsselung" bedeutet). In diesem Fall würde example.key mit einem Passwort verschlüsselt. Dies ist jedoch für eine Serverinstallation so gut wie nie sinnvoll, da Sie entweder das Kennwort auch auf dem Server speichern müssen oder es bei jedem Neustart manuell eingeben müssen.

Bemerkung 3: MinGW

Unter Windows in der MinGW-Bash sollten Sie dem Befehl MSYS_NO_PATHCONV=1 voranstellen:

MSYS_NO_PATHCONV=1 openssl ...

Alternativ können Sie den Befehl in der einfachen Windows-Eingabeaufforderung cmd.exe ausführen.

Anmerkung 4: Siehe auch

• Geben Sie subjectAltName für openssl direkt in der Befehlszeile an
• Wie füge ich einem SSL-Zertifikat mehrere E-Mail-Adressen über die Befehlszeile hinzu?
• Weitere Informationen zu MSYS_NO_PATHCONV

Ich kann keinen Kommentar abgeben, daher werde ich dies als separate Antwort angeben. Ich habe ein paar Probleme mit der akzeptierten Einzeiler-Antwort gefunden:

• Der Einzeiler enthält eine Passphrase im Schlüssel.
• Der Einzeiler verwendet SHA-1, das in vielen Browsern Warnungen in der Konsole ausgibt.

Hier ist eine vereinfachte Version, die die Passphrase entfernt, die Sicherheit erhöht, um Warnungen zu unterdrücken, und einen Vorschlag in Kommentare einschließt, um -subj zu übergeben, um die vollständige Fragenliste zu entfernen:

openssl genrsa -out server.key 2048
openssl rsa -in server.key -out server.key
openssl req -sha256 -new -key server.key -out server.csr -subj '/CN=localhost'
openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt

Ersetzen Sie 'localhost' durch die Domain, die Sie benötigen. Sie müssen die ersten beiden Befehle nacheinander ausführen, da OpenSSL zur Eingabe einer Passphrase auffordert.

So kombinieren Sie die beiden in eine PEM-Datei:

cat server.crt server.key > cert.pem

Moderne Browser werfen jetzt einen Sicherheitsfehler für ansonsten wohlgeformte selbstsignierte Zertifikate, wenn ihnen ein SAN (alternativer Antragstellername) fehlt. OpenSSL bietet keine Befehlszeile, um dieses anzugeben, so viele Tutorials und Lesezeichen von Entwicklern sind plötzlich veraltet.

Der schnellste Weg, um wieder zum Laufen zu kommen, ist eine kurze, eigenständige Konfigurationsdatei:

1. Erstellen Sie eine OpenSSL-Konfigurationsdatei (Beispiel: req.cnf)

   [req]
   distinguished_name = req_distinguished_name
   x509_extensions = v3_req
   Prompt = no
   [req_distinguished_name]
   C = US
   ST = VA
   L = SomeCity
   O = MyCompany
   OU = MyDivision
   CN = www.company.com
   [v3_req]
   keyUsage = critical, digitalSignature, keyAgreement
   extendedKeyUsage = serverAuth
   subjectAltName = @alt_names
   [alt_names]
   DNS.1 = www.company.com
   DNS.2 = company.com
   DNS.3 = company.net
   

2. Erstellen Sie das Zertifikat, das auf diese Konfigurationsdatei verweist

   openssl req -x509 -nodes -days 730 -newkey rsa:2048 \
    -keyout cert.key -out cert.pem -config req.cnf -sha256
   

Beispielkonfiguration von https://support.citrix.com/article/CTX135602

Ich würde empfehlen, den Parameter - sha256 hinzuzufügen, um den SHA-2-Hash-Algorithmus zu verwenden, da große Browser die Anzeige von "SHA-1-Zertifikaten" in Betracht ziehen. als nicht sicher.

Dieselbe Befehlszeile aus der akzeptierten Antwort - @diegows mit dem Zusatz -sha256

openssl req -x509 - sha256 -newkey rsa: 2048 -keyout key.pem -out cert.pem -days XXX

Weitere Informationen finden Sie in Google Security-Blog .

Update Mai 2018. Wie in den Kommentaren erwähnt, bietet die Verwendung von SHA-2 keine zusätzliche Sicherheit für ein selbstsigniertes Zertifikat. Ich empfehle es dennoch als gute Angewohnheit, keine veralteten/unsicheren kryptografischen Hash-Funktionen zu verwenden. Eine vollständige Erklärung finden Sie in Warum ist es in Ordnung, wenn Zertifikate über dem End-Entity-Zertifikat auf SHA-1 basieren?.

Dies ist das Skript, das ich für lokale Boxen verwende, um SAN (subjectAltName) in selbstsignierten Zertifikaten festzulegen.

Dieses Skript verwendet den Domänennamen (example.com) und generiert das SAN für * .example.com und example.com im selben Zertifikat. Die folgenden Abschnitte sind kommentiert. Nennen Sie das Skript (z. B. generate-ssl.sh) und geben Sie ihm ausführbare Berechtigungen. Die Dateien werden in dasselbe Verzeichnis wie das Skript geschrieben.

Für Chrome 58 und höher muss SAN in selbstsignierten Zertifikaten festgelegt sein.

#!/usr/bin/env bash

# Set the TLD domain we want to use
BASE_DOMAIN="example.com"

# Days for the cert to live
DAYS=1095

# A blank passphrase
PASSPHRASE=""

# Generated configuration file
CONFIG_FILE="config.txt"

cat > $CONFIG_FILE <<-EOF
[req]
default_bits = 2048
Prompt = no
default_md = sha256
x509_extensions = v3_req
distinguished_name = dn

[dn]
C = CA
ST = BC
L = Vancouver
O = Example Corp
OU = Testing Domain
emailAddress = [email protected]$BASE_DOMAIN
CN = $BASE_DOMAIN

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = *.$BASE_DOMAIN
DNS.2 = $BASE_DOMAIN
EOF

# The file name can be anything
FILE_NAME="$BASE_DOMAIN"

# Remove previous keys
echo "Removing existing certs like $FILE_NAME.*"
chmod 770 $FILE_NAME.*
rm $FILE_NAME.*

echo "Generating certs for $BASE_DOMAIN"

# Generate our Private Key, CSR and Certificate
# Use SHA-2 as SHA-1 is unsupported from Jan 1, 2017

openssl req -new -x509 -newkey rsa:2048 -sha256 -nodes -keyout "$FILE_NAME.key" -days $DAYS -out "$FILE_NAME.crt" -passin pass:$PASSPHRASE -config "$CONFIG_FILE"

# OPTIONAL - write an info to see the details of the generated crt
openssl x509 -noout -fingerprint -text < "$FILE_NAME.crt" > "$FILE_NAME.info"

# Protect the key
chmod 400 "$FILE_NAME.key"

Dieses Skript schreibt auch eine Informationsdatei, sodass Sie das neue Zertifikat überprüfen und sicherstellen können, dass SAN richtig eingestellt ist.

                ...
                28:dd:b8:1e:34:b5:b1:44:1a:60:6d:e3:3c:5a:c4:
                da:3d
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Subject Alternative Name: 
            DNS:*.example.com, DNS:example.com
Signature Algorithm: sha256WithRSAEncryption
     3b:35:5a:d6:9e:92:4f:fc:f4:f4:87:78:cd:c7:8d:cd:8c:cc:
     ...

Wenn Sie Apache verwenden, können Sie das obige Zertifikat in Ihrer Konfigurationsdatei folgendermaßen referenzieren:

<VirtualHost _default_:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/htdocs

    SSLEngine on
    SSLCertificateFile path/to/your/example.com.crt
    SSLCertificateKeyFile path/to/your/example.com.key
</VirtualHost>

Denken Sie daran, den Apache- (oder Nginx- oder IIS-) Server neu zu starten, damit das neue Zertifikat wirksam wird.

2017 Einzeiler:

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

Dies funktioniert auch in Chrome 57, da das SAN bereitgestellt wird, ohne dass eine andere Konfigurationsdatei vorhanden ist. Es wurde einer Antwort entnommen hier .

Dadurch wird eine einzelne PEM-Datei erstellt, die sowohl den privaten Schlüssel als auch das Zertifikat enthält. Sie können sie bei Bedarf in separate PEM-Dateien verschieben.

Einzeiler FTW. Ich halte es gerne einfach. Warum nicht einen Befehl verwenden, der ALLE erforderlichen Argumente enthält? So gefällt es mir - so wird ein x509-Zertifikat und sein PEM-Schlüssel erstellt:

openssl req -x509 \
 -nodes -days 365 -newkey rsa:4096 \
 -keyout self.key.pem \
 -out self-x509.crt \
 -subj "/C=US/ST=WA/L=Seattle/CN=example.com/[email protected]"

Dieser einzelne Befehl enthält alle Antworten, die Sie normalerweise für die Zertifikatdetails bereitstellen würden. Auf diese Weise können Sie die Parameter einstellen und den Befehl ausführen, Ihre Ausgabe abrufen und dann Kaffee trinken.

>> Mehr hier <<

Sie haben die allgemeine Vorgehensweise richtig. Die Syntax für den Befehl ist unten.

openssl req -new -key {private key file} -out {output file}

Die Warnungen werden jedoch angezeigt, da der Browser die Identifizierung durch Validieren des Zertifikats bei einer bekannten Zertifizierungsstelle (CA) nicht überprüfen konnte.

Da es sich um ein selbstsigniertes Zertifikat handelt, gibt es keine Zertifizierungsstelle. Sie können die Warnung ignorieren und fortfahren. Wenn Sie ein echtes Zertifikat erhalten möchten, das von jedem im öffentlichen Internet erkannt werden kann, gehen Sie wie folgt vor.

1. Generieren Sie einen privaten Schlüssel
2. Verwenden Sie diesen privaten Schlüssel, um eine CSR-Datei zu erstellen
3. CSR an CA senden (Verisign oder andere usw.)
4. Installieren Sie das von der Zertifizierungsstelle empfangene Zertifikat auf dem Webserver
5. Fügen Sie der Authentifizierungskette je nach Typ des Zertifikats weitere Zertifikate hinzu

Ich habe weitere Details dazu in einem Beitrag unter Sichern der Verbindung: Erstellen eines Sicherheitszertifikats mit OpenSSL

Einzeiler-Version 2017:

CentOS:

openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/pki/tls/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))

buntu:

openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))

Schlüssel generieren

Ich verwende /etc/mysql für die Zertifikatsspeicherung, da /etc/apparmor.d/usr.sbin.mysqld/etc/mysql/*.pem r enthält.

Sudo su -
cd /etc/mysql
openssl genrsa -out ca-key.pem 2048;
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem -out ca-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem -out server-req.pem;
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem -out client-req.pem;
openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem;

Konfiguration hinzufügen

/etc/mysql/my.cnf

[client]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/client-cert.pem
ssl-key=/etc/mysql/client-key.pem

[mysqld]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/server-cert.pem
ssl-key=/etc/mysql/server-key.pem

Auf meinem Setup hat sich der Ubuntu-Server angemeldet bei: /var/log/mysql/error.log

Follow-up Notizen:

• SSL error: Unable to get certificate from '...'

  MySQL wird möglicherweise der Lesezugriff auf Ihre Zertifikatsdatei verweigert, wenn diese nicht in der Apparmors-Konfiguration enthalten ist. . Speichern Sie, wie in den vorherigen Schritten ^ erwähnt, alle unsere Zertifikate als .pem -Dateien im Verzeichnis /etc/mysql/, das standardmäßig von Apparmor genehmigt wird (oder ändern Sie Apparmor/SELinux, um den Zugriff auf die von Ihnen gespeicherten Zertifikate zu ermöglichen. )

• SSL error: Unable to get private key

  Ihre MySQL-Serverversion unterstützt möglicherweise nicht das Standardformat rsa:2048

  Generierten rsa:2048 in einfachen rsa konvertieren mit:

  openssl rsa -in server-key.pem -out server-key.pem
  openssl rsa -in client-key.pem -out client-key.pem
  

• Überprüfen Sie, ob der lokale Server SSL unterstützt :

  mysql -u root -p
  mysql> show variables like "%ssl%";
  +---------------+----------------------------+
  | Variable_name | Value                      |
  +---------------+----------------------------+
  | have_openssl  | YES                        |
  | have_ssl      | YES                        |
  | ssl_ca        | /etc/mysql/ca-cert.pem     |
  | ssl_capath    |                            |
  | ssl_cert      | /etc/mysql/server-cert.pem |
  | ssl_cipher    |                            |
  | ssl_key       | /etc/mysql/server-key.pem  |
  +---------------+----------------------------+
  

• Überprüfen, ob eine Verbindung zur Datenbank SSL-verschlüsselt ist :

  Verbindung wird überprüft

  Wenn Sie bei der MySQL-Instanz angemeldet sind, können Sie die folgende Abfrage ausführen:

  show status like 'Ssl_cipher';
  

  Wenn Ihre Verbindung nicht verschlüsselt ist, ist das Ergebnis leer:

  mysql> show status like 'Ssl_cipher';
  +---------------+-------+
  | Variable_name | Value |
  +---------------+-------+
  | Ssl_cipher    |       |
  +---------------+-------+
  1 row in set (0.00 sec)
  

  Andernfalls würde eine Zeichenfolge ungleich Null für die verwendete Verschlüsselung angezeigt:

  mysql> show status like 'Ssl_cipher';
  +---------------+--------------------+
  | Variable_name | Value              |
  +---------------+--------------------+
  | Ssl_cipher    | DHE-RSA-AES256-SHA |
  +---------------+--------------------+
  1 row in set (0.00 sec)
  

• SSL für die Verbindung eines bestimmten Benutzers erforderlich ('SSL erforderlich'):

  • SSL

  Weist den Server an, nur SSL-verschlüsselte Verbindungen für das Konto zuzulassen.

  GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost'
    REQUIRE SSL;
  

  Um eine Verbindung herzustellen, muss der Client die Option --ssl-ca angeben, um das Serverzertifikat zu authentifizieren, und er kann zusätzlich die Optionen --ssl-key und --ssl-cert angeben. Wenn weder die Option --ssl-ca noch die Option --ssl-capath angegeben ist, authentifiziert der Client das Serverzertifikat nicht.

Alternativer Link: Langes Tutorial in Sichere PHP Verbindungen zu MySQL mit SSL.

Wie bereits ausführlich erläutert, gilt selbstsignierte Zertifikatefür das Internet nicht vertrauenswürdig . Sie können fügen Sie Ihr selbstsigniertes Zertifikat vielen, aber nicht allen Browsern hinz . Alternativ können Sie Ihre eigene Zertifizierungsstelle werden .

Der Hauptgrund, warum man kein signiertes Zertifikat von einer Zertifizierungsstelle erhalten möchte, sind die Kosten - Symantec berechnet für Zertifikate zwischen 995 USD und 1.999 USD pro Jahr - nur für ein für das interne Netzwerk bestimmtes Zertifikat berechnet Symantec 399 USD pro Jahr . Diese Kosten sind leicht zu rechtfertigen, wenn Sie Kreditkartenzahlungen abwickeln oder für das Profitcenter eines hochprofitablen Unternehmens arbeiten. Es ist mehr, als sich viele für ein persönliches Projekt leisten können, das man im Internet erstellt, oder für ein gemeinnütziges Unternehmen, das mit einem minimalen Budget arbeitet, oder wenn man auf einer Kostenstelle einer Organisation arbeitet - Kostenstellen versuchen immer, mehr zu tun mit weniger.

Eine Alternative ist certbot (siehe über certbot ). Certbot ist ein benutzerfreundlicher automatischer Client, der SSL/TLS-Zertifikate für Ihren Webserver abruft und bereitstellt.

Wenn Sie certbot einrichten, können Sie es aktivieren, um ein Zertifikat zu erstellen und zu verwalten, das von der Zertifizierungsstelle Let’s Encrypt ausgestellt wurde.

Ich habe das über das Wochenende für meine Organisation gemacht. Ich habe die erforderlichen Pakete für certbot auf meinem Server (Ubuntu 16.04) installiert und dann den Befehl ausgeführt, der zum Einrichten und Aktivieren von certbot erforderlich ist. Man benötigt wahrscheinlich ein DNS-Plugin für Certbot - wir verwenden derzeit DigitalOcean , werden aber möglicherweise bald auf einen anderen Dienst migrieren.

Beachten Sie, dass einige der Anweisungen nicht ganz richtig waren und ein wenig Stöbern und Zeit bei Google in Anspruch nahmen, um dies herauszufinden. Das hat beim ersten Mal ziemlich viel Zeit gekostet, aber jetzt glaube ich, dass ich es in Minuten schaffen kann.

Bei DigitalOcean hatte ich Probleme, als ich aufgefordert wurde, den Pfad zu Ihrer DigitalOcean-Anmeldeinformationsdatei INI einzugeben. Das Skript bezieht sich auf die Seite Applications & API und die Registerkarte Tokens/Key auf dieser Seite. Sie müssen ein persönliches Zugriffstoken (Lesen und Schreiben) für die DigitalOcean-API haben oder generieren - dies ist eine 65-stellige hexadezimale Zeichenfolge. Diese Zeichenfolge muss dann in eine Datei auf dem Webserver gestellt werden, auf dem Sie certbot ausführen. Diese Datei kann in der ersten Zeile einen Kommentar enthalten (Kommentare beginnen mit #). Die zweite Zeile lautet:

dns_digitalocean_token = 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff

Nachdem ich herausgefunden hatte, wie ein Lese- und Schreib-Token für die DigitalOcean-API eingerichtet werden kann, war es ziemlich einfach, mit certbot ein Platzhalterzertifikat einzurichten. Beachten Sie, dass Sie kein Platzhalterzertifikat einrichten müssen, sondern stattdessen jede Domäne und Unterdomäne angeben können, auf die das Zertifikat angewendet werden soll. Es war das Platzhalterzertifikat, für das die Datei mit den Anmeldeinformationen INI erforderlich war, die das persönliche Zugriffstoken von DigitalOcean enthielt.

Beachten Sie, dass Zertifikate mit öffentlichem Schlüssel (auch als Identitätszertifikate oder SSL-Zertifikate bezeichnet) ablaufen und erneuert werden müssen. Daher müssen Sie Ihr Zertifikat regelmäßig (wiederholt) erneuern. Die certbot-Dokumentation behandelt erneuernde Zertifikate .

Mein Plan ist es, ein Skript zu schreiben, das den Befehl openssl verwendet, um das Ablaufdatum meines Zertifikats abzurufen und die Verlängerung auszulösen, wenn es 30 Tage oder weniger bis zum Ablaufdatum ist. Ich werde dieses Skript dann zu cron hinzufügen und es einmal pro Tag ausführen.

Hier ist der Befehl zum Lesen des Ablaufdatums Ihres Zertifikats:

[email protected]:~# /usr/bin/openssl x509 -enddate -noout -in path-to-certificate-pem-file
notAfter=May 25 19:24:12 2019 GMT

Selbstsignierte Zertifikats- und Zertifikatskettenerstellungsskripte für RSA und ECDSA unter Verwendung von OpenSSL sind hier verfügbar.