OpenSSL ist das Schweizer Taschenmesser der SSL/TLS-Zertifikatsverwaltung. Ob Sie einen privaten Schlüssel generieren, ein bald ablaufendes Zertifikat inspizieren, eine Zertifizierungsstelle für interne Dienste aufbauen oder einen TLS-Handshake-Fehler debuggen müssen — die openssl-CLI bewältigt alles. Dieser Leitfaden führt Sie durch alle wesentlichen Zertifikatsoperationen — von der Schlüsselgenerierung bis zur Kettenvalidierung — mit praxistauglichen Befehlen, die Sie sofort auf jedem Linux-Server ausführen können.

Voraussetzungen

  • OpenSSL installiert (Version 1.1.x oder 3.x — prüfen Sie mit openssl version)
  • Grundlegende Kenntnisse der Linux-Kommandozeile
  • Root- oder sudo-Zugriff für systemweite Zertifikatsinstallation
  • Verständnis von SSL/TLS-Zertifikaten (öffentliche/private Schlüsselpaare, CAs, Vertrauensketten)

Schlüsselgenerierung und Certificate Signing Requests

Jeder Zertifikatslebenszyklus beginnt mit einem privaten Schlüssel. OpenSSL unterstützt RSA, ECDSA und Ed25519. RSA 4096 Bit und ECDSA P-256 sind die häufigsten Produktionsentscheidungen.

RSA-Privatschlüssel generieren:

openssl genrsa -out key.pem 4096

ECDSA-Schlüssel generieren (schneller, kleiner, gleich sicher):

openssl ecparam -genkey -name prime256v1 | openssl ec -out ec-key.pem

Certificate Signing Request (CSR) erstellen:

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

Sie werden aufgefordert, die Distinguished-Name-Felder (DN) auszufüllen. Das wichtigste Feld ist Common Name (CN) — es muss Ihrem Domainnamen entsprechen. Für modernes TLS sind Subject Alternative Names (SANs) erforderlich. Nutzen Sie eine Konfigurationsdatei:

cat > san.conf <<EOF
[req]
req_extensions = v3_req
distinguished_name = dn
[dn]
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com
EOF

openssl req -new -key key.pem -out request.csr -config san.conf

CSR vor der Einreichung prüfen:

openssl req -text -noout -in request.csr

Selbstsignierte Zertifikate erstellen

Selbstsignierte Zertifikate sind ideal für interne Dienste, Entwicklungsumgebungen und private APIs, bei denen eine öffentliche CA nicht notwendig ist.

Selbstsigniertes Zertifikat mit einem Befehl erstellen:

openssl req -x509 -newkey rsa:4096 \
  -keyout key.pem -out cert.pem \
  -sha256 -days 365 -nodes \
  -subj "/CN=example.com/O=MyOrg/C=US"

Das Flag -nodes überspringt die Passphrasen-Verschlüsselung des privaten Schlüssels. Entfernen Sie es für offline gespeicherte Schlüssel.

Selbstsigniert mit SANs (für moderne Browser erforderlich):

openssl req -x509 -newkey rsa:4096 \
  -keyout key.pem -out cert.pem \
  -sha256 -days 365 -nodes \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

Interne Zertifizierungsstelle aufbauen

Eine interne CA ermöglicht es Ihnen, vertrauenswürdige Zertifikate für alle Dienste in Ihrer Organisation auszustellen, ohne auf eine öffentliche CA angewiesen zu sein.

CA-Schlüssel und selbstsigniertes Root-Zertifikat erstellen:

openssl genrsa -aes256 -out ca-key.pem 4096
openssl req -new -x509 -days 3650 \
  -key ca-key.pem -out ca-cert.pem \
  -subj "/CN=My Internal CA/O=MyOrg/C=US"

Server-CSR mit der CA signieren:

openssl x509 -req -days 365 \
  -in request.csr \
  -CA ca-cert.pem -CAkey ca-key.pem \
  -CAcreateserial -out server-cert.pem \
  -extfile san.conf -extensions v3_req

Zertifikate prüfen und validieren

Lokales Zertifikat lesen:

openssl x509 -text -noout -in cert.pem

Nur das Ablaufdatum prüfen:

openssl x509 -enddate -noout -in cert.pem

Zertifikat eines Remote-Servers inspizieren:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -text -noout

Übereinstimmung von Zertifikat und privatem Schlüssel prüfen:

openssl rsa  -noout -modulus -in key.pem  | md5sum
openssl x509 -noout -modulus -in cert.pem | md5sum

Vergleich

MerkmalOpenSSL CLIcfssleasy-rsacertbot
Selbstsignierte ZertifikateJaJaJaNein
Interne CAJaJaJaNein
Öffentliche CA-IntegrationNeinNeinNeinJa (Let’s Encrypt)
SAN-UnterstützungJa (Config-Datei)JaJaJa
PKCS#12-ExportJaTeilweiseNeinJa
LernkurveMittelNiedrigNiedrigSehr niedrig

Praxisbeispiel

Sie haben einen Nginx-Produktionsserver, der SSL-Handshake-Fehler wirft. Nutzer melden “NET::ERR_CERT_COMMON_NAME_INVALID” in Chrome. Hier ist der Diagnose-Workflow:

# Schritt 1: prüfen, welches Zertifikat der Server ausliefert
echo | openssl s_client -connect myserver.com:443 -servername myserver.com 2>/dev/null \
  | openssl x509 -text -noout | grep -A3 "Subject Alternative Name"

# Schritt 2: falls keine SANs gelistet, mit dem san.conf-Ansatz neu generieren

# Schritt 3: Schlüssel/Zertifikat-Übereinstimmung nach Neugenerierung prüfen
openssl rsa  -noout -modulus -in /etc/nginx/ssl/key.pem  | md5sum
openssl x509 -noout -modulus -in /etc/nginx/ssl/cert.pem | md5sum

# Schritt 4: vollständigen Handshake testen
openssl s_client -connect myserver.com:443 -servername myserver.com

Stolperfallen und Sonderfälle

SANs sind seit 2017 Pflicht. Chrome 58 hat die Unterstützung für CN-only-Zertifikate eingestellt. Fügen Sie immer subjectAltName hinzu, auch bei Single-Domain-Zertifikaten.

Dateiberechtigungen des Schlüssels sind wichtig. Der private Schlüssel darf nur vom benötigten Prozess gelesen werden: chmod 600 key.pem. Nginx und Apache verweigern den Start, wenn der Schlüssel für alle lesbar ist.

Passphrasen-geschützte Schlüssel blockieren automatisierte Neustarts. Verwenden Sie -nodes beim Generieren von Schlüsseln für Webserver.

Die Reihenfolge der Zertifikatskette ist wichtig. Nginx und Apache erwarten zuerst das Server-Zertifikat, gefolgt von Zwischenzertifikaten, in derselben PEM-Datei.

Zeitabweichungen brechen die Validierung. Wenn die Serveruhr um mehr als ein paar Minuten abweicht, schlägt openssl verify mit “certificate not yet valid” fehl.

Export in PKCS#12-Format für Windows/Java:

openssl pkcs12 -export \
  -out bundle.p12 \
  -inkey key.pem \
  -in cert.pem \
  -certfile ca-cert.pem

Fehlerbehebung

“verify error:num=20:unable to get local issuer certificate” — Das CA-Zertifikat ist nicht in Ihrem Vertrauensspeicher. Übergeben Sie es explizit: openssl verify -CAfile ca-cert.pem cert.pem.

“private key does not match the certificate public key” — Die Modulus-Hashes stimmen nicht überein. Sie haben den Schlüssel ohne das Zertifikat neu generiert oder die Dateien vertauscht.

“no shared cipher” — Client und Server können sich nicht auf eine Cipher-Suite einigen. Prüfen Sie die SSL-Konfiguration des Servers.

“certificate has expired” — Prüfen Sie mit openssl x509 -enddate -noout -in cert.pem und erneuern Sie mit demselben CSR.

Zusammenfassung

  • Generieren Sie RSA-4096- oder ECDSA-P-256-Schlüssel mit openssl genrsa oder openssl ecparam
  • Fügen Sie immer Subject Alternative Names hinzu — CN-only-Zertifikate werden von modernen Browsern abgelehnt
  • Verwenden Sie eine Konfigurationsdatei mit Abschnitt [alt_names], um SANs zu CSRs und selbstsignierten Zertifikaten hinzuzufügen
  • Inspizieren Sie jedes Zertifikat mit openssl x509 -text -noout -in cert.pem
  • Prüfen Sie die Schlüssel/Zertifikat-Übereinstimmung durch Vergleich der MD5-Modulus-Hashes
  • Bauen Sie eine interne CA für Kubernetes, VPN und Microservices ohne externe Abhängigkeiten
  • Exportieren Sie ins PKCS#12-Format für Java-Keystores und Windows-Zertifikatspeicher
  • Bewahren Sie CA-Privatschlüssel verschlüsselt, offline und mit separaten Backups auf

Verwandte Artikel