Frage Wie erstelle ich ein selbstsigniertes Zertifikat mit openssl?


Ich füge https-Unterstützung zu einem eingebetteten Linux-Gerät hinzu. Ich habe versucht, ein selbstsigniertes Zertifikat mit diesen Schritten zu generieren:

openssl req -new > cert.csr
openssl rsa -in privkey.pem -out key.pem
openssl x509 -in cert.csr -out cert.pem -req -signkey key.pem -days 1001
cat key.pem>>cert.pem

Das funktioniert, aber ich bekomme einige Fehler, zum Beispiel bei Google Chrome:

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

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


854
2018-04-16 14:14


Ursprung


Antworten:


Sie können das in einem Befehl tun:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

Sie können auch hinzufügen -nodes Wenn Sie Ihren privaten Schlüssel nicht mit einer Passphrase schützen möchten, werden Sie andernfalls zur Eingabe eines Kennworts von mindestens 4 Zeichen aufgefordert. Der Parameter days (365) kann durch eine beliebige Zahl ersetzt werden, um das Ablaufdatum zu beeinflussen. Sie werden dann aufgefordert, nach "Country Name" zu suchen, aber Sie können einfach Enter drücken und die Standardeinstellungen übernehmen.

Hinzufügen -subj '/CN=localhost' Fragen zum Inhalt des Zertifikats unterdrücken (ersetzen localhost mit deiner gewünschten Domain)

Selbstsignierte Zertifikate werden nicht mit Dritten validiert, es sei denn, Sie importieren sie zuvor in den Browser. Wenn Sie mehr Sicherheit benötigen, sollten Sie ein Zertifikat verwenden, das von einer Zertifizierungsstelle signiert wurde.


1485
2018-04-16 15:04



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

Es ist einfach, ein selbstsigniertes Zertifikat zu erstellen. Du benutzt einfach die openssl req Befehl. Es kann schwierig sein, einen zu erstellen, der von der größten Auswahl an Clients wie Browsern und Befehlszeilentools konsumiert werden kann.

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

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

Einige Browser erleichtern den Import eines selbstsignierten Serverzertifikats nicht gerade. In der Tat können Sie nicht mit einigen Browsern, wie Android-Browser. Die komplette Lösung soll also Ihre eigene Autorität werden.

In Ermangelung Ihrer eigenen Autorität, müssen Sie die DNS-Namen richtig machen, um dem Zertifikat die größte Chance auf Erfolg zu geben. Aber ich würde Sie ermutigen, Ihre eigene Autorität zu werden. Es ist leicht, Ihre eigene Autorität zu werden, und es wird Seite alle Vertrauensfragen Schritt (wer besser als Sie selbst vertrauen?).


Dies ist wahrscheinlich nicht die Website, 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 überprüfen. Ein selbstsigniertes Zertifikat ist nicht mit einem vertrauenswürdigen Anker verknüpft.

Der beste Weg, dies zu vermeiden, ist:

  1. Erstellen Sie Ihre eigene Autorität (d. H. Werden Sie eine CA)
  2. Erstellen Sie eine Zertifikatsignierungsanforderung (CSR) für den Server
  3. Unterschreiben Sie die 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 - Erschaffe deine eigene Autorität bedeutet nur, ein selbstsigniertes Zertifikat mit zu erstellen CA: true und richtige Schlüsselverwendung. Das bedeutet, dass Subject und Issuer dieselbe Entität sind. CA wird in Basic Constraints auf "True" gesetzt (es sollte auch als "Critical" markiert werden). Die Schlüsselverwendung ist keyCertSign und crlSign (wenn Sie CRLs verwenden), und der Subject Key Identifier (SKI) ist derselbe wie der Authority Key Identifier (AKI).

Um Ihre eigene Zertifizierungsstelle zu werden, siehe Wie unterschreiben Sie eine Zertifikatsignierungsanfrage mit Ihrer Zertifizierungsstelle? auf Stapelüberlauf. Importieren Sie Ihre Zertifizierungsstelle dann in den Trust Store, den der Browser verwendet.

Die Schritte 2 bis 4 sind ungefähr die Schritte, die Sie jetzt für einen öffentlichen Server ausführen, wenn Sie die Dienste einer Zertifizierungsstelle in Anspruch nehmen Startcom oder CAcert. Die Schritte 1 und 5 ermöglichen es Ihnen, die Autorität der dritten Partei zu vermeiden und als Ihre eigene Autorität zu agieren (wem sollten Sie besser vertrauen als Sie selbst?).

