SSL-Zertifikat bei Hetzner einrichten

Bei Hetzner gibt es nicht „das" SSL-Zertifikat, sondern drei getrennte Wege — und welcher davon gilt, entscheidet nicht die Domain, sondern das Produkt, auf dem sie 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: das Zertifikat kommt aus der Verwaltung#

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

Der zweite Weg im selben Menü ist das Hochladen eines eigenen Zertifikats. Das ist der Fall, wenn ein Zertifikat mit erweiterter Prüfung (OV oder EV) oder ein Zertifikat aus einem Unternehmensvertrag verwendet werden soll. 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.

Bei einem hochgeladenen Zertifikat entfällt die automatische Erneuerung. Das Ablaufdatum gehört in einen Kalender, nicht ins Gedächtnis.

Cloud-Server: hier ist man selbst die Automatik#

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

Der übliche Weg ist certbot, der offizielle ACME-Client. Er fordert das Zertifikat an, weist der Zertifizierungsstelle nach, dass man über die Domain verfügt, 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 genau diesen Server zeigen und Port 80 von außen erreichbar sein.

Ein Wildcard-Zertifikat lässt sich so nicht ausstellen. Dafür ist DNS-01 nötig, also ein Eintrag in der Zone der Domain, den der Client automatisiert setzen können muss.

Woran die Ausstellung typischerweise 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 weiterhin auf den alten Anbieter. Die Prüfung landet dann dort und schlägt fehl. Vor dem ersten Ausstellungsversuch lohnt eine Abfrage, welche Adresse die Domain tatsächlich auflöst, inklusive der www-Variante. Beide Namen müssen im Zertifikat stehen, sonst warnt der Browser bei einem davon.

Eine Weiterleitung fängt die Prüfung ab. Weiterleitungen von HTTP auf HTTPS sind unproblematisch, solange sie der Anfrage folgen und nicht ihr Ziel verändern. 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 nie die Datei zu sehen, die sie erwartet. Der Pfad /.well-known/ gehört deshalb 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 zuverlässig — auch dann, wenn die Seite über HTTPS bereits erreichbar ist.

Erneuerung: der Unterschied, der später auffällt#

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

Bei den verwalteten Produkten geschieht die Verlängerung ohne Zutun. Auf einem eigenen Server richtet certbot bei der Installation einen Zeitplan ein, der zweimal täglich prüft und erneuert, sobald weniger als 30 Tage Restlaufzeit übrig sind. Ob dieser Zeitplan wirklich läuft, zeigt ein Probelauf mit certbot renew --dry-run. Diese Prüfung ist die eine Minute wert, die sie kostet — die Alternative ist eine Fehlermeldung im Browser an einem Sonntagmorgen.

Eine stille Fehlerquelle bei der Erneuerung: Der Webserver lädt das neue Zertifikat nicht automatisch. Ohne einen Reload-Befehl nach dem Erneuern liefert der Prozess weiter das alte, abgelaufene aus, obwohl die neue Datei längst auf der Platte liegt.

Nach der Ausstellung ist die Arbeit nicht fertig#

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.

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. Welche Fehler eine Seite trotz gültigem Zertifikat unsicher lassen, zeigt der kostenlose SSL-Check; Header, Weiterleitungen und offene Ports prüft der Security-Scan im selben Durchgang mit.