Wie generiert man ein selbstsigniertes Zertifikat mit OpenSSL?

Ein selbstsigniertes Zertifikat ist eines, das Sie sich selbst ausstellen, anstatt es von einer Zertifizierungsstelle zu kaufen. Browser vertrauen ihm nicht automatisch, daher hat es auf einer öffentlichen Website nichts verloren, aber es ist der schnellste Weg, um HTTPS auf einem Entwicklungsrechner, einem Staging-Server, einem internen Dashboard oder einem beliebigen Dienst einzurichten, der nie im offenen Internet steht.

Diese Anleitung zeigt Ihnen, wie Sie mit OpenSSL ein selbstsigniertes Zertifikat erstellen, unter Windows, Linux und macOS. Der Befehl ist auf allen drei Systemen derselbe. Sie erfahren außerdem, wie Sie prüfen, ob das erzeugte Zertifikat tatsächlich brauchbar ist, und wie Sie Ihrem eigenen Rechner beibringen, ihm zu vertrauen, damit die Browser-Warnungen verschwinden.

Was ein selbstsigniertes Zertifikat ist

Ein selbstsigniertes Zertifikat ist ein digitales Zertifikat, das mit seinem eigenen privaten Schlüssel signiert wurde, statt von einer vertrauenswürdigen Zertifizierungsstelle (CA). Kryptografisch gesehen ist es ein ganz normales X.509-Zertifikat: Es verschlüsselt den Datenverkehr genauso gut wie ein gekauftes Zertifikat. Was ihm fehlt, ist eine Vertrauenskette. Nichts außerhalb Ihres eigenen Rechners hat einen Grund, ihm zu glauben, weshalb Browser eine Warnung anzeigen, bis Sie ihnen etwas anderes mitteilen.

Das macht selbstsignierte Zertifikate gut geeignet für:

• Lokale Entwicklung, bei der Sie HTTPS benötigen, damit Cookies, Service Worker oder ein Payment-SDK sich so verhalten wie später in der Produktion.
• Interne Dienste wie ein Intranet-Dashboard, ein Monitoring-Panel oder eine Geräteverwaltungsoberfläche in einem privaten Netzwerk.
• Tests und Staging, wenn Sie eine TLS-Konfiguration durchspielen möchten, ohne dafür ein Zertifikat auszugeben.
• Origin-Server hinter einem Proxy, der auf der Backend-Strecke ein nicht vertrauenswürdiges Zertifikat akzeptiert, wie etwa Cloudflare im Full-Modus.

Sie sind das falsche Werkzeug für alles, was ein echter Besucher aufruft. Diesen Unterschied behandeln wir weiter unten ausführlich, im Abschnitt darüber, wann man keins verwenden sollte.

Bevor Sie beginnen: OpenSSL prüfen

Sie benötigen das OpenSSL-Kommandozeilentool. Prüfen Sie, was Sie bereits haben:

openssl version

• Linux: OpenSSL ist auf den meisten Distributionen bereits vorinstalliert. Falls nicht, lesen Sie unsere Anleitung zur Installation von OpenSSL unter Ubuntu.
• Windows: OpenSSL ist nicht enthalten. Folgen Sie unserer Anleitung zur Installation von OpenSSL unter Windows und führen Sie den Befehl dann in der Eingabeaufforderung oder PowerShell aus.
• macOS: Apple liefert LibreSSL, einen Fork von OpenSSL, als integrierten openssl-Befehl aus, weshalb hier etwas wie LibreSSL 3.3.6 statt einer OpenSSL-Version zurückgegeben wird.

Der Hauptbefehl in dieser Anleitung funktioniert sowohl unter LibreSSL 3.3.6 als auch unter aktuellem OpenSSL, sodass Mac-Nutzer das eingebaute Tool verwenden können. Wenn Sie lieber echtes OpenSSL verwenden möchten (einige der optionalen Befehle unten benötigen es), installieren Sie es mit dem Homebrew-Paketmanager und rufen Sie es über seinen vollständigen Pfad auf:

brew install openssl@3
/opt/homebrew/opt/openssl@3/bin/openssl version

Auf Intel-Macs lautet der Pfad stattdessen /usr/local/opt/openssl@3/bin/openssl. Weitere Details zum Lesen der Ausgabe finden Sie in unserer Anleitung zum Prüfen Ihrer OpenSSL-Version.

Wie man mit OpenSSL ein selbstsigniertes Zertifikat erstellt

Schritt 1: Terminal öffnen

Unter Linux drücken Sie Strg + Alt + T oder suchen Sie im Anwendungsmenü nach „Terminal“. Unter macOS öffnen Sie Programme, dann Dienstprogramme, dann Terminal, oder drücken Sie Cmd + Leertaste und tippen Sie „Terminal“. Unter Windows drücken Sie Win + R, geben cmd ein und drücken Enter.

Schritt 2: In den Ordner wechseln, in dem die Dateien liegen sollen

OpenSSL schreibt seine Ausgabe in das aktuelle Arbeitsverzeichnis, nicht in das Verzeichnis, in dem OpenSSL installiert ist. Erstellen Sie einen Ordner für dieses Zertifikat und wechseln Sie hinein, damit Schlüssel und Zertifikat an einem Ort landen, den Sie wiederfinden:

mkdir my-cert
cd my-cert

Verwenden Sie unter Windows dieselben zwei Befehle in der Eingabeaufforderung. Führen Sie die Befehle nicht aus dem OpenSSL-Programmordner heraus aus: Unter Windows ist dieses Verzeichnis oft nicht für normale Benutzer beschreibbar, und wenn Sie Ihre Schlüssel mit den ausführbaren Dateien vermischen, gehen sie leicht verloren.

Schritt 3: Den Zertifikatsbefehl ausführen

Dieser einzelne Befehl erzeugt den privaten Schlüssel und das selbstsignierte Zertifikat gemeinsam. Ersetzen Sie example.com und www.example.com durch die Namen, unter denen Ihr Dienst tatsächlich erreichbar sein wird:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

Belassen Sie ihn in einer einzigen Zeile. Die Eingabeaufforderung und Unix-Shells verwenden unterschiedliche Zeichen zur Zeilenfortsetzung, und eine einzelne Zeile funktioniert überall. Verwenden Sie aus demselben Grund doppelte Anführungszeichen, nicht einfache: Die Eingabeaufforderung behandelt einfache Anführungszeichen nicht als Zitatzeichen.

Hier ist, was jeder Teil bewirkt:

• req -x509: erzeugt ein fertiges, signiertes Zertifikat anstelle einer Zertifikatsanforderung (CSR).
• -newkey rsa:2048: erzeugt im selben Befehl einen neuen 2048-Bit-RSA-Privatschlüssel. 2048 Bit ist derzeit das Minimum und eine sinnvolle Standardeinstellung. Verwenden Sie rsa:4096, wenn Ihre Richtlinie einen größeren Schlüssel verlangt, auf Kosten langsamerer Handshakes.
• -keyout private.key: der Dateiname für den privaten Schlüssel.
• -out certificate.crt: der Dateiname für das Zertifikat.
• -days 365: wie lange das Zertifikat gültig bleibt. Lesen Sie den Abschnitt zur Gültigkeit unten, bevor Sie diesen Wert ändern.
• -nodes: lässt den privaten Schlüssel unverschlüsselt, damit Ihr Webserver starten kann, ohne dass jemand eine Passphrase eingeben muss.
• -addext „subjectAltName=…“: die Liste der Hostnamen, für die das Zertifikat gültig ist. Ohne diese Angabe passt das Zertifikat auf nichts.
• -addext „basicConstraints=critical,CA:FALSE“: markiert das Zertifikat als Endentitäts- (Server-) Zertifikat und nicht als Zertifizierungsstelle.
• -addext „extendedKeyUsage=serverAuth“: gibt an, dass das Zertifikat zur Authentifizierung eines TLS-Servers dient. Apple-Plattformen behandeln dies als zwingend erforderlich.

Warum die drei -addext-Optionen wichtig sind

Diese drei Optionen machen den Unterschied zwischen einem funktionierenden Zertifikat und einem, das Clients rundweg ablehnen. Es lohnt sich, sie zu verstehen, denn ein ohne sie erstelltes selbstsigniertes Zertifikat scheitert auf drei Arten, die schwer zu diagnostizieren sind.

Subject Alternative Name ist der Ort, an dem Hostnamen leben. Browser lesen seit Jahren nicht mehr das Common-Name-Feld und gleichen den Hostnamen nur noch mit der Subject-Alternative-Name-Erweiterung (SAN) ab. Ein Zertifikat ohne SAN passt auf keine Website, egal wie korrekt der Common Name aussieht. Listen Sie jeden Namen auf, den Sie verwenden werden, getrennt durch Kommas. Für einen lokalen Dienst können Sie auch eine IP-Adresse angeben:

-addext "subjectAltName=DNS:localhost,DNS:dev.example.com,IP:127.0.0.1"

Ohne CA:FALSE erstellt OpenSSL ein CA-Zertifikat für Sie. Wenn req -x509 mit seinen Standardwerten belassen wird, setzt es basicConstraints auf critical, CA:TRUE, was eine Zertifizierungsstelle beschreibt, keinen Webserver. Chrome und Safari akzeptieren das bei einem Serverzertifikat. Firefox tut das nicht und bricht mit MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY ab. Sie können zwar auf „Erweitert“ klicken und eine Ausnahme hinzufügen, aber damit umgehen Sie ein Zertifikat, von dem Sie bereits wissen, dass es fehlerhaft ist, und andere Clients ziehen die Grenze an anderer Stelle. Die Angabe von basicConstraints=critical,CA:FALSE vermeidet die Situation von vornherein.

Der LibreSSL-Build, den macOS mitliefert, verhält sich hier anders: Ohne explizite Angaben schreibt er ein X.509-Version-1-Zertifikat ganz ohne Erweiterungen, sodass Sie zwar kein CA:TRUE-Problem haben, aber auch keinen Subject Alternative Name. Wenn Sie die Erweiterungen explizit angeben, erhalten Sie mit beiden Tools dasselbe, korrekte Zertifikat.

Ohne serverAuth lehnen Apple-Plattformen das Zertifikat ab. Apples veröffentlichte Anforderungen für vertrauenswürdige Zertifikate besagen, dass ein TLS-Serverzertifikat eine ExtendedKeyUsage-Erweiterung mit der id-kp-serverAuth-OID enthalten muss. Ein Zertifikat ohne diese Angabe scheitert unter macOS an der Zertifikatsprüfung der TLS-Richtlinie mit der Meldung „Invalid Extended Key Usage for policy“, selbst wenn das Zertifikat als eigener Vertrauensanker dient. Firefox und Chrome sind nachsichtiger und behandeln ein fehlendes ExtendedKeyUsage bei einem Serverzertifikat als zulässig, weshalb dieser Punkt leicht übersehen wird, bis ein Mac oder ein iPhone das Gerät ist, das die Verbindung verweigert. Das Hinzufügen von extendedKeyUsage=serverAuth kostet auf den anderen Plattformen nichts und entspricht dem, was eine öffentliche CA ohnehin ausstellen würde.

Schritt 4: Die Zertifikatsdetails ausfüllen

OpenSSL fragt nach den Feldern, die den Distinguished Name bilden. Drücken Sie Enter, um eines davon zu überspringen, füllen Sie aber mindestens eines aus, und zwar den Common Name. Der LibreSSL-Build unter macOS bricht mit „error, no objects specified in config file“ ab und schreibt nichts, wenn Sie alle Felder leer lassen. Die folgenden Werte sind Beispiele, verwenden Sie also Ihre eigenen:

• Country Name: der zweibuchstabige Ländercode, zum Beispiel US.
• State or Province Name: ausgeschrieben, zum Beispiel California.
• Locality Name: Ihre Stadt, zum Beispiel San Jose.
• Organization Name: der Name Ihres Unternehmens oder Projekts, zum Beispiel Example Inc.
• Organizational Unit Name: das zuständige Team, zum Beispiel IT.
• Common Name: der Haupt-Hostname, zum Beispiel example.com. Verwenden Sie denselben Namen, den Sie zuerst in der Subject-Alternative-Name-Liste angegeben haben.
• Email Address: eine Kontaktadresse, zum Beispiel [email protected]. Optional.

Nur der Common Name spielt hier wirklich eine Rolle, und auch nur als Bezeichnung: Der Abgleich des Hostnamens erfolgt über den Subject Alternative Name, den Sie bereits in der Befehlszeile festgelegt haben. Alles Übrige ist rein beschreibend.

Sie werden bemerken, dass der Befehl nie nach einem Challenge Password fragt. Diese Abfrage gehört zu Zertifikatsanforderungen (CSRs) und ist ein Relikt aus früheren Zeiten, das CAs in der Regel ignorieren oder ablehnen. Da dieser Befehl ein fertiges Zertifikat statt einer Anforderung erzeugt, erscheint diese Abfrage überhaupt nicht.

Schritt 5: Das Zertifikat vor der Nutzung prüfen

Überspringen Sie dies nicht. Ein selbstsigniertes Zertifikat kann erfolgreich erzeugt werden und trotzdem unbrauchbar sein, und der Fehler zeigt sich erst später als Browserfehler. Lesen Sie das Zertifikat zur Kontrolle wieder ein:

openssl x509 -in certificate.crt -noout -text

Im Block X509v3 extensions suchen Sie genau nach drei Dingen:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com
X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Extended Key Usage:
    TLS Web Server Authentication

Fehlt die Zeile Subject Alternative Name, passt das Zertifikat auf keinen Hostnamen. Steht bei Basic Constraints CA:TRUE, bricht Firefox ab. Fehlt die Zeile Extended Key Usage, lehnen Apple-Plattformen das Zertifikat ab. In jedem dieser Fälle löschen Sie die beiden Dateien und führen den Befehl erneut aus, diesmal mit allen drei -addext-Optionen.

Unter OpenSSL 3.x können Sie stattdessen gezielt nur diese Erweiterungen abfragen, ohne das ganze Zertifikat zu lesen:

openssl x509 -in certificate.crt -noout -ext subjectAltName,basicConstraints,extendedKeyUsage

Die Option -ext gibt es im LibreSSL-Build, den macOS mitliefert, nicht, dort erscheint die Meldung „unknown option -ext“. Verwenden Sie auf einem unveränderten Mac die oben gezeigte -text-Variante.

Um zu bestätigen, dass Zertifikat und Schlüssel zusammengehören, vergleichen Sie deren Modulus. Die beiden Befehle müssen denselben Hash ausgeben:

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

Das Zertifikat selbst ist eine Textdatei. Öffnet man sie in einem Texteditor, sieht man einen Base64-Block zwischen den Zeilen BEGIN CERTIFICATE und END CERTIFICATE, den Sie in Kontrollzentren einfügen können, die nach dem Zertifikat statt einem Datei-Upload fragen.

Varianten des Befehls

Ohne Eingabeaufforderungen erzeugen

Für Skripte und CI-Pipelines geben Sie den Distinguished Name mit -subj an, und der Befehl läuft unbeaufsichtigt durch:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -subj "/C=US/ST=California/L=San Jose/O=Example Inc/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

Einen EC-Schlüssel statt RSA verwenden

Elliptic-Curve-Schlüssel sind bei gleicher Sicherheitsstärke kleiner und schneller als RSA-Schlüssel, und jeder aktuelle Browser unterstützt sie. P-256 ist die Standardwahl:

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

Das Ergebnis wird mit ecdsa-with-SHA256 signiert. Bleiben Sie bei RSA, wenn Sie alte eingebettete Clients oder ältere Java-Versionen unterstützen müssen, denen manchmal die EC-Unterstützung fehlt.

Verwenden Sie hierfür echtes OpenSSL. Der LibreSSL-Build unter macOS akzeptiert den Befehl zwar, schreibt die Kurve aber als vollständigen Satz expliziter Parameter in das Zertifikat statt als den Standard-Bezeichner P-256. RFC 5480 legt fest, dass die explizite Form in Zertifikaten nicht verwendet werden darf, und macOS selbst lehnt ein so kodiertes Zertifikat ab.

Prüfen Sie das Ergebnis mit openssl x509 -in certificate.crt -noout -text: Gesucht ist eine Zeile mit „ASN1 OID: prime256v1“, nicht ein Block mit Prime, A, B und Generator. Verwenden Sie auf einem unveränderten Mac entweder den RSA-Befehl von oben oder installieren Sie zuerst OpenSSL über Homebrew.

-nodes oder -noenc?

Beide Optionen bewirken dasselbe: Sie verhindern, dass OpenSSL den privaten Schlüssel mit einer Passphrase verschlüsselt. OpenSSL 3.x hat -noenc als klareren Namen eingeführt und führt -nodes als veraltet, akzeptiert es aber weiterhin. LibreSSL, das macOS mitliefert, kennt -noenc überhaupt nicht und bricht mit einem Fehler ab.

Diese Anleitung verwendet -nodes, weil dies die Option ist, die auf jedem Build funktioniert, dem Sie wahrscheinlich begegnen, einschließlich eines unveränderten Macs. Wenn Sie OpenSSL 3.x verwenden und die veraltete Schreibweise vermeiden möchten, tauschen Sie sie gegen -noenc aus. Sonst ändert sich nichts.

Lassen Sie die Option ganz weg, verschlüsselt OpenSSL den Schlüssel mit einer von Ihnen gewählten Passphrase, und Ihr Webserver fragt dann bei jedem Neustart danach. Das ist bei einem Entwicklungszertifikat selten das, was Sie wollen.

Ihrem Rechner das Zertifikat vertrauen lassen

Ein korrektes selbstsigniertes Zertifikat erzeugt trotzdem eine Browserwarnung, weil niemandem gesagt wurde, ihm zu vertrauen. Es dem lokalen Trust Store hinzuzufügen schaltet die Warnung ab, und genau das ist meist der eigentliche Zweck, ein solches Zertifikat überhaupt zu erstellen.

Tun Sie das nur auf Rechnern, die Sie selbst verwalten, und nur für Zertifikate, die Sie selbst erzeugt haben. Ein vertrauenswürdiges Zertifikat wird für jede darin genannte Website als vertrauenswürdig eingestuft, behandeln Sie den privaten Schlüssel entsprechend und geben Sie ihn niemals weiter.

macOS-Schlüsselbund

Fügen Sie das Zertifikat dem System-Schlüsselbund hinzu und markieren Sie es als vertrauenswürdig für TLS. Sie werden nach Ihrem Administratorpasswort gefragt:

sudo security add-trusted-cert -d -r trustRoot -p ssl -k /Library/Keychains/System.keychain certificate.crt

Der Teil -p ssl beschränkt das Vertrauen auf TLS-Verbindungen. Lassen Sie ihn weg, wird das Zertifikat für jeden Zweck vertraut, den macOS kennt, einschließlich Code-Signierung, was weit mehr ist, als ein Entwicklungszertifikat benötigt.

Um dies stattdessen über die Benutzeroberfläche zu erledigen, doppelklicken Sie auf die Zertifikatsdatei, um Schlüsselbundverwaltung zu öffnen, suchen Sie den Eintrag im System-Schlüsselbund, öffnen Sie ihn, klappen Sie Vertrauen auf und stellen Sie Bei Verwendung dieses Zertifikats auf Immer vertrauen. Um dies später rückgängig zu machen, löschen Sie den Eintrag aus der Schlüsselbundverwaltung.

Windows-Zertifikatsspeicher

Öffnen Sie die Eingabeaufforderung als Administrator (drücken Sie Win + R, geben Sie cmd ein, dann drücken Sie Strg + Umschalt + Enter) und fügen Sie das Zertifikat dem Speicher der vertrauenswürdigen Stammzertifizierungsstellen hinzu:

certutil -addstore -f "Root" certificate.crt

Alternativ doppelklicken Sie auf die Zertifikatsdatei, wählen Zertifikat installieren, wählen Lokaler Computer, dann Alle Zertifikate in folgendem Speicher speichern, und navigieren zu Vertrauenswürdige Stammzertifizierungsstellen. Um es später zu entfernen, öffnen Sie certmgr.msc und löschen Sie den Eintrag aus diesem Speicher.

Linux ca-certificates

Unter Debian und Ubuntu kopieren Sie das Zertifikat in das lokale Anker-Verzeichnis und erstellen das Bundle neu. Die Datei muss die Endung .crt behalten, sonst ignoriert das Update-Tool sie:

sudo cp certificate.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

Unter RHEL, CentOS, AlmaLinux, Rocky und Fedora unterscheiden sich die Pfade:

sudo cp certificate.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

Die Firefox-Ausnahme

Firefox führt einen eigenen Trust Store, statt den des Betriebssystems zu verwenden. Unter Windows und macOS liest er standardmäßig aber auch Stammzertifikate, die dem OS-Store hinzugefügt wurden, sodass die obigen Schritte dies normalerweise abdecken. Unter Linux ist das nicht der Fall, weshalb das Zertifikat direkt in Firefox importiert werden muss: öffnen Sie Einstellungen, dann Datenschutz & Sicherheit, scrollen Sie zu Zertifikate, klicken Sie auf Zertifikate anzeigen, öffnen Sie den Reiter Zertifizierungsstellen und nutzen Sie Importieren.

Starten Sie den Browser nach jeder dieser Änderungen neu. Browser speichern Zertifikatsentscheidungen zwischen, und eine veraltete Sitzung ist ein häufiger Grund, warum die Warnung nach einem korrekten Import scheinbar bestehen bleibt.

Wann man kein selbstsigniertes Zertifikat verwenden sollte

Verwenden Sie es niemals auf einer Website, die die Öffentlichkeit besucht. Jeder Besucher erhält eine ganzseitige Sicherheitswarnung, und diejenigen, die trotzdem fortfahren, wurden darauf trainiert, genau die Warnung wegzuklicken, die sie vor einem echten Angriff schützt. Ein Besucher hat auch keine Möglichkeit, Ihr selbstsigniertes Zertifikat von dem eines Angreifers zu unterscheiden, was genau der Grund ist, warum Browser ihnen misstrauen. Wir gehen in unserem Artikel über die Gefahren selbstsignierter Zertifikate näher darauf ein.

Selbstsignierte Zertifikate erfüllen auch praktische Anforderungen über die Browserwarnung hinaus nicht. Zahlungsdienstleister, App Stores, mobile Apps mit Certificate Pinning und die meisten Compliance-Vorgaben verlangen ein Zertifikat einer anerkannten CA. Verwenden Sie für alles, was öffentlich zugänglich ist, ein Zertifikat, das von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde, das Sie mit einem CSR anfordern und vor der Ausstellung validieren lassen. Sobald es live ist, bestätigen Sie die Installation mit unserem SSL Checker.