Der nächste beste Weg, die Warnung des Browsers zu vermeiden, besteht darin, dem Zertifikat des Servers zu vertrauen. Aber einige Browser, wie der Standardbrowser von Android, lassen es nicht zu. Es wird also nie auf der Plattform funktionieren.

Das Problem der Browser (und anderer ähnlicher Benutzeragenten) nicht Vertrauen in selbstsignierte Zertifikate wird ein großes Problem im Internet der Dinge (IoT) sein. Zum Beispiel, was passiert, wenn Sie eine Verbindung zu Ihrem Thermostat oder Kühlschrank herstellen, um es zu programmieren? Die Antwort ist, nichts Gutes, was die Benutzererfahrung angeht.

Die WebAppSec-Arbeitsgruppe des W3C befasst sich nun mit dem Problem. Siehe zum Beispiel Vorschlag: Markieren von HTTP als nicht sicher.


Wie erstelle ich ein selbstsigniertes Zertifikat mit openssl?

Die folgenden Befehle und die Konfigurationsdatei erstellen ein selbstsigniertes Zertifikat (es zeigt Ihnen auch, wie Sie eine Signaturanforderung erstellen). Sie unterscheiden sich von anderen Antworten in einer Hinsicht: Die für das selbstsignierte Zertifikat verwendeten DNS-Namen sind in der Betreff Alternativer Name (SAN)und nicht die Allgemeiner Name (CN).

Die DNS-Namen werden über die Konfigurationsdatei mit der Zeile im SAN gespeichert subjectAltName = @alternate_names (Es gibt keine Möglichkeit, dies über die Befehlszeile zu tun). Dann gibt es ein alternate_names Abschnitt in der Konfigurationsdatei (Sie sollten dies nach Ihrem Geschmack tunen):

[ 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 das SAN und nicht die CN zu setzen beide die IETF und die CA / Browser Foren spezifizieren die Praxis. Sie geben außerdem an, dass DNS-Namen im CN veraltet (aber nicht verboten) sind. Ob Sie legen einen DNS-Namen in das CN, dann es Muss unter den CA / B-Richtlinien in das SAN aufgenommen werden. Sie können also nicht vermeiden, den Subject Alternate Name zu verwenden.

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

Verwandt: Browser folgen den Richtlinien des CA / Browser Forums; und nicht die IETF-Richtlinien. Das ist einer der Gründe, warum ein Zertifikat, das mit OpenSSL erstellt wurde (welches im Allgemeinen der IETF folgt), nicht unter einem Browser validiert wird (Browser folgen der CA / B). Sie sind unterschiedliche Standards, sie haben unterschiedliche Ausstellungsrichtlinien und unterschiedliche Validierungsanforderungen.


Erstellen Sie ein selbstsigniertes Zertifikat (Beachten Sie den Zusatz von -x509 Möglichkeit):

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 (beachte das Fehlen von -x509 Möglichkeit):

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:

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

Drucken Sie eine Signieranfrage:

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

Konfigurationsdatei (übergeben über -config Möglichkeit)

[ 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 its 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        = test@example.com

# 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

Unter Umständen müssen Sie für Chrome Folgendes tun. Andernfalls Chrome könnte sich beschweren Gemeinsamen Namen ist ungültig (ERR_CERT_COMMON_NAME_INVALID). Ich bin nicht sicher, wie die Beziehung zwischen einer IP-Adresse in dem SAN und einem CN in diesem Fall ist.

# IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

Für die Behandlung von DNS-Namen in X.509 / PKIX-Zertifikaten gelten weitere Regeln. In diesen Dokumenten finden Sie die Regeln:

RFC 6797 und RFC 7469 werden aufgelistet, da sie restriktiver sind als die anderen RFCs und CA / B-Dokumente. RFCs 6797 und 7469 unterlassen Sie Erlaube auch eine IP-Adresse.


390
2018-01-13 21:12



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

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

PKCS # 10-Zertifikatanforderung und Dienstprogramm zur Erstellung von Zertifikaten.

-x509

Diese Option gibt ein selbstsigniertes Zertifikat anstelle einer Zertifikatsanforderung aus.   Dies wird normalerweise verwendet, um ein Testzertifikat oder eine selbstsignierte Stammzertifizierungsstelle zu generieren.

-newkey arg

Diese Option erstellt eine neue Zertifikatanforderung und einen neuen privaten Schlüssel. Das Argument   nimmt eine von mehreren Formen an. rsa: nbits, woher nbits ist die Anzahl der Bits,   generiert einen RSA-Schlüssel nbits in Größe.

-keyout filename

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

-out filename

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

-days n

wenn das -x509 Die Option wird verwendet, um die Anzahl der zu zertifizierenden Tage anzugeben   das Zertifikat für. Der Standardwert ist 30 Tage.

-nodes

Wenn diese Option angegeben wird, wird ein privater Schlüssel nicht erstellt, wenn er erstellt wird.

Die Dokumentation ist tatsächlich detaillierter als die oben genannten, ich habe es hier nur zusammengefasst.


353
2018-04-13 01:48



Ich kann nichts sagen, also werde ich das als separate Antwort aufführen. Ich habe ein paar Probleme mit der akzeptierten One-Liner-Antwort gefunden:

  • Der Einzeiler enthält eine Passphrase im Schlüssel.
  • Der One-Liner verwendet SHA1, 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 Kommentaren enthält, um -subj weiterzugeben, 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' mit der gewünschten Domain. Sie müssen die ersten beiden Befehle nacheinander ausführen, da openssl nach einer Passphrase fragt.

So kombinieren Sie die beiden zu einer PEM-Datei:

cat server.crt server.key > cert.pem

106
2017-08-13 09:44



Der folgende Befehl:

openssl req -x509 -newkey rsa:4096 -sha256 -nodes -keyout example.key -out example.crt -subj "/CN=example.com" -days 3650

Erstellt ein Zertifikat für die Domäne example.com das ist

  • relativ stark (ab 2018) und
  • Gültig für 3650 Tage (~ 10 Jahre).

Es erstellt die folgenden Dateien:

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

Da alle Informationen über die Befehlszeile bereitgestellt werden, gibt es keine störenden interaktiven Eingaben. Außerdem werden alle notwendigen Schritte durch diesen einzelnen OpenSSL-Aufruf ausgeführt: von der privaten Schlüsselgenerierung bis zum selbstsignierten Zertifikat.

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

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

Randnotiz: Theoretisch könnte man das weglassen -nodes Parameter (was bedeutet "keine DES-Verschlüsselung"), in welchem ​​Fall example.key würde mit einem Passwort verschlüsselt werden. Dies ist jedoch für eine Serverinstallation fast nie sinnvoll, da Sie das Kennwort entweder auf dem Server speichern oder bei jedem Neustart manuell eingeben müssen.


105
2017-12-28 17:30



Ich würde empfehlen, hinzuzufügen -sha256 Parameter, um den SHA-2-Hash-Algorithmus zu verwenden, da die großen Browser "SHA-1-Zertifikate" als nicht sicher betrachten.

Die gleiche Befehlszeile von der angenommenen Antwort - @diegows mit -sha256 hinzugefügt

openssl req -x509 -sha256 -newkey rsa: 2048 -schlüsselschlüssel.pem -out cert.pem -days XXX

Mehr Infos in Google-Sicherheitsblog.

Aktualisierung Mai 2018. Wie viele in den Kommentaren angemerkt haben, fügt die Verwendung von SHA-2 dem selbstsignierten Zertifikat keine Sicherheit hinzu. Aber ich empfehle immer noch, es als gute Angewohnheit zu verwenden, keine veralteten / unsicheren kryptographischen Hash-Funktionen zu verwenden. Ausführliche Erklärung ist verfügbar in: https://security.stackexchange.com/questions/91913/why-is-it-fine-for-certificates-above-the-end-entity-certificate-to-be-sha1-base


63
2017-10-20 09:52



Moderne Browser werfen jetzt einen Sicherheitsfehler für ansonsten wohlgeformte selbstsignierte Zertifikate ab, wenn ihnen ein SAN (Subject Alternate Name) fehlt. OpenSSL bietet keine Befehlszeilenmöglichkeit, um dies zu spezifizieren, so viele Tutorials und Bookmarks von Entwicklern sind plötzlich veraltet.

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

  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


53
2018-05-09 02:37



Dies ist das Skript, das ich für lokale Boxen verwende, um das 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. Benennen Sie das Skript (z. generate-ssl.sh) und geben Sie ausführbare Berechtigungen. Die Dateien werden in das gleiche Verzeichnis wie das Skript geschrieben.

Ab Chrome 58 muss SAN in selbstsignierten Zertifikaten eingerichtet werden.

#!/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 = webmaster@$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 Infodatei, damit Sie das neue Zertifikat überprüfen und überprüfen können, ob das SAN ordnungsgemäß eingerichtet 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 wie folgt auf das obige Zertifikat in Ihrer Konfigurationsdatei verweisen:

<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, Ihren Apache-Server (oder Nginx- oder IIS-Server) neu zu starten, damit das neue Zertifikat wirksam wird.


11
2018-05-13 20:21