Apache selbstsigniertes Zertifikat - So geht's richtig!

Ein apache self signed certificate ist vor allem dann sinnvoll, wenn ich eine HTTPS-Umgebung schnell für Tests, interne Dienste oder eine Laborinstallation aufsetzen will. Entscheidend ist dabei nicht nur das Erzeugen des Zertifikats, sondern auch die saubere Apache-Konfiguration, der Umgang mit Hostnamen im subjectAltName und die Frage, wann ein selbstsigniertes Zertifikat eben nicht mehr reicht. Genau darum geht es hier: vom Erstellen über das Einbinden bis zu den typischen Stolperfallen.

Wann ein selbstsigniertes Zertifikat die richtige Wahl ist

Ich setze auf ein selbstsigniertes Zertifikat, wenn ich schnell ein verschlüsseltes Ziel brauche, aber noch keine Vertrauenskette aufbauen will oder kann. Das passt gut für lokale Entwicklung, interne Admin-Oberflächen, Testserver in einem abgeschotteten Netz oder temporäre Wartungsumgebungen. Für öffentliche Websites ist das die falsche Baustelle, weil der Browser dem Zertifikat ohne zusätzliche Vertrauensebene nicht automatisch glaubt.

Genau an dieser Stelle entscheidet sich oft der Aufwand für die nächsten Monate. Wenn mehrere Benutzer oder Geräte zugreifen, ist eine interne CA meist der bessere Mittelweg; sobald der Server öffentlich erreichbar ist, sollte die Lösung aus der CA-Welt kommen. Daraus folgt direkt die praktische Frage, wie man das Zertifikat korrekt erzeugt, ohne sich später an Hostnamen oder Browserfehlern zu verheddern.

Ein Zertifikat mit OpenSSL erzeugen, das zu Apache passt

Für Apache erzeuge ich das Zertifikat in der Regel mit OpenSSL, weil das Werkzeug auf fast jedem Server verfügbar ist und die nötigen X.509-Attribute direkt setzen kann. Der wichtigste Punkt ist heute der Subject Alternative Name: Dort sollten die Hostnamen stehen, die der Browser später auch wirklich aufruft. Der Common Name allein ist dafür in der Praxis zu schwach.

Schnellvariante für Testsysteme

Diese Variante ist ideal, wenn ich in wenigen Sekunden eine lauffähige Kombination aus Schlüssel und Zertifikat brauche. Der private Schlüssel bleibt dabei unverschlüsselt, was für lokale Tests praktisch ist; produktiv würde ich das nur mit Bedacht einsetzen.

openssl req -x509 -newkey rsa:2048 \
  -keyout apache.key \
  -out apache.crt \
  -days 365 \
  -noenc \
  -subj "/CN=dev.example.test" \
  -addext "subjectAltName=DNS:dev.example.test,DNS:localhost,IP:127.0.0.1"

Ich verwende hier bewusst -noenc statt der älteren Variante mit Passwortabfrage, weil Apache bei einem unverschlüsselten Schlüssel ohne Rückfrage starten kann. Wenn du den Schlüssel mit Passphrase absichern willst, lass -noenc weg und plane den Startdialog ein. Für einen Laborserver reicht mir meist die schnelle Variante mit sauber gesetzten SAN-Einträgen.

Lesen Sie auch: Nginx DNS Resolver - Wann er wirklich nötig ist und wie er funktioniert

Variante mit Konfigurationsdatei

Wenn mehrere Hostnamen oder IPv6-Adressen im Spiel sind, arbeite ich lieber mit einer kleinen Konfigurationsdatei. Das ist lesbarer, weniger fehleranfällig und bei Wiederholungen deutlich angenehmer als lange Shell-Argumente.

[ req ]
prompt = no
distinguished_name = req_distinguished_name
x509_extensions = v3_req

[ req_distinguished_name ]
CN = dev.example.test

[ v3_req ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = dev.example.test
DNS.2 = localhost
IP.1 = 127.0.0.1
IP.2 = ::1

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

Der zweite Weg ist für mich der robustere, weil ich Hostnamen, IPs und spätere Anpassungen sauber getrennt halte. Sobald die Dateien existieren, muss Apache sie nur noch korrekt einbinden und dem passenden virtuellen Host zuordnen.

Das Zertifikat sauber in Apache einbinden

Apache erwartet das Zertifikat und den privaten Schlüssel in getrennten Dateien. Ich halte mich daran konsequent, weil die Trennung die Dateirechte einfacher und die Angriffsfläche kleiner macht. Die Grundkonfiguration gehört in den TLS-VirtualHost auf Port 443, nicht in irgendeinen globalen Mischbereich.

Listen 443


    ServerName dev.example.test
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile "/etc/ssl/apache/apache.crt"
    SSLCertificateKeyFile "/etc/ssl/apache/apache.key"

Der ServerName sollte zu dem Namen passen, der im Zertifikat unter subjectAltName steht. Wenn ich den Server später über einen Alias oder eine IP aufrufe, und dieser Name dort nicht abgebildet ist, bekomme ich trotz korrekt eingebundenem Zertifikat unnötige Warnungen. Für den Schlüssel setze ich außerdem strikte Rechte, typischerweise 600 für die Key-Datei und 644 für das Zertifikat.

In der Praxis prüfe ich auch immer, ob wirklich der richtige VirtualHost auf Port 443 greift. Gerade auf Maschinen mit mehreren Sites landet man sonst schnell in der falschen Konfiguration, obwohl die Zertifikatsdateien eigentlich stimmen. Mit der Einbindung ist der technische Teil noch nicht erledigt, denn erst der Test zeigt, ob Browser, Name und Schlüssel wirklich zusammenpassen.

So prüfe ich, ob alles wirklich funktioniert

Bevor ich einen Server freigebe, teste ich die Konfiguration auf drei Ebenen: Apache selbst, die TLS-Verbindung und den Hostnamen. Das spart mir später Zeit, weil ich Fehler früh sehe und nicht erst im Browser des Nutzers.

Das -servername bei openssl s_client ist wichtig, wenn der Server mehrere TLS-Websites bedient. Ohne diesen Hinweis prüfst du unter Umständen den falschen Host. Im Browser ist eine Warnung bei einem selbstsignierten Zertifikat zunächst normal; verschwindet sie nicht trotz korrekter Datei und SAN, liegt das Problem meist im Trust Store oder in einer abweichenden Hostnamen-Auflösung. Nachdem die Grundprüfung steht, bleiben noch die Fehlerbilder, die mir im Alltag am häufigsten begegnen.

Typische Fehler, die ich in der Praxis immer wieder sehe

• Nur Common Name, kein SAN - der Hostname wirkt dann in modernen Clients schnell falsch oder unvollständig.
• Falscher Name im Zertifikat - der Server wird über einen Alias, eine interne Domain oder eine IP aufgerufen, die im Zertifikat fehlt.
• Schlüssel und Zertifikat in einer Datei - das ist laut Apache-Dokumentation ausdrücklich unerwünscht, weil Dateirechte und Risiko unnötig zusammenfallen.
• Verwechselter VirtualHost - Apache liefert ein anderes Zertifikat aus, als du denkst, weil der Port-443-Host nicht sauber zugeordnet ist.
• Zu offene Dateirechte - der private Schlüssel sollte nicht lesbar für alle sein.
• Passphrase unerwartet aktiv - Apache fragt beim Start nach einem Passwort, weil der Schlüssel verschlüsselt angelegt wurde.
• Browser-Cache und HSTS - alte Sicherheitszustände oder zwischengespeicherte Weiterleitungen sorgen für Fehlinterpretationen.

Aus meiner Sicht ist der häufigste Denkfehler, dass ein Zertifikat allein schon „HTTPS fertig“ bedeutet. In Wahrheit müssen Name, Pfad, Rechte und VirtualHost exakt zusammenpassen. Wenn das für eine lokale Testumgebung zu umständlich wird oder mehrere Systeme teilnehmen, lohnt sich der Blick auf eine stärkere Vertrauenskette.

Wann du besser auf eine echte Zertifizierungsstelle gehst

Sobald der Server von echten Nutzern, Kundensystemen oder mobilen Geräten erreicht wird, würde ich nicht mehr auf ein selbstsigniertes Zertifikat setzen. Dann kostet die manuelle Vertrauensverteilung mehr Zeit, als sie spart. Für öffentliche Dienste ist eine CA-Zertifikatskette oder eine ACME-basierte Lösung fast immer die bessere Entscheidung.

Gerade für produktive Apache-Installationen ist Automatisierung der eigentliche Gewinn. Ein Zertifikat, das man nur einmal im Jahr anfassen muss, ist besser als ein Testzertifikat, das jede Woche manuell nachgezogen werden muss. Für interne Netze kann eine eigene CA diesen Mittelweg liefern, weil sie die Geräte trust-seitig sauber versorgt und trotzdem unter eigener Kontrolle bleibt.

Was für Testumgebungen am Ende wirklich zählt

Wenn ich ein selbstsigniertes Zertifikat für Apache einrichte, achte ich im Kern auf vier Dinge: richtiger Hostname, getrennte Schlüsseldatei, saubere Apache-Definition und eine bewusste Entscheidung für den Einsatzbereich. Mehr braucht es für einen soliden Testserver oft nicht. Weniger sollte es aber auch nicht sein, sonst entsteht schnell eine Konfiguration, die zwar startet, aber im Browser oder im Team Ärger macht.

Der pragmatische Weg ist für mich deshalb klar: Für lokale oder interne Tests verwende ich ein knappes, sauber benanntes Zertifikat mit subjectAltName; für interne Mehrbenutzer-Umgebungen nehme ich eine eigene CA; und sobald der Server öffentlich erreichbar ist, wechsle ich auf eine echte, vertrauenswürdige Zertifikatsquelle. So bleibt Apache nachvollziehbar, sicher und ohne unnötige Bastelarbeit betreibbar.