Self-signed Zertifikat erstellen - OpenSSL & SAN Guide

Ein selbstsigniertes Zertifikat ist dann sinnvoll, wenn ein interner Dienst, ein Testsystem oder eine lokale Entwicklungsumgebung per HTTPS erreichbar sein soll, ohne dass sofort eine öffentliche CA ins Spiel kommt. Der praktische Weg hinter dem Schritt create self-signed certificate ist dabei überschaubar: Schlüssel erzeugen, SAN korrekt setzen, Zertifikat ausstellen, prüfen und im richtigen Trust Store einordnen. Ich gehe hier genau diese Schritte durch und zeige, wann diese Lösung genügt und wann eine private CA oder ein öffentliches Zertifikat die bessere Wahl ist.

Wann ein selbstsigniertes Zertifikat die richtige Wahl ist

Ich setze ein selbstsigniertes Zertifikat nur dann ein, wenn der Vertrauenskreis klein und kontrollierbar bleibt. Das ist typisch für Entwicklungsmaschinen, Staging-Umgebungen, interne Admin-Oberflächen, Appliances im Labor oder kurzfristige PoCs. Dort geht es meist nicht darum, eine öffentliche Identität zu beweisen, sondern verschlüsselte Verbindungen schnell und nachvollziehbar bereitzustellen.

Wichtig ist die Grenze: Ein selbstsigniertes Zertifikat beweist nicht gegenüber fremden Clients, dass der Gegenüber wirklich der richtige Server ist. Das Vertrauen entsteht erst, wenn du das Zertifikat oder die zugehörige Root-CA bewusst in einen Trust Store übernimmst. Genau deshalb ist diese Lösung für das öffentliche Web ungeeignet, intern aber oft absolut ausreichend. Damit ist auch klar, warum SAN und Trust Store die eigentlichen Stolpersteine sind.

Gut geeignet für

• Lokale Entwicklung auf localhost oder einer internen Test-IP
• Interne Admin-UIs ohne externe Nutzer
• Labore, Demo-Systeme und Prototypen
• Temporäre Umgebungen, in denen Zeit wichtiger ist als formale Ausstellung

Eher ungeeignet für

• Öffentlich erreichbare Websites und APIs
• Services mit wechselnden, unbekannten Clients
• Umgebungen, in denen du kein Vertrauen auf den Endgeräten verteilen kannst
• Langfristige Setups, bei denen du später keine manuelle Pflege willst

Genau an dieser Stelle entscheidet sich, ob du direkt ein Einzelzertifikat baust oder später auf eine private CA umsteigen solltest.

Welche Voraussetzungen heute entscheidend sind

Wer ein Zertifikat sauber erzeugen will, sollte nicht nur den Befehl kennen, sondern auch die Felder verstehen, die wirklich zählen. In der Praxis achte ich auf fünf Dinge: den Schlüsseltyp, die SAN-Einträge, den Verwendungszweck, die Rolle des Zertifikats und die Laufzeit. Der Common Name allein ist dafür zu schwach, selbst wenn einzelne Werkzeuge ihn noch mitauswerten.

Für gemischte Umgebungen bleibe ich meist bei RSA 2048 oder 3072; für moderne Stacks ist ECDSA ebenfalls eine gute Option. Mit diesen Vorgaben im Kopf wird der eigentliche OpenSSL-Befehl deutlich einfacher.

So erzeugst du das Zertifikat mit OpenSSL

Für den schnellen Start reicht ein einziger Befehl. Ich verwende dabei bewusst -noenc statt -nodes, weil die ältere Variante in OpenSSL 3 als veraltet gilt. Für lokale Tests ist ein unverschlüsselter Schlüssel oft praktikabel, solange die Dateirechte stimmen und die Datei nicht versehentlich geteilt wird.

Der schnelle Weg für Entwicklung und Tests

openssl req -x509 -newkey rsa:2048 -sha256 -days 365 -noenc \
  -keyout server.key \
  -out server.crt \
  -subj "/C=DE/O=Interne IT/CN=app.intern.test" \
  -addext "subjectAltName = DNS:app.intern.test,DNS:localhost,IP:127.0.0.1,IP:::1" \
  -addext "keyUsage = digitalSignature,keyEncipherment" \
  -addext "extendedKeyUsage = serverAuth"

Dieser Befehl erzeugt Schlüssel und Zertifikat in einem Rutsch. Der wichtigste Teil ist der SAN-Block: Dort stehen alle Namen und Adressen, mit denen der Dienst später aufgerufen wird. Wenn du den Dienst sowohl per DNS als auch per IP testest, müssen beide Varianten drinstehen, sonst bekommst du später unnötige TLS-Fehler.

Lesen Sie auch: For-Schleife in CMD - Effiziente Batch-Automatisierung meistern

Die saubere Variante mit Konfigurationsdatei

Sobald mehr als ein Hostname, eine IPv6-Adresse oder ein wiederverwendbares Profil im Spiel ist, bevorzuge ich eine Konfigurationsdatei. Das ist leichter zu prüfen, besser versionierbar und weniger fehleranfällig als ein langer Einzeiler.

[ req ]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
x509_extensions = v3_server

[ dn ]
C = DE
O = Interne IT
CN = app.intern.test

[ v3_server ]
basicConstraints = critical,CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = app.intern.test
DNS.2 = localhost
IP.1 = 127.0.0.1
IP.2 = ::1

openssl req -x509 -newkey rsa:2048 -days 365 -noenc \
  -keyout server.key \
  -out server.crt \
  -config openssl.cnf

Die Konfigurationsvariante ist mein Standard, sobald ein Zertifikat nicht mehr nur für einen einzelnen lokalen Test gedacht ist. Danach lohnt sich der Blick auf die Prüfung, weil ein Zertifikat erst im Zusammenspiel mit Server und Trust Store auffällt.

So prüfst du, ob das Zertifikat technisch sauber ist

Nach der Erstellung prüfe ich immer zuerst den Inhalt des Zertifikats selbst. Damit stelle ich sicher, dass SAN, Laufzeit, Verwendungszweck und Schlüsselparameter so aussehen, wie ich sie geplant habe. Ein Zertifikat kann nämlich kryptografisch korrekt sein und trotzdem im Browser scheitern, wenn der Hostname nicht passt oder der Trust Store fehlt.

• openssl x509 -in server.crt -noout -text zeigt dir SAN, EKU, Key Usage, Aussteller und Gültigkeit.
• openssl verify -CAfile server.crt server.crt testet, ob das selbstsignierte Zertifikat als eigene Vertrauensbasis konsistent ist.
• openssl s_client -connect localhost:443 -servername app.intern.test prüft den realen TLS-Handshake gegen den Server.

Wenn der Browser trotzdem meckert, ist das meist kein Kryptografieproblem, sondern ein Vertrauens- oder Namensproblem. Ein Fehler wie NET::ERR_CERT_COMMON_NAME_INVALID deutet oft auf fehlende SANs oder einen falschen Aufrufnamen hin; eine Meldung über den untrusted issuer bedeutet in der Regel, dass das Zertifikat oder die lokale CA nicht im passenden Trust Store liegt. Genau deshalb vergleiche ich anschließend die drei gängigen Wege nebeneinander.

Self-signed, eigene CA oder öffentliches Zertifikat

Die eigentliche Architekturfrage ist fast immer dieselbe: Willst du nur ein einzelnes System absichern, mehrere interne Dienste bedienen oder für das öffentliche Web arbeiten? Ich trenne diese Fälle bewusst, weil sonst schnell eine Lösung gewählt wird, die später unnötig viel Pflege erzeugt.

Für lokale Entwicklung ist mkcert oft die pragmatische Abkürzung, weil es eine lokale CA anlegt und die passenden Entwicklungszertifikate daraus ausstellt. Der Vorteil ist nicht das Zertifikat selbst, sondern die Zeitersparnis bei der Vertrauensverteilung. Was in der Praxis am häufigsten schiefgeht, sind aber nicht die Befehle selbst, sondern die kleinen Details drumherum.

Typische Fehler, die ich immer wieder korrigiere

• Nur CN gesetzt, kein SAN - der Dienst sieht auf dem Papier korrekt aus, scheitert aber an Browsern und modernen Clients.
• Falscher Hostname - das Zertifikat enthält app.intern.test, aber der Browser ruft server01 oder eine andere IP auf.
• Serverzertifikat als CA markiert - CA:TRUE gehört in eine Root- oder Intermediate-CA, nicht in ein normales End-Entity-Zertifikat.
• Privater Schlüssel zu offen abgelegt - im Repository, in Backups ohne Schutz oder mit zu breiten Dateirechten.
• Trust Store an der falschen Stelle - das System vertraut dem Zertifikat, der verwendete Browser oder Container aber nicht.
• Kein Plan für Erneuerung - interne Zertifikate laufen ab und werden dann zum unnötigen Störfaktor.

Wenn man diese Fehler vermeidet, ist die Lösung für interne Systeme erstaunlich stabil. Aus meiner Sicht läuft die Praxis deshalb auf eine klare Dreiteilung hinaus: lokal schnell, intern sauber verwaltet, öffentlich vollständig automatisiert.

Was ich für interne SSL-Setups praktisch empfehle

• Für einen einzelnen Testrechner genügt ein selbstsigniertes Serverzertifikat mit sauberem SAN.
• Für mehrere interne Systeme ist eine private CA meist die bessere Struktur, weil du Vertrauen zentral verteilst.
• Für alles, was nach außen sichtbar ist, nehme ich ein öffentliches Zertifikat mit automatischer Erneuerung.
• Den Schlüssel halte ich immer getrennt vom Code und so restriktiv wie möglich.
• Ich teste grundsätzlich mit dem exakten DNS-Namen und der exakten IP, die später im Betrieb verwendet werden.

Mein Standard ist deshalb simpel: SAN immer setzen, Schlüssel knapp halten, Trust-Store-Fragen früh klären und auf Dauer lieber mit einer privaten CA arbeiten, sobald mehr als ein Client beteiligt ist. So bleibt HTTPS intern kontrollierbar, ohne dass du später jede Maschine einzeln nachpflegen musst.