SSL-Zertifikat bei Hetzner einrichten

Es gibt bei Hetzner kein „das SSL-Zertifikat“, sondern drei Wege, und welcher gilt, entscheidet das Produkt, auf dem die Domain liegt. Wer das verwechselt, sucht im Kundenmenü nach einer Schaltfläche, die es dort nicht geben kann. Die Trennlinie verläuft zwischen verwalteten Produkten und Servern mit Root-Zugang.

Webhosting und Managed Server#

Bei den verwalteten Angeboten übernimmt die Verwaltungsoberfläche konsoleH die Ausstellung: Domain auswählen, Zertifikat aktivieren, die Plattform holt es bei Let's Encrypt, hinterlegt es im Webserver und verlängert es später selbst. Ein Zugriff auf Konfigurationsdateien ist dafür weder nötig noch vorgesehen.

Der zweite Weg im selben Menü ist das Hochladen eines eigenen Zertifikats, etwa eines mit erweiterter Prüfung (OV oder EV) oder aus einem Unternehmensvertrag. Dabei werden drei Bestandteile gebraucht: das Zertifikat selbst, der zugehörige private Schlüssel und die Zwischenzertifikate der ausstellenden Stelle. Fehlt der letzte Teil, funktioniert die Seite im eigenen Browser oft trotzdem, weil der das Zwischenzertifikat noch zwischengespeichert hat; auf einem fremden Gerät bricht die Kette dann sichtbar ab. Und bei einem hochgeladenen Zertifikat entfällt die automatische Erneuerung. Das Ablaufdatum gehört in einen Kalender.

Cloud-Server#

Ein Cloud-Server kommt ohne Weboberfläche für Zertifikate. Es gibt kein Menü, weil es keine verwaltete Schicht gibt; der Server gehört dir, samt aller Zuständigkeit.

Der übliche Weg ist certbot, der ACME-Client der EFF. Er fordert das Zertifikat an, weist der Zertifizierungsstelle nach, dass du über die Domain verfügst, und trägt die Pfade in die Konfiguration von Apache oder nginx ein. Der Nachweis läuft im Regelfall über HTTP-01: Let's Encrypt ruft eine Datei unter /.well-known/acme-challenge/ auf der Domain ab. Damit das gelingt, muss die Domain auf diesen Server zeigen und Port 80 von außen erreichbar sein. Ein Wildcard-Zertifikat geht so nicht; dafür ist DNS-01 nötig, also ein TXT-Eintrag, den der Client automatisiert setzen können muss. Ob ein Wildcard überhaupt die richtige Wahl ist, steht in SSL-Zertifikat erstellen.

Woran die Ausstellung scheitert#

Die Domain zeigt noch woanders hin. Der häufigste Fall bei Umzügen: Der Server steht, der Webserver läuft, aber der A-Eintrag verweist weiter auf den alten Anbieter. Die Prüfung landet dort und schlägt fehl. Vor dem ersten Versuch deshalb nachsehen, wohin die Domain auflöst, und zwar beide Namen:

dig beispiel.de A +short
dig www.beispiel.de A +short

Beide müssen die Adresse des neuen Servers liefern und beide gehören ins Zertifikat, sonst warnt der Browser bei einem davon. Wie man DNS-Antworten liest und warum der eigene Resolver noch die alte Adresse zeigen kann, steht in DNS-Eintrag prüfen.

Eine Weiterleitung fängt die Prüfung ab. Weiterleitungen von HTTP auf HTTPS stören nicht, solange sie der Anfrage folgen. Kritisch wird es, wenn eine Regel in der .htaccess oder in der Serverkonfiguration alle Anfragen pauschal auf die Startseite oder auf eine andere Domain umleitet. Dann bekommt die Zertifizierungsstelle die Datei nie zu sehen. Der Pfad /.well-known/ gehört von jeder Umleitungs- und Sperrregel ausgenommen.

Der Port ist zu. Eine Firewall-Regel in der Cloud-Konsole oder eine lokale Regel auf dem Server, die Port 80 schließt, verhindert die Prüfung, auch wenn die Seite über HTTPS bereits erreichbar ist.

Erneuerung#

Ein Zertifikat von Let's Encrypt läuft nach 90 Tagen ab. Das ist Absicht: Eine kurze Laufzeit erzwingt Automatisierung, und Automatisierung ist verlässlicher als ein Kalendereintrag.

Bei den verwalteten Produkten geschieht die Verlängerung ohne Zutun. Auf dem eigenen Server richtet certbot bei der Installation einen Zeitplan ein, der zweimal täglich prüft und erneuert, sobald weniger als ein Drittel der Laufzeit übrig ist, bei 90 Tagen also 30. Ob dieser Zeitplan läuft, zeigt ein Probelauf:

certbot renew --dry-run

Eine stille Fehlerquelle danach: Der Webserver lädt das neue Zertifikat nicht von selbst. Ohne einen Reload nach dem Erneuern liefert der Prozess das alte weiter aus, obwohl die neue Datei längst auf der Platte liegt. certbot kann dafür einen Befehl hinterlegen (--deploy-hook); ohne ihn fällt der Fehler erst auf, wenn das alte Zertifikat abgelaufen ist.

Nach der Ausstellung#

Ein installiertes Zertifikat verschlüsselt nichts, solange die Seite weiter über HTTP ausgeliefert wird. Erst eine Weiterleitung von HTTP auf HTTPS und ein HSTS-Header machen die Verschlüsselung verbindlich; wie der gesetzt wird, mit welchem Startwert und warum nicht gleich mit einem Jahr, steht in Security-Header einrichten.

Der letzte Schritt sind gemischte Inhalte: Bilder, Skripte oder Stylesheets, die im Quelltext noch mit http:// referenziert sind. Der Browser zeigt dann kein geschlossenes Schloss, obwohl das Zertifikat einwandfrei ist. Bei WordPress stecken diese Adressen meist in der Datenbank und müssen dort ersetzt werden, nicht in den Vorlagen. Kette, Weiterleitung und Header prüft der Security-Scan von außen.

Stand 03.10.2026. Quellen an diesem Tag abgerufen; die Menüs von konsoleH sind aus eigener Nutzung beschrieben, Hetzner verlinkt sie nicht einzeln.