OpenSSL-Grundlagen: SSL-Zertifikate, private Schlüssel und Certificate Signing Requests

OpenSSL ist ein Kommandozeilen-Werkzeug, das Administratoren häufig verwenden, um Schlüssel zu erzeugen, Certificate Signing Requests (CSRs) zu erstellen, mit X.509-Zertifikaten zu arbeiten, PEM-Dateien zu untersuchen und Zertifikatsformate für Server und Clients umzuwandeln. Dieser Leitfaden behandelt praktische openssl-Befehle für RSA- und Elliptic-Curve-Schlüssel, CSRs mit Subject Alternative Names (SANs), selbstsignierte Zertifikate, die Überprüfung von Zertifikaten, Live-TLS-Tests mit s_client sowie Arbeitsabläufe mit PEM, DER, PKCS12 und PKCS7. Er richtet sich an Administratoren, die HTTPS auf Linux-Servern verwalten, CSRs bei öffentlichen oder privaten Zertifizierungsstellen einreichen oder Probleme mit TLS-Handshakes und Vertrauensketten untersuchen.

So verwenden Sie diesen OpenSSL-Leitfaden

• Wenn Sie zunächst die Grundlagen zu CSRs, Distinguished-Name-Feldern und der nicht interaktiven Option -subj benötigen, beginnen Sie mit Was ist OpenSSL und warum ist es für die SSL/TLS-Verwaltung wichtig? und Certificate Signing Requests (CSRs) erstellen.
• Verwenden Sie den Abschnitt Private Schlüssel mit OpenSSL erzeugen, wenn Sie neue RSA- oder EC-Schlüssel benötigen, einen Passwortschutz einrichten möchten oder RSA 2048, RSA 4096 und P-256 miteinander vergleichen wollen.
• Unter Selbstsignierte Zertifikate erstellen finden Sie die passenden Schritte für Entwicklungs-, Test- und interne TLS-Umgebungen, in denen keine öffentliche Browser-Vertrauenskette erforderlich ist.
• Die Abschnitte Zertifikate, CSRs und private Schlüssel untersuchen und dekodieren, Gültigkeit und Ablaufdatum von Zertifikaten prüfen und Aktive TLS-Verbindungen mit openssl s_client testen helfen bei der Kontrolle lokaler Dateien und entfernter TLS-Dienste.
• Unter Zertifikatsformate konvertieren finden Sie passende Befehle, wenn Windows, Java oder ältere Anwendungen Formate wie DER, PFX oder P7B benötigen.
• Viele Befehle verwenden zur besseren Lesbarkeit das Zeilenfortsetzungszeichen \. Sie können diese Befehle mehrzeilig einfügen oder zu einer einzigen Zeile zusammenfassen.

Die wichtigsten Punkte im Überblick

• RSA-Schlüssel lassen sich mit genrsa oder genpkey erzeugen, EC-Schlüssel mit ecparam. Optional können private Schlüssel mit AES-256 geschützt werden.
• CSRs können mit -newkey, einem bereits vorhandenen privaten Schlüssel, einem vorhandenen Zertifikat oder einer OpenSSL-Konfigurationsdatei mit SAN-Einträgen für DNS-Namen und IP-Adressen erstellt werden.
• Für nicht produktive Umgebungen können selbstsignierte Zertifikate erzeugt und bei OpenSSL 1.1.1 oder neuer über -addext mit SAN-Einträgen versehen werden.
• PEM-Zertifikate und CSRs lassen sich untersuchen, RSA-Schlüsseldaten mit openssl rsa -text anzeigen und die Zugehörigkeit zwischen Schlüssel, Zertifikat und CSR anhand von RSA-Modulus-Hashes beziehungsweise EC-Public-Keys überprüfen.
• Die Felder notBefore und notAfter zeigen den Gültigkeitszeitraum. Zertifikate können gegen CA-Dateien und vollständige Ketten mit -untrusted-Zwischenzertifikaten geprüft werden.
• Mit openssl s_client lassen sich aktive TLS-Verbindungen einschließlich SNI, TLS 1.2, TLS 1.3 und bereitgestellter OCSP-Antworten analysieren.
• Zertifikate können zwischen PEM, DER, PKCS12/PFX und PKCS7/P7B konvertiert werden. Für ältere Software steht bei PKCS12 zusätzlich die Kompatibilitätsoption -legacy zur Verfügung.

Was ist OpenSSL und warum ist es für die SSL/TLS-Verwaltung wichtig?

OpenSSL ist in vielen Linux-Distributionen enthalten und stellt mit openssl ein Werkzeug für nahezu alle dateibasierten Arbeiten mit TLS-Zertifikaten bereit. Dazu gehören das Erzeugen privater Schlüssel, das Erstellen von CSRs, das Signieren von Zertifikaten, das Prüfen von PEM-Dateien und die Konvertierung zwischen verschiedenen Zertifikatsformaten. Anwendungen und Dienste wie Apache, NGINX, HAProxy, Postfix sowie zahlreiche TLS-Bibliotheken für Python und Node.js können OpenSSL verwenden. Dadurch lässt sich dasselbe Werkzeug sowohl für die Erstellung eines CSRs als auch für die Erzeugung der später von Produktivdiensten verwendeten Schlüssel einsetzen.

Die Rolle von OpenSSL im Zertifikatsprozess

Ein TLS-Zertifikat durchläuft üblicherweise fünf zentrale Phasen: die Erzeugung des privaten Schlüssels, die Erstellung des CSRs, die Signierung durch eine öffentliche CA, eine private CA oder durch Selbstsignierung, die Bereitstellung für den verwendenden Dienst sowie die Erneuerung vor Ablauf des Zertifikats. OpenSSL stellt für jede dieser Phasen geeignete Befehle bereit. Die während der Signierung erzeugten Zertifikate verwenden das in RFC 5280 beschriebene X.509-Format.

Erzeugung des privaten Schlüssels
        |
        v
    CSR-Erstellung
        |
        v
    CA-Signierung (oder Selbstsignierung)
        |
        v
    Bereitstellung des Zertifikats
        |
        v
    Erneuerung / Widerruf

Private Schlüssel, CSRs und Zertifikate erklärt

Privater Schlüssel: Eine vertrauliche Datei, die normalerweise im PEM- oder DER-Format gespeichert wird und ausschließlich auf Systemen oder Hardware-Sicherheitsmodulen verbleiben sollte, die unter Ihrer Kontrolle stehen. Der Schlüssel wird für kryptografische Vorgänge während TLS-Handshakes verwendet und sollte niemals per E-Mail verschickt, in Support-Tickets eingefügt oder in Versionsverwaltungssystemen gespeichert werden.

CSR (Certificate Signing Request): Ein üblicherweise PEM-kodierter PKCS#10-Antrag, der einen öffentlichen Schlüssel zusammen mit einem Distinguished Name und optionalen Erweiterungen wie SANs enthält. Der CSR wird an eine Zertifizierungsstelle übermittelt. Diese kann damit ein identitätsgebundenes Zertifikat ausstellen, ohne Zugriff auf den privaten Schlüssel zu benötigen.

Zertifikat: Ein öffentliches X.509-Schlüsselzertifikat gemäß RFC 5280. Es verknüpft einen Subject-Namen und SAN-Einträge mit einem öffentlichen Schlüssel, enthält Angaben zur Gültigkeitsdauer und kann Bestandteil einer Zertifikatskette bis zu einem vertrauenswürdigen Root-Zertifikat sein. TLS-Clients verwenden diese Beziehung bei der Authentifizierung eines Servers.

Kurzer Überblick über die Geschichte von OpenSSL

OpenSSL geht auf SSLeay zurück, eine von Eric Young in den 1990er-Jahren entwickelte SSL-Bibliothek, die als Grundlage für die ersten OpenSSL-Versionen diente. Die 2014 bekannt gewordene Heartbleed-Schwachstelle betraf die TLS-Heartbeat-Implementierung von OpenSSL 1.0.1 und führte weltweit zu umfangreichen Updates, dem Austausch von Schlüsseln und einer stärkeren Aufmerksamkeit für die Pflege des Projekts. Heute wird die Codebasis von der OpenSSL Software Foundation betreut. OpenSSL 3.0 erschien im September 2021 mit einem fünfjährigen LTS-Unterstützungszeitraum. Es folgten Version 3.1 im März 2023, 3.2 im November 2023, 3.3 im April 2024 und 3.4 im Oktober 2024. OpenSSL 1.1.1 erreichte im September 2023 das Ende seines Lebenszyklus, weshalb Produktivsysteme OpenSSL 3.0 LTS oder eine andere weiterhin gepflegte Version einsetzen sollten.

Private Schlüssel mit OpenSSL erzeugen

Private Schlüssel bilden die Grundlage einer TLS-Identität. Sie sollten ausschließlich auf vertrauenswürdigen Systemen erzeugt werden. Beschränken Sie den Dateizugriff beispielsweise mit chmod 600 und speichern Sie Passphrasen für verschlüsselte Schlüssel nicht in Konfigurations-Repositories.

Einen privaten RSA-Schlüssel erzeugen

Der folgende Befehl erstellt einen unverschlüsselten RSA-Schlüssel mit 2048 Bit und speichert ihn als PEM-Datei:

# genrsa: RSA-Schlüsselerzeugung; -out legt den PEM-Pfad fest; 2048 bestimmt die Modulusgröße in Bit
openssl genrsa -out domain.key 2048

Beispielausgabe:

Generating RSA private key, 2048 bit long modulus
........................................................................+++++
............+++++
writing new private key to 'domain.key'

OpenSSL 3.x unterstützt genrsa weiterhin. Für neue Skripte wird jedoch häufig openssl genpkey bevorzugt, da darüber unterschiedliche Algorithmen über eine einheitliche Schnittstelle ausgewählt werden können. Der entsprechende RSA-Befehl lautet:

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out domain.key

Einen privaten EC-Schlüssel mit elliptischer Kurve erzeugen

Der folgende Befehl erzeugt einen P-256-Schlüssel für elliptische Kurven, der auch unter der Bezeichnung prime256v1 bekannt ist, und speichert ihn im PEM-Format:

openssl ecparam -genkey -name prime256v1 -noout -out ec.key

Ein EC-Schlüssel auf Basis von P-256 bietet ein Sicherheitsniveau, das ungefähr mit RSA 3072 vergleichbar ist, benötigt jedoch deutlich weniger Schlüsseldaten. Auf modernen x86-Systemen kann das Signieren mit P-256 ungefähr eine Größenordnung schneller als mit RSA 2048 sein. Dadurch sinkt die CPU-Belastung bei Servern mit vielen neuen TLS-Handshakes. Die RSA-Verifikation ist in der Regel schneller als die P-256-Verifikation. Da der Server während eines TLS-Handshakes jedoch typischerweise einmal signiert und der Client die Signatur prüft, kann EC auf der Serverseite dennoch Vorteile bieten.

Einen passwortgeschützten privaten Schlüssel erzeugen

Der folgende Befehl erstellt einen neuen RSA-Schlüssel mit 2048 Bit und verschlüsselt ihn mit AES-256:

openssl genrsa -aes256 -out domain.key 2048

OpenSSL fordert die Passphrase interaktiv an. In älteren Anleitungen wird häufig -des3 verwendet. Triple-DES steht aus Kompatibilitätsgründen weiterhin zur Verfügung, für neu erzeugte Schlüssel ist AES-256 jedoch die sinnvollere Wahl.

Wenn ausdrücklich eine mit Triple-DES verschlüsselte PEM-Datei benötigt wird, kann weiterhin der folgende ältere Aufruf verwendet werden:

openssl genrsa -des3 -out domain.key 2048

Einen vorhandenen unverschlüsselten privaten Schlüssel verschlüsseln:

openssl rsa -aes256 \
       -in unencrypted.key \
       -out encrypted.key

Wenn Kompatibilität mit älteren Umgebungen erforderlich ist, kann auch ein bereits vorhandener RSA-Schlüssel mit Triple-DES geschützt werden:

openssl rsa -des3 \
       -in unencrypted.key \
       -out encrypted.key

Einen verschlüsselten RSA-Schlüssel entschlüsseln:

openssl rsa \
       -in encrypted.key \
       -out decrypted.key

RSA 2048, RSA 4096 und EC P-256 im Vergleich

Für konkrete Messwerte auf dem eigenen System können Sie openssl speed rsa2048 rsa4096 ecdsap256 ausführen. Die relativen Unterschiede fallen auf vielen x86_64-Servern ähnlich aus. Die tatsächliche Leistung hängt jedoch vom Prozessor, vorhandenen Hardwarebeschleunigungen und der kryptografischen Konfiguration ab.

Certificate Signing Requests (CSRs) erstellen

Ein CSR enthält den Subject-Namen, den öffentlichen Schlüssel und die angeforderten Zertifikatserweiterungen. Damit kann eine Zertifizierungsstelle ein Zertifikat ausstellen, das den benötigten DNS-Namen und Identitätsinformationen entspricht.

Grundlagen zu Certificate Signing Requests

Wenn ein SSL/TLS-Zertifikat von einer öffentlichen oder privaten Zertifizierungsstelle bezogen werden soll, wird normalerweise zunächst ein CSR erstellt. Darin befinden sich der öffentliche Schlüssel und die von der CA benötigten Identitätsinformationen. Diese Bestandteile werden anschließend in das ausgestellte Zertifikat übernommen.

Bei der interaktiven Erstellung eines CSRs fragt OpenSSL verschiedene Werte für den Distinguished Name ab. Wenn keine SANs vorhanden sind, muss der Common Name (CN) dem primären Hostnamen entsprechen. Moderne Zertifikate sollten stattdessen SAN-Einträge für alle Hostnamen enthalten, über die Clients den Dienst aufrufen.

Die übrigen DN-Felder beschreiben die Organisation oder Einheit, die das Zertifikat beantragt. Kommerzielle Zertifizierungsstellen können korrekte Organisations- und Standortdaten voraussetzen.

Typische interaktive Abfragen sehen beispielsweise so aus:

Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:Brooklyn
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example Brooklyn Company
Organizational Unit Name (eg, section) []:Technology Division
Common Name (e.g. server FQDN or YOUR name) []:examplebrooklyn.com
Email Address []:

Wenn die Subject-Werte ohne interaktive Eingabe übergeben werden sollen, kann die Option -subj an einen openssl req-Befehl angehängt werden:

openssl req \
    -newkey rsa:2048 -nodes -keyout domain.key \
    -out domain.csr \
    -subj "/C=US/ST=New York/L=Brooklyn/O=Example Brooklyn Company/CN=examplebrooklyn.com"

CSR und privaten Schlüssel mit einem einzigen Befehl erzeugen

Diese Variante eignet sich, wenn gleichzeitig ein neuer privater RSA-Schlüssel und ein CSR für die Einreichung bei einer Zertifizierungsstelle benötigt werden:

openssl req \
       -newkey rsa:2048 -nodes -keyout domain.key \
       -out domain.csr \
       -sha256

Beantworten Sie die interaktiven CSR-Abfragen, sofern die Werte nicht zusätzlich über -subj bereitgestellt werden.

Einen CSR mit einem vorhandenen privaten Schlüssel erzeugen

Diese Methode ist geeignet, wenn der private Schlüssel bereits vorhanden ist und lediglich ein neuer CSR erstellt werden soll:

openssl req \
       -key domain.key \
       -new -out domain.csr

Einen CSR aus einem vorhandenen Zertifikat und privaten Schlüssel erstellen

Diese Vorgehensweise kann bei der Erneuerung oder Neuausstellung eines Zertifikats hilfreich sein, wenn der ursprüngliche CSR nicht mehr vorhanden ist und die Subject-Informationen eines bestehenden Zertifikats wiederverwendet werden sollen:

openssl x509 \
       -in domain.crt \
       -signkey domain.key \
       -x509toreq -out domain.csr

Einen CSR mit Konfigurationsdatei und SANs erzeugen

Mit einer Konfigurationsdatei lassen sich SAN-Werte und weitere Anfragedaten ohne interaktive Eingabe festlegen. Gleichzeitig werden die gewünschten DNS-Namen und IP-Adressen in einer wiederverwendbaren Datei dokumentiert.

1. san.cnf erstellen:

[req]
default_bits       = 2048
prompt             = no
default_md         = sha256
distinguished_name = dn
req_extensions     = req_ext

[dn]
C  = US
ST = New York
L  = Brooklyn
O  = Example Brooklyn Company
CN = examplebrooklyn.com

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = examplebrooklyn.com
DNS.2 = www.examplebrooklyn.com
IP.1  = 192.168.1.10

2. CSR erzeugen:

openssl req \
    -new \
    -key domain.key \
    -out domain.csr \
    -config san.cnf

Häufige Fehler mit san.cnf:

• Error opening config file san.cnf: Der relative Pfad konnte nicht aufgelöst werden. Verwenden Sie einen absoluten Pfad oder führen Sie OpenSSL aus dem Verzeichnis aus, in dem sich die Konfigurationsdatei befindet.
• SAN-Einträge fehlen im erzeugten CSR: Prüfen Sie, ob unter [req] die Zeile req_extensions = req_ext vorhanden ist und [req_ext] auf [alt_names] verweist. Ein falsch geschriebener Abschnittsname kann dazu führen, dass ein CSR ohne SANs erstellt wird.
• error in req: Jeder DN-Eintrag unter [dn] muss in einer eigenen Zeile stehen und ein Gleichheitszeichen verwenden. Auch nachgestellte Leerzeichen oder BOM-Zeichen können Parsing-Fehler verursachen.

3. SAN-Einträge überprüfen:

openssl req -text -noout -in domain.csr | grep -A1 "Subject Alternative"

SANs werden nicht allein durch die Angabe von -subj hinzugefügt. Verwenden Sie stattdessen eine Konfigurationsdatei wie im vorherigen Beispiel oder ab OpenSSL 1.1.1 die Option -addext.

CSR mit -addext in einem einzigen Befehl unter OpenSSL 1.1.1 oder neuer:

openssl req \
    -newkey rsa:2048 -nodes -keyout domain.key \
    -out domain.csr \
    -subj "/C=US/ST=New York/L=Brooklyn/O=Example Brooklyn Company/CN=examplebrooklyn.com" \
    -addext "subjectAltName=DNS:examplebrooklyn.com,DNS:www.examplebrooklyn.com"

Selbstsignierte Zertifikate erstellen

Selbstsignierte Zertifikate ermöglichen eine TLS-Verschlüsselung, werden jedoch nicht automatisch von öffentlichen Vertrauensspeichern akzeptiert. Sie eignen sich für Entwicklungsumgebungen, administrative Oberflächen, Testsysteme und private Netzwerke, in denen eigene Root-Zertifikate manuell verteilt werden können.

Selbstsigniertes Zertifikat mit einem neuen Schlüssel erzeugen

Der folgende Befehl erstellt gleichzeitig einen neuen RSA-Schlüssel und ein selbstsigniertes Zertifikat:

openssl req \
       -newkey rsa:2048 -nodes -keyout domain.key \
       -x509 -days 365 -out domain.crt

Selbstsigniertes Zertifikat aus einem vorhandenen privaten Schlüssel erstellen

Der folgende Befehl erstellt ein selbstsigniertes Zertifikat auf Basis eines bereits vorhandenen privaten Schlüssels. Wenn -subj nicht angegeben wird, fragt OpenSSL die Subject-Daten interaktiv ab:

openssl req \
       -key domain.key \
       -new \
       -x509 -days 365 -out domain.crt

Selbstsigniertes Zertifikat aus privatem Schlüssel und CSR erzeugen

openssl x509 \
       -signkey domain.key \
       -in domain.csr \
       -req -days 365 -out domain.crt

Selbstsigniertes Zertifikat mit SANs erstellen

Moderne TLS-Clients erwarten Hostnamen in der SAN-Erweiterung. Dies gilt auch bei selbstsignierten Zertifikaten:

openssl req \
    -newkey rsa:2048 -nodes -keyout domain.key \
    -x509 -days 365 -out domain.crt \
    -subj "/CN=examplebrooklyn.com" \
    -addext "subjectAltName=DNS:examplebrooklyn.com,DNS:www.examplebrooklyn.com"

Aktuelle Browser behandeln die SAN-Erweiterung als maßgebliche Quelle für Hostnamen. Ein selbstsigniertes Zertifikat ohne SAN-Einträge kann deshalb bei der Hostnamenprüfung fehlschlagen, selbst wenn dem Zertifikat zuvor manuell vertraut wurde.

Zertifikat auf einem Webserver bereitstellen

Nach der Erzeugung von privatem Schlüssel und Zertifikat sollten die Dateien an Speicherorte verschoben werden, auf die der Webserver zugreifen kann. Anschließend müssen passende Dateiberechtigungen gesetzt und der betreffende Dienst neu geladen werden.

Eine häufig verwendete Dateistruktur unter Linux sieht beispielsweise so aus:

sudo mv domain.crt /etc/ssl/certs/domain.crt
sudo mv domain.key /etc/ssl/private/domain.key
sudo chmod 644 /etc/ssl/certs/domain.crt
sudo chmod 600 /etc/ssl/private/domain.key
sudo chown root:root /etc/ssl/certs/domain.crt /etc/ssl/private/domain.key

Nachdem NGINX auf das neue Zertifikat und den privaten Schlüssel verweist, sollte zunächst die Konfiguration geprüft und erst danach neu geladen werden:

sudo nginx -t && sudo systemctl reload nginx

Für Apache:

sudo apachectl configtest && sudo systemctl reload apache2

Prüfen Sie die Konfiguration immer vor dem Neuladen des Webservers. Ein fehlerhafter TLS-Eintrag in einer NGINX- oder Apache-Konfiguration kann verhindern, dass der Dienst nach dem Reload korrekt startet. Befehle wie nginx -t und apachectl configtest analysieren die Konfiguration, ohne die Änderungen bereits zu aktivieren.

Zertifikate, CSRs und private Schlüssel untersuchen und dekodieren

OpenSSL kann Informationen aus Zertifikaten, CSRs und privaten Schlüsseln direkt anzeigen, ohne dass die betreffende Datei vorher in ein anderes Format konvertiert werden muss.

Inhalt eines Zertifikats anzeigen

Der folgende Befehl zeigt die dekodierten X.509-Felder eines Zertifikats zur Überprüfung an:

openssl x509 -text -noout -in domain.crt

Gekürztes Beispiel:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ...
        Issuer: CN = Example CA
        Validity
            Not Before: Jan  1 00:00:00 2026 GMT
            Not After : Dec 31 23:59:59 2027 GMT
        Subject: CN = examplebrooklyn.com
        ...
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:examplebrooklyn.com, DNS:www.examplebrooklyn.com

CSR-Details dekodieren und anzeigen

openssl req -text -noout -verify -in domain.csr

Beispiel:

Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: C = US, ST = New York, L = Brooklyn, O = Example Brooklyn Company, CN = examplebrooklyn.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name:
                DNS:examplebrooklyn.com, DNS:www.examplebrooklyn.com

Details eines privaten Schlüssels anzeigen

Für einen privaten RSA-Schlüssel:

openssl rsa -text -noout -in domain.key

Für private EC-Schlüssel wird rsa durch ec ersetzt:

openssl ec -text -noout -in ec.key

Einen RSA-Schlüssel prüfen, ohne seine gesamte Struktur auszugeben:

openssl rsa -check -in domain.key

Bei verschlüsselten privaten Schlüsseln wird die Passphrase abgefragt. Eine erfolgreiche Verarbeitung bestätigt, dass OpenSSL die PEM-Datei korrekt lesen kann.

Veröffentlichen Sie niemals private Schlüssel, entschlüsselte Schlüsseldaten oder Ausgaben von rsa -text in öffentlich zugänglichen Support-Tickets, Chats oder Monitoring-Systemen.

Prüfen, ob privater Schlüssel, Zertifikat und CSR zusammengehören

Mit den folgenden Befehlen werden Digests des RSA-Modulus berechnet. Dadurch lässt sich feststellen, ob ein Zertifikat, ein CSR und ein privater Schlüssel auf demselben Schlüsselpaar basieren:

openssl rsa -noout -modulus -in domain.key | openssl md5
openssl x509 -noout -modulus -in domain.crt | openssl md5
openssl req -noout -modulus -in domain.csr | openssl md5

Identische MD5-Ausgaben zeigen an, dass allen Dateien dasselbe RSA-Schlüsselpaar zugrunde liegt.

Häufiges Problem: unterschiedliche Modulus-Werte. Wenn sich die Digests unterscheiden, wurden die Dateien mit verschiedenen privaten Schlüsseln erzeugt. Eine häufige Ursache ist, dass nach der Erstellung des ursprünglichen CSRs ein neuer privater Schlüssel generiert wurde und anschließend versucht wird, den alten CSR mit dem neuen Schlüssel zu verwenden. Ebenso kann ein von einer CA signiertes Zertifikat versehentlich mit dem falschen privaten Schlüssel auf dem Server installiert worden sein. Erstellen Sie in diesem Fall einen neuen CSR mit dem korrekten Schlüssel oder stellen Sie den privaten Schlüssel wieder her, der ursprünglich für den CSR verwendet wurde.

Bei EC-Schlüsseln sollten anstelle des RSA-Modulus die exportierten öffentlichen Schlüssel verglichen werden:

openssl ec -pubout -in ec.key | openssl md5
openssl x509 -pubkey -noout -in domain.crt | openssl md5

Identische MD5-Ausgaben bestätigen, dass der private EC-Schlüssel zum Zertifikat gehört.

Gültigkeit und Ablaufdatum von Zertifikaten prüfen

Mit den folgenden Befehlen lässt sich überprüfen, ob ein Zertifikat aktuell innerhalb seines Gültigkeitszeitraums liegt und ob eine gültige Vertrauenskette zu einer akzeptierten Zertifizierungsstelle aufgebaut werden kann. openssl verify überprüft dabei die Datei oder das Verzeichnis, das explizit über -CAfile beziehungsweise -CApath angegeben wurde.

Ablaufdatum eines Zertifikats prüfen

openssl x509 -enddate -noout -in domain.crt

Beispiel:

notAfter=Dec 31 23:59:59 2027 GMT

Um Beginn und Ende des Gültigkeitszeitraums gemeinsam anzuzeigen:

openssl x509 -dates -noout -in domain.crt

Zertifikat gegen ein CA-Bundle prüfen

openssl verify -verbose -CAfile ca.crt domain.crt

Ein Exit-Code von 0 bedeutet, dass OpenSSL gemäß den geltenden X.509-Prüfregeln erfolgreich einen Zertifikatspfad zu einem vertrauenswürdigen Anker aufbauen konnte.

Eine fehlgeschlagene Prüfung kann beispielsweise so aussehen:

CN = wrong.example.com
error 62 at 0 depth lookup: Hostname mismatch
domain.crt: verification failed

Vollständige Zertifikatskette überprüfen

openssl verify -CAfile ca-chain.pem -untrusted intermediate.pem domain.crt

Verwenden Sie -untrusted für Zwischenzertifikate, wenn geprüft werden soll, wie ein signiertes TLS-Zertifikat mit einem vertrauenswürdigen Root-Zertifikat verkettet werden kann. Öffentliche Zertifizierungsstellen sollten Zertifikate mit korrekt aufgebauten Zertifikatsketten ausstellen.

Häufige Fehler bei der Prüfung einer Zertifikatskette:

• unable to get local issuer certificate: Das Zwischenzertifikat, das das Leaf-Zertifikat signiert hat, konnte nicht gefunden werden. Stellen Sie es über -untrusted intermediate.pem bereit oder nehmen Sie es in das passende CA-Bundle auf.
• self signed certificate in certificate chain: Ein Root-Zertifikat innerhalb der Kette wird als nicht vertrauenswürdig betrachtet. Fügen Sie es zu -CAfile hinzu, wenn ihm vertraut werden soll, oder entfernen Sie ein unnötiges selbstsigniertes Root-Zertifikat aus der an Clients ausgelieferten Kette.
• certificate has expired: Prüfen Sie notAfter mit openssl x509 -enddate -noout -in cert.pem. Wenn das Leaf-Zertifikat noch gültig ist, kontrollieren Sie auf dieselbe Weise sämtliche Intermediate-Zertifikate.

Aktive TLS-Verbindungen mit openssl s_client testen

Mit openssl s_client können clientseitige TLS-Handshakes direkt über die Kommandozeile reproduziert werden, ohne dafür einen Browser verwenden zu müssen.

Verbindung zu einem entfernten Server herstellen und dessen Zertifikat prüfen

openssl s_client -connect example.com:443 -servername example.com

Beispiel für eine gekürzte Ausgabe:

CONNECTED(00000003)
---
Certificate chain
 0 s:CN = example.com
   i:C = US, O = Example CA, CN = Example Intermediate
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=CN = example.com
issuer=C = US, O = Example CA, CN = Example Intermediate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

Beenden Sie die Verbindung mit Ctrl+C. Falls OpenSSL nach der Ausgabe der Handshake-Informationen weiterhin auf eine Eingabe wartet, kann auch Q verwendet werden.

Bestimmte TLS-Protokollversionen testen

# TLS 1.2 testen
openssl s_client -connect example.com:443 -tls1_2

# TLS 1.3 testen
openssl s_client -connect example.com:443 -tls1_3

Unterstützt der entfernte Server die ausgewählte Protokollversion nicht, schlägt der Handshake normalerweise unmittelbar fehl. Dies zeigt zunächst lediglich, dass die betreffende Protokollversion nicht verfügbar ist, und muss nicht automatisch auf eine fehlerhafte Produktivkonfiguration hindeuten.

OCSP Stapling und Zertifikatswiderruf prüfen

openssl s_client -connect example.com:443 -status 2>/dev/null | grep -A 17 'OCSP response:'

OCSP Stapling ermöglicht es dem Server, direkt während des TLS-Handshakes eine aktuelle Information zum Widerrufsstatus eines Zertifikats mitzuliefern. Wenn OpenSSL OCSP response: no response sent ausgibt, wurde keine OCSP-Antwort bereitgestellt. Das kommt häufig vor und stellt nicht automatisch einen Fehler dar.

Mit -showcerts kann OpenSSL sämtliche Zertifikate anzeigen, die der entfernte Server als Teil seiner Zertifikatskette übermittelt. Diese lassen sich anschließend offline untersuchen oder als PEM-Dateien speichern.

Häufige TLS-Fehler mit s_client diagnostizieren

Mehrere häufig auftretende TLS-Handshake-Probleme lassen sich anhand charakteristischer s_client-Ausgaben erkennen.

Hostname stimmt nicht überein: Der für die Verbindung verwendete Hostname ist nicht in den SAN-Einträgen des Zertifikats enthalten.

verify error:num=62:Hostname mismatch

Stellen Sie ein neues Zertifikat mit den erforderlichen SAN-Einträgen aus oder verwenden Sie für die Verbindung einen Hostnamen, der bereits im SAN-Feld des Zertifikats vorhanden ist.

Abgelaufenes Zertifikat oder abgelaufenes Element der Zertifikatskette:

verify return code: 10 (certificate has expired)

Prüfen Sie jedes vom Server bereitgestellte Zertifikat einschließlich aller Intermediate-Zertifikate. Die folgende Pipeline trennt die Zertifikatskette in einzelne Dateien und gibt Subject sowie Ablaufdatum jedes Zertifikats aus:

openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null \
  | awk '/BEGIN CERTIFICATE/{n++} n{print > ("/tmp/cert-" n ".pem")}' \
  && for f in /tmp/cert-*.pem; do openssl x509 -subject -enddate -noout -in "$f"; done \
  && rm /tmp/cert-*.pem

Der awk-Schritt speichert jeden PEM-Block in einer nummerierten Datei unter /tmp/. Die for-Schleife gibt anschließend Subject und notAfter jedes Zertifikats aus. Am Ende entfernt rm die temporären Dateien. Die Pipeline verwendet Standardfunktionen von awk und kann auf Linux-, macOS- und BSD-Systemen eingesetzt werden.

Nicht vertrauenswürdiges Intermediate-Zertifikat, weil der Server nur das Leaf-Zertifikat bereitstellt:

verify return code: 21 (unable to verify the first certificate)

Der Server liefert das erforderliche Intermediate-Zertifikat nicht aus. Bei NGINX können Leaf- und Intermediate-Zertifikat in einer Datei zusammengeführt und diese anschließend über ssl_certificate verwendet werden:

cat domain.crt intermediate.crt > fullchain.crt

Mutual TLS mit Client-Zertifikatsauthentifizierung testen:

openssl s_client \
    -connect example.com:443 \
    -cert client.crt \
    -key client.key

Verwenden Sie diesen Test, wenn der Server ein Client-Zertifikat verlangt. Ist mTLS verpflichtend und der Client übermittelt kein Zertifikat, kann der Server den TLS-Handshake mit tlsv13 alert certificate required beenden.

Zertifikatsformate konvertieren

Überblick über Zertifikatsformate und Konvertierungswege

PEM in DER konvertieren

openssl x509 \
       -in domain.crt \
       -outform der -out domain.der

DER in PEM konvertieren

Mit dem folgenden Befehl wird ein binär kodiertes DER-Zertifikat in eine PEM-Datei umgewandelt:

openssl x509 \
       -inform der -in domain.der \
       -out domain.crt

PEM in PKCS12 beziehungsweise PFX konvertieren

Mit dem folgenden Befehl werden Zertifikat, privater Schlüssel und CA-Kette gemeinsam in eine PKCS12-Datei exportiert:

openssl pkcs12 \
    -export \
    -inkey domain.key \
    -in domain.crt \
    -certfile ca-chain.pem \
    -out domain.pfx

Minimaler Export ohne separate CA-Kettendatei:

Diese Variante kann verwendet werden, wenn die PEM-Datei des Leaf-Zertifikats die erforderlichen Intermediate-Zertifikate bereits enthält.

openssl pkcs12 \
       -inkey domain.key \
       -in domain.crt \
       -export -out domain.pfx

Wenn die verwendete Software dies erlaubt, kann das Exportpasswort leer bleiben.

OpenSSL 3 verwendet geänderte Standardalgorithmen für PKCS#12-Dateien. Falls ältere Windows-Komponenten oder Java-Keystores eine erzeugte PFX-Datei aufgrund der moderneren Einstellungen nicht importieren können, kann -legacy ergänzt werden.

PKCS12 in PEM konvertieren

openssl pkcs12 \
       -in domain.pfx \
       -nodes -out domain.combined.crt

PEM in PKCS7 beziehungsweise P7B konvertieren

openssl crl2pkcs7 -nocrl \
       -certfile domain.crt \
       -certfile ca-chain.crt \
       -out domain.p7b

PKCS7 in PEM konvertieren

openssl pkcs7 \
       -in domain.p7b \
       -print_certs -out domain.crt

Installierte OpenSSL-Version prüfen

Der Befehl openssl version zeigt die installierte OpenSSL-Version und die Build-Konfiguration an. Diese Informationen können darüber entscheiden, welche Funktionen und Optionen verfügbar sind.

openssl version -a

Beispielausgabe einer OpenSSL-3.x-Installation:

OpenSSL 3.0.13 30 Jan 2024
built on: Wed Apr 10 12:00:00 2024 UTC
platform: linux-x86_64
compiler: gcc ...
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3"
MODULESDIR: "/usr/lib/x86_64-linux-gnu/ossl-modules"
Seeding source: os-specific

Die OpenSSL-Zweige 1.0.x und 1.1.x werden vom Upstream-Projekt nicht mehr gepflegt. Produktivsysteme sollten daher eine weiterhin unterstützte OpenSSL-3.x-Version aus den Paketquellen des jeweiligen Betriebssystems verwenden oder beim eigenen Kompilieren die OpenSSL-Release-Strategie berücksichtigen.

OpenSSL im Vergleich zu LibreSSL, BoringSSL und Rustls

OpenSSL gehört weiterhin zu den verbreitetsten TLS-Werkzeugen auf Linux-Servern und bietet umfangreiche Funktionen für dateibasierte Public-Key-Infrastrukturen. Alternative TLS-Bibliotheken existieren, weil verschiedene Projekte unterschiedliche Schwerpunkte setzen, beispielsweise Lizenzierung, Umfang der Codebasis, API-Stabilität, Plattformanforderungen oder Speichersicherheit.

Wann eine Alternative zu OpenSSL sinnvoll sein kann

BoringSSL kann geeignet sein, wenn eine Software eng an das TLS-Verhalten Chromium-basierter Netzwerkkomponenten gekoppelt ist. LibreSSL kann in Betracht gezogen werden, wenn eine Plattform auf OpenBSD standardisiert ist und Abweichungen bei der Kommandozeilenbedienung akzeptiert werden. Rustls eignet sich für Rust-Anwendungen, die eine native Rust-TLS-Implementierung ohne OpenSSL-Abhängigkeit benötigen. Für die allgemeine Zertifikatsverwaltung auf Linux-Systemen bleibt OpenSSL wegen seiner umfangreichen Dokumentation, breiten Paketunterstützung und zahlreichen Integrationen eine praktische Lösung.

Zertifikatserneuerung und Rotation automatisieren

Bei einem oder zwei Systemen kann eine manuelle Zertifikatserneuerung noch praktikabel sein. In größeren Umgebungen sollte die Erneuerung automatisiert werden. Zwei Vorgehensweisen decken viele übliche Einsatzfälle ab.

ACME-Automatisierung mit Certbot kann für öffentliche Zertifikate von Let’s Encrypt oder anderen ACME-kompatiblen Zertifizierungsstellen verwendet werden:

sudo certbot renew --dry-run

Ein erfolgreicher Testlauf bestätigt, dass die eingerichtete Erneuerung grundsätzlich funktioniert, bevor ein echtes Zertifikat abläuft. Prüfen Sie außerdem, ob der zugehörige systemd-Timer aktiv ist:

sudo systemctl list-timers | grep certbot

Eigene Erneuerungsskripte können für private Zertifizierungsstellen oder Zertifikate eingesetzt werden, die nicht über ACME verwaltet werden können. Ein solches Skript sollte:

1. Einen CSR mit derselben san.cnf-Konfiguration erzeugen, die bereits bei der ursprünglichen Ausstellung verwendet wurde.
2. Den CSR an den Endpunkt oder das Signierungswerkzeug der jeweiligen Zertifizierungsstelle übermitteln.
3. Die Zertifikatsdatei unter /etc/ssl/certs/ atomar ersetzen.
4. Die Anwendung oder den Webserver erst nach einem erfolgreichen Konfigurationstest neu laden.
5. Eine Benachrichtigung über Erfolg oder Fehlschlag ausgeben.

Wenn möglich, sollte das Skript über einen systemd-Timer statt über einen klassischen Cronjob ausgeführt werden. systemd-Timer schreiben in das Journal, unterstützen Dienstabhängigkeiten und ermöglichen Wiederholungsversuche nach vorübergehenden Fehlern.

Das Ablaufdatum eines Zertifikats sollte unabhängig vom eigentlichen Erneuerungsprozess überwacht werden. Ein falsch eingerichteter Timer oder ein unbemerkt fehlschlagendes Skript kann andernfalls trotzdem zu einem abgelaufenen Zertifikat führen. Ein wöchentlich geplanter Prozess, der die Ausgabe von openssl x509 -enddate -noout an ein Benachrichtigungssystem weitergibt, kann solche Fehler frühzeitig erkennen.

OpenSSL FAQ

Wie erstelle ich einen CSR mit einem vorhandenen privaten Schlüssel?

Verwenden Sie openssl req mit -key für den vorhandenen PEM-Schlüssel und -new, um einen neuen CSR zu erzeugen:

openssl req -key existing.key -new -out request.csr

Mit -subj lassen sich interaktive Abfragen vermeiden. -config kann verwendet werden, wenn SAN-Einträge oder andere in einer Konfigurationsdatei definierte Erweiterungen erforderlich sind.

Wie füge ich einem CSR Subject Alternative Names hinzu?

Definieren Sie die SAN-Einträge im Abschnitt [req_ext] einer OpenSSL-Konfigurationsdatei, die über -config eingebunden wird. Alternativ kann mit OpenSSL 1.1.1 oder neuer -addext 'subjectAltName=DNS:example.com,DNS:www.example.com' verwendet werden:

openssl req -new -key domain.key -out domain.csr -config san.cnf

Das Ergebnis lässt sich mit openssl req -text -noout -in domain.csr kontrollieren.

Wie prüfe ich, wann ein SSL-Zertifikat abläuft?

Geben Sie das Feld notAfter aus:

openssl x509 -enddate -noout -in domain.crt

Mit -dates werden sowohl notBefore als auch notAfter ausgegeben.

Wie prüfe ich, ob ein privater Schlüssel zu einem Zertifikat gehört?

Bei RSA-Zertifikaten können die Modulus-Hashes verglichen werden:

openssl rsa -noout -modulus -in domain.key | openssl md5
openssl x509 -noout -modulus -in domain.crt | openssl md5

Sind beide Ausgaben identisch, gehören Zertifikat und privater Schlüssel zum selben RSA-Schlüsselpaar.

Wie dekodiere und lese ich den Inhalt eines CSRs?

Mit req -text und -verify kann der CSR untersucht und seine Signatur überprüft werden:

openssl req -text -noout -verify -in domain.csr

Die dekodierte Ausgabe enthält unter anderem den Distinguished Name des Subjects und angeforderte SAN-Einträge.

Wie konvertiere ich ein PEM-Zertifikat in PFX oder PKCS12?

Verwenden Sie pkcs12 -export und geben Sie privaten Schlüssel, Leaf-Zertifikat und optional die CA-Kette an:

openssl pkcs12 -export -inkey domain.key -in domain.crt -certfile ca-chain.pem -out domain.pfx

Fügen Sie -legacy hinzu, wenn ein älterer Importer die standardmäßig von OpenSSL 3 verwendeten PKCS#12-Algorithmen nicht verarbeiten kann.

Was ist der Unterschied zwischen RSA 2048 und RSA 4096?

RSA 4096 verwendet einen größeren Modulus als RSA 2048. Dadurch steigt der Rechenaufwand für asymmetrische kryptografische Operationen innerhalb von TLS, gleichzeitig entsteht jedoch eine zusätzliche Sicherheitsreserve gegenüber klassischen Angriffsszenarien. RSA 2048 ist weiterhin eine häufig verwendete Wahl für öffentliche TLS-Zertifikate. RSA 4096 bietet sich an, wenn Sicherheitsrichtlinien ausdrücklich eine größere Schlüssellänge verlangen.

Wie verwende ich openssl s_client zum Testen einer aktiven TLS-Verbindung?

Öffnen Sie eine Client-Verbindung und lassen Sie die ausgehandelten TLS-Informationen anzeigen:

openssl s_client -connect example.com:443 -servername example.com

Ergänzen Sie -tls1_2 oder -tls1_3, wenn eine bestimmte TLS-Version getestet werden soll. Mit -showcerts lässt sich die vom entfernten Server übermittelte PEM-Zertifikatskette ausgeben.

Bestimmte TLS-Protokollversionen testen

# TLS 1.2 testen
openssl s_client -connect example.com:443 -tls1_2

# TLS 1.3 testen
openssl s_client -connect example.com:443 -tls1_3

Unterstützt der Server die ausgewählte Protokollversion nicht, schlägt der Handshake normalerweise schnell fehl. Dieses Verhalten sollte zunächst als Hinweis auf die unterstützten Protokolle verstanden werden und bedeutet nicht automatisch, dass die Produktivkonfiguration fehlerhaft ist.

OCSP Stapling und Zertifikatswiderruf prüfen

openssl s_client -connect example.com:443 -status 2>/dev/null | grep -A 17 'OCSP response:'

Beim OCSP Stapling kann der Server eine aktuelle Widerrufsinformation bereits während des TLS-Handshakes mitliefern. Erscheint OCSP response: no response sent, wurde keine solche Antwort übermittelt. Dieses Verhalten ist weit verbreitet und nicht zwangsläufig ein Fehler.

Mit -showcerts können sämtliche Zertifikate der vom Gegenüber bereitgestellten Zertifikatskette angezeigt und anschließend offline untersucht oder als PEM-Dateien gespeichert werden.

Häufige TLS-Fehler mit s_client diagnostizieren

Mehrere typische TLS-Handshake-Fehler lassen sich anhand klar erkennbarer Meldungen in der Ausgabe von s_client identifizieren.

Abweichender Hostname. Der verwendete Hostname befindet sich nicht in der SAN-Liste des Zertifikats:

verify error:num=62:Hostname mismatch

Stellen Sie ein neues Zertifikat mit den korrekten SAN-Einträgen aus oder verbinden Sie sich über einen Hostnamen, der bereits in der SAN-Liste enthalten ist.

Abgelaufenes Zertifikat oder abgelaufenes Element innerhalb der Zertifikatskette:

verify return code: 10 (certificate has expired)

Kontrollieren Sie jedes vom Server bereitgestellte Zertifikat einschließlich aller Zwischenzertifikate. Die folgende Pipeline trennt die Zertifikatskette in einzelne Dateien und zeigt für jedes Zertifikat Subject und Ablaufdatum an:

openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null \
  | awk '/BEGIN CERTIFICATE/{n++} n{print > ("/tmp/cert-" n ".pem")}' \
  && for f in /tmp/cert-*.pem; do openssl x509 -subject -enddate -noout -in "$f"; done \
  && rm /tmp/cert-*.pem

awk speichert jeden PEM-Block in einer nummerierten Datei im Verzeichnis /tmp/. Danach gibt die for-Schleife für jedes Zertifikat Subject und notAfter aus. Abschließend entfernt rm die temporären Dateien. Die Pipeline basiert auf standardmäßig verfügbaren awk-Funktionen und kann unter Linux, macOS und BSD ausgeführt werden.

Nicht vertrauenswürdiges Zwischenzertifikat, wenn der Server nur das Leaf-Zertifikat sendet:

verify return code: 21 (unable to verify the first certificate)

Das erforderliche Zwischenzertifikat wird vom Server nicht mitgeliefert. Bei NGINX lassen sich Leaf- und Intermediate-Zertifikat in einer einzelnen Datei zusammenführen. Anschließend kann ssl_certificate auf diese Datei verweisen:

cat domain.crt intermediate.crt > fullchain.crt

Mutual TLS mit Client-Zertifikatsauthentifizierung testen:

openssl s_client \
    -connect example.com:443 \
    -cert client.crt \
    -key client.key

Verwenden Sie diesen Befehl, wenn der Server ein Client-Zertifikat voraussetzt. Ist Mutual TLS vorgeschrieben und der Client stellt kein Zertifikat bereit, kann der Server den Handshake mit tlsv13 alert certificate required abbrechen.

Zertifikatsformate konvertieren

Überblick über Zertifikatsformate und mögliche Konvertierungen

PEM nach DER konvertieren

openssl x509 \
       -in domain.crt \
       -outform der -out domain.der

DER nach PEM konvertieren

Der folgende Befehl wandelt ein binär kodiertes DER-Zertifikat in ein PEM-kodiertes Zertifikat um:

openssl x509 \
       -inform der -in domain.der \
       -out domain.crt

PEM nach PKCS12 beziehungsweise PFX konvertieren

Der folgende Befehl exportiert privaten Schlüssel, Leaf-Zertifikat und CA-Kette gemeinsam in eine PKCS12-Datei:

openssl pkcs12 \
    -export \
    -inkey domain.key \
    -in domain.crt \
    -certfile ca-chain.pem \
    -out domain.pfx

Minimaler Export ohne separate Zertifikatskettendatei ist möglich, wenn die PEM-Datei des Leaf-Zertifikats die benötigten Intermediate-Zertifikate bereits enthält:

openssl pkcs12 \
       -inkey domain.key \
       -in domain.crt \
       -export -out domain.pfx

Wenn die Zielsoftware einen ungeschützten Export unterstützt, kann das Exportpasswort leer bleiben.

OpenSSL 3 führte andere Standardalgorithmen für PKCS#12-Dateien ein. Bei älteren Windows-Komponenten oder Java-Keystores, die diese moderneren Schlüsselableitungseinstellungen nicht unterstützen, kann die Option -legacy erforderlich sein.

PKCS12 nach PEM konvertieren

openssl pkcs12 \
       -in domain.pfx \
       -nodes -out domain.combined.crt

PEM nach PKCS7 beziehungsweise P7B konvertieren

openssl crl2pkcs7 -nocrl \
       -certfile domain.crt \
       -certfile ca-chain.crt \
       -out domain.p7b

PKCS7 nach PEM konvertieren

openssl pkcs7 \
       -in domain.p7b \
       -print_certs -out domain.crt

OpenSSL-Version überprüfen

Mit openssl version können Informationen über das installierte OpenSSL-Programm und dessen Build-Konfiguration ausgegeben werden. Diese Angaben können beeinflussen, welche einzelnen Funktionen verfügbar sind.

openssl version -a

Beispielausgabe einer OpenSSL-3.x-Installation:

OpenSSL 3.0.13 30 Jan 2024
built on: Wed Apr 10 12:00:00 2024 UTC
platform: linux-x86_64
compiler: gcc ...
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3"
MODULESDIR: "/usr/lib/x86_64-linux-gnu/ossl-modules"
Seeding source: os-specific

Die OpenSSL-Zweige 1.0.x und 1.1.x haben das Ende ihres Lebenszyklus erreicht. Produktivserver sollten deshalb gepflegte OpenSSL-3.x-Pakete des jeweiligen Betriebssystemanbieters verwenden oder beim Kompilieren aus dem Quellcode die offizielle OpenSSL-Release-Strategie berücksichtigen.

OpenSSL und Alternativen: LibreSSL, BoringSSL und Rustls

OpenSSL zählt weiterhin zu den am häufigsten eingesetzten TLS-Werkzeugen auf Linux-Servern und bietet umfangreiche Möglichkeiten für die Verwaltung dateibasierter Public-Key-Infrastrukturen. Alternative TLS-Bibliotheken verfolgen teilweise andere Ziele und setzen unterschiedliche Prioritäten, etwa bei Lizenzierung, Codeumfang, API-Stabilität, Plattformanforderungen oder Speichersicherheit.

Wann eine OpenSSL-Alternative in Betracht kommt

BoringSSL kann eine passende Wahl sein, wenn eine Software das TLS-Verhalten Chromium-basierter Netzwerkkomponenten nachbilden oder nutzen muss. LibreSSL kann für Plattformen sinnvoll sein, die auf OpenBSD standardisiert sind und Unterschiede im Kommandozeilenwerkzeug akzeptieren. Rustls eignet sich insbesondere für Rust-Anwendungen, die eine reine Rust-TLS-Implementierung ohne OpenSSL-Verknüpfung benötigen. Für die alltägliche Zertifikatsverwaltung auf Linux-Systemen bleibt OpenSSL aufgrund der umfangreichen Dokumentation, breiten Paketverfügbarkeit und zahlreichen Drittanbieterintegrationen eine praktische Lösung.

Zertifikatserneuerung und Zertifikatsrotation automatisieren

Eine manuelle Erneuerung kann bei einem oder zwei Systemen noch überschaubar sein. Bei größeren Installationen ist eine Automatisierung in der Regel sinnvoller. Zwei Ansätze decken zahlreiche typische Umgebungen ab.

ACME-Automatisierung mit Certbot eignet sich für öffentliche Zertifikate, die von Let’s Encrypt oder einer anderen ACME-kompatiblen Zertifizierungsstelle ausgestellt werden:

sudo certbot renew --dry-run

Ein erfolgreicher Probelauf bestätigt, dass der konfigurierte Mechanismus Zertifikate erneuern kann, bevor sie ablaufen. Zusätzlich sollte überprüft werden, ob der entsprechende systemd-Timer aktiv ist:

sudo systemctl list-timers | grep certbot

Ein eigenes Erneuerungsskript kann für private Zertifizierungsstellen oder Zertifikate verwendet werden, die nicht über ACME verwaltet werden. Das Skript sollte:

1. Einen CSR mit derselben san.cnf-Konfiguration erzeugen, die bereits bei der ursprünglichen Ausstellung verwendet wurde.
2. Den CSR an den vorgesehenen Endpunkt oder das Signierungswerkzeug der Zertifizierungsstelle übermitteln.
3. Die Zertifikatsdatei unter /etc/ssl/certs/ atomar ersetzen.
4. Den Dienst, der das Zertifikat verwendet, erst nach einem erfolgreichen Konfigurationstest neu laden.
5. Eine Benachrichtigung ausgeben, ob der Vorgang erfolgreich war oder fehlgeschlagen ist.

Wenn möglich, sollte das Erneuerungsskript über einen systemd-Timer und nicht über einen herkömmlichen Cronjob ausgeführt werden. systemd-Timer protokollieren im Journal, unterstützen Dienstabhängigkeiten und können nach vorübergehenden Fehlern erneut ausgeführt werden.

Die Überwachung des Zertifikatsablaufs sollte unabhängig von der eigentlichen Erneuerungsroutine erfolgen. Ein falsch konfigurierter Timer oder ein unbemerkt fehlschlagendes Skript kann andernfalls trotzdem zu einem abgelaufenen Zertifikat führen. Eine wöchentliche Aufgabe, die die Ausgabe von openssl x509 -enddate -noout an ein Alarmierungs- oder Benachrichtigungssystem weiterleitet, kann erkennen, wenn die automatische Erneuerung nicht mehr funktioniert.

OpenSSL FAQ

Wie erzeuge ich einen CSR mit einem vorhandenen privaten Schlüssel, ohne einen neuen Schlüssel anzulegen?

Führen Sie openssl req mit -key für den vorhandenen PEM-Schlüssel und -new aus, um eine neue CSR-Datei zu erstellen:

openssl req -key existing.key -new -out request.csr

Nutzen Sie -subj, wenn interaktive Abfragen vermieden werden sollen, oder -config, wenn SAN-Werte oder andere konfigurierte Erweiterungen aufgenommen werden müssen.

Wie füge ich Subject Alternative Names beziehungsweise SANs zu einem CSR hinzu?

Definieren Sie SAN-Einträge im Abschnitt [req_ext] einer über -config eingebundenen OpenSSL-Konfigurationsdatei. Bei OpenSSL 1.1.1 oder neuer kann alternativ -addext 'subjectAltName=DNS:example.com,DNS:www.example.com' verwendet werden:

openssl req -new -key domain.key -out domain.csr -config san.cnf

Überprüfen Sie den erzeugten CSR anschließend mit openssl req -text -noout -in domain.csr.

Wie kann ich das Ablaufdatum eines SSL-Zertifikats prüfen?

Geben Sie das Feld notAfter des Zertifikats aus:

openssl x509 -enddate -noout -in domain.crt

Mit -dates werden sowohl notBefore als auch notAfter angezeigt.

Wie prüfe ich, ob ein privater Schlüssel mit einem Zertifikat übereinstimmt?

Bei RSA-Zertifikaten können die Modulus-Hashes miteinander verglichen werden:

openssl rsa -noout -modulus -in domain.key | openssl md5
openssl x509 -noout -modulus -in domain.crt | openssl md5

Wenn beide Befehle dieselbe Ausgabe liefern, gehören Zertifikat und privater Schlüssel zum selben RSA-Schlüsselpaar.

Wie dekodiere und lese ich den Inhalt eines CSRs?

Verwenden Sie req -text zusammen mit -verify, um die CSR-Struktur auszulesen und gleichzeitig die Signatur zu überprüfen:

openssl req -text -noout -verify -in domain.csr

Die dekodierten Informationen enthalten den Distinguished Name des Subjects sowie angeforderte SAN-Einträge.

Wie konvertiere ich ein PEM-Zertifikat in das PFX- oder PKCS12-Format?

Verwenden Sie pkcs12 -export und geben Sie privaten Schlüssel, Leaf-Zertifikat und optional die CA-Kette an:

openssl pkcs12 -export -inkey domain.key -in domain.crt -certfile ca-chain.pem -out domain.pfx

Ergänzen Sie -legacy, wenn ein älteres Zertifikatsimportprogramm die standardmäßigen PKCS#12-Algorithmen von OpenSSL 3 nicht unterstützt.

Was unterscheidet RSA 2048 von RSA 4096 bei privaten Schlüsseln?

RSA 4096 verwendet einen größeren Modulus als RSA 2048. Dadurch steigt der Rechenaufwand für asymmetrische Operationen während TLS-Prozessen, gleichzeitig erhöht sich die Sicherheitsreserve gegenüber klassischen Bedrohungsmodellen. RSA 2048 wird weiterhin häufig als Standard für öffentliche TLS-Zertifikate eingesetzt. RSA 4096 eignet sich insbesondere dann, wenn interne Richtlinien oder regulatorische Vorgaben ausdrücklich eine größere Schlüssellänge verlangen.

Wie teste ich mit openssl s_client eine aktive TLS-Verbindung?

Öffnen Sie eine Client-Verbindung und geben Sie die ausgehandelten TLS-Parameter mit dem folgenden Befehl aus:

openssl s_client -connect example.com:443 -servername example.com

Mit -tls1_2 beziehungsweise -tls1_3 kann der Test auf eine bestimmte TLS-Version beschränkt werden. -showcerts sorgt dafür, dass OpenSSL die vom entfernten Server bereitgestellte PEM-Zertifikatskette anzeigt.

Fazit

Dieser Leitfaden hat zentrale OpenSSL-Arbeitsabläufe für private RSA- und EC-Schlüssel, die CSR-Erstellung mit SAN-Einträgen über Konfigurationsdateien und -addext, verschiedene Verfahren für selbstsignierte Zertifikate, SAN-Unterstützung bei selbstsignierten Zertifikaten, die Untersuchung von PEM-Dateien, den Vergleich von RSA-Modulus-Werten, Ablaufprüfungen von Zertifikaten, die Verifikation gegen CA-Bundles, die Prüfung vollständiger Zertifikatsketten mit Intermediate-Zertifikaten, Live-TLS-Tests mit openssl s_client sowie Konvertierungen zwischen PEM, DER, PKCS12 und PKCS7 behandelt.

Mit diesen Techniken lassen sich private Schlüssel sicher erzeugen, CSRs entsprechend moderner Anforderungen an die Hostnamenvalidierung erstellen, Zertifikate vor der Aktivierung von HTTPS kontrollieren, das Verhalten von TLS-Handshakes an entfernten Endpunkten analysieren und Zertifikatspakete für gemischte Linux- und Windows-Umgebungen erzeugen. Dabei können auch die geänderten PKCS12-Standardeinstellungen von OpenSSL 3 berücksichtigt werden.