Ein zuverlässiger SSL-Erneuerungsprozess ohne Ausfallzeiten
Veröffentlicht am 18. Oktober 2026
Der SSL-Erneuerungsprozess sollte lange vor Ablauf des Zertifikats beginnen. Zu diesem Zeitpunkt sollten das Zertifikatsinventar, der DNS-Zugriff und der Bereitstellungspfad bereits geprüft sein. Eine Zertifikatserneuerung ist in der Regel Routine. Die Ausfälle entstehen meist im Zusammenhang damit: eine vergessene Subdomain, ein Validierungseintrag in der falschen DNS-Zone oder ein neues Zertifikat, das auf einem Server installiert wird, während der Datenverkehr weiterhin einen anderen Server erreicht.
Behandeln Sie die Erneuerung einer produktiven Website als kleine Wartungsänderung mit einem Rollback-Plan. Erstellen Sie das Ersatzzertifikat oder fordern Sie es an, führen Sie die Validierung durch, installieren Sie die vollständige Zertifikatskette, laden Sie den entsprechenden Webdienst neu und überprüfen Sie, welches Zertifikat externe Besucher tatsächlich erhalten. So bleibt der Dienst störungsfrei und Browser haben keinen Grund, Warnungen anzuzeigen.
Was bei der SSL-Erneuerung tatsächlich erneuert wird
Ein SSL-Zertifikat ist der Identitätsnachweis, den Ihr Server während einer HTTPS-Verbindung vorlegt. Es bestätigt, dass Besucher die vorgesehene Domain erreicht haben, und stellt eine verschlüsselte Kommunikation zwischen ihrem Browser und Ihrer Website her.
Bei einer Erneuerung werden normalerweise weder Ihre Website noch Ihre Anwendung oder die IP-Adresse Ihres Servers geändert. Dabei wird das vorhandene Zertifikat vor Ablauf durch ein neu ausgestelltes Zertifikat ersetzt. Öffentlich vertrauenswürdige TLS-Zertifikate haben eine begrenzte Gültigkeitsdauer, oft höchstens etwa 398 Tage. Viele Unternehmen entscheiden sich für kürzere Laufzeiten oder eine automatisierte Ausstellung. Das auf dem Zertifikat angegebene Datum ist keine unverbindliche Empfehlung des Browsers. Nach Ablauf können Besucher eine Warnung sehen, selbst wenn die Website einwandfrei funktioniert.
Die Erneuerungsmethode hängt vom Zertifikatstyp und der ausstellenden Stelle ab. Bei einem kostenpflichtigen, organisationsvalidierten Zertifikat kann eine Bestätigung per Freigabe-E-Mail, DNS-Eintrag oder Datei erforderlich sein, die auf der Website abgelegt wird. Bei automatisierten Zertifikaten wird häufig die ACME-Validierung über HTTP oder DNS verwendet. Das operative Ziel ist dasselbe: die Kontrolle über die Domain nachweisen, das Zertifikat erhalten und es korrekt bereitstellen.
Beginnen Sie mit einem Inventar, nicht mit der Ablaufbenachrichtigung
Als Erstes müssen Sie alle Endpunkte ermitteln, die das Zertifikat verwenden. Bei einem einzelnen Unternehmen können die Hauptwebsite, die www-Version, das Kundenportal, die API, der Mailserver, die Staging-Umgebung und der Load Balancer unterschiedliche Zertifikate verwenden. Eine Ablaufbenachrichtigung für einen Hostnamen belegt nicht, dass alle anderen abgedeckt sind.
Prüfen Sie die alternativen Antragstellernamen des Zertifikats, meist SANs genannt. Daraus gehen die im Zertifikat enthaltenen Domains und Subdomains hervor. Wenn `www.example.com` nicht enthalten ist, schützt ein Zertifikat nur für `example.com` diese Domain nicht. Wildcard-Zertifikate decken Subdomains der ersten Ebene wie `shop.example.com` ab, aber nicht automatisch die Root-Domain oder tiefer verschachtelte Namen wie `eu.shop.example.com`.
Ermitteln Sie außerdem, wo die TLS-Verbindung terminiert wird. Bei einem einfachen VPS kann das Zertifikat direkt in NGINX, Apache, Caddy oder einem Hosting-Control-Panel hinterlegt sein. Bei einer größeren Infrastruktur kann das Zertifikat auf einem Reverse-Proxy, einem CDN, einem Cloud-Load-Balancer, einem Kubernetes-Ingress-Controller oder mehreren Knoten hinter einem Load Balancer installiert sein. Die Erneuerung des Zertifikats auf dem Anwendungsserver bringt nichts, wenn der vorgeschaltete Proxy weiterhin das alte Zertifikat bereitstellt. Die DNS-Situation ist manchmal nicht besonders übersichtlich, aber sobald der Datenverkehrspfad erfasst ist, lässt sie sich kontrollieren.
Legen Sie interne Erinnerungen früher als das öffentliche Ablaufdatum fest. Dreißig Tage sind für ein unkompliziertes Zertifikat angemessen, während 45 bis 60 Tage mehr Spielraum bieten, wenn mehrere Teams, externe DNS-Anbieter oder eine geschäftliche Validierung beteiligt sind. Die Überwachung sollte an mehreren Zeitpunkten alarmieren, zum Beispiel 30, 14, 7 und 3 Tage vor Ablauf. Eine einzelne E-Mail-Erinnerung kann herausgefiltert oder ignoriert werden oder jemanden erreichen, der das Unternehmen bereits im letzten Frühjahr verlassen hat.
Wählen Sie eine Validierungsmethode, die zu Ihrer Infrastruktur passt
Bei der Validierung der Domainkontrolle geraten viele Erneuerungen ins Stocken. Die Zertifizierungsstelle benötigt einen Nachweis, dass Sie die Kontrolle über die angeforderte Domain haben. Am besten eignet sich die Methode, die Ihr Team zuverlässig wiederholen kann.
Bei der HTTP-Validierung wird eine bestimmte Datei unter einer bestimmten öffentlichen URL abgelegt. Das ist praktisch, wenn der Webserver direkt über Port 80 erreichbar ist und den richtigen virtuellen Host bereitstellt. Sie kann fehlschlagen, wenn der Datenverkehr auf ungewöhnliche Weise umgeleitet wird, die Website hinter einem restriktiven Proxy liegt oder eine Firewall die Validierungsanfrage blockiert.
Bei der DNS-Validierung muss beim DNS-Anbieter der Domain ein TXT-Eintrag angelegt werden. Sie eignet sich häufig besser für Wildcard-Zertifikate und Systeme, bei denen kein HTTP-Validierungspfad bereitgestellt werden kann. Sie funktioniert auch gut mit verteilter Infrastruktur, allerdings muss die DNS-Propagation abgewartet werden. Manche DNS-Änderungen werden innerhalb von Sekunden wirksam, andere benötigen aufgrund von TTL-Einstellungen, dem Verhalten des Anbieters und zwischengespeicherten Resolvern länger. Entfernen Sie den Validierungseintrag erst, wenn die Ausstellung bestätigt wurde.
Die E-Mail-Validierung kann in kleinen, stabilen Umgebungen funktionieren, hängt jedoch stärker vom Zugriff auf Postfächer und zugelassenen E-Mail-Adressen ab. Ist der Registrierungskontakt der Domain veraltet oder wird ein Funktionspostfach nicht mehr überwacht, kommt die Erneuerung an dieser Stelle zum Stillstand. Bei geschäftskritischen Diensten sorgen DNS- oder automatisierte ACME-Validierung in der Regel für weniger Engpässe durch manuelle Arbeit.
Erstellen Sie das Zertifikat mit Sorgfalt
Erstellen Sie bei manuell verwalteten Zertifikaten eine Zertifikatsignierungsanforderung, kurz CSR, auf dem System, auf dem der private Schlüssel gespeichert wird. Die CSR enthält den öffentlichen Schlüssel und die Domainangaben. Der private Schlüssel muss geheim bleiben. Senden Sie ihn nicht per E-Mail, fügen Sie ihn nicht in Tickets ein und speichern Sie ihn nicht in einem gemeinsam genutzten Dokument mit dem Namen `final-final-use-this-one`.
Sie können bei der Erneuerung einen vorhandenen Schlüssel wiederverwenden. In der Regel ist es jedoch betrieblich sicherer, einen neuen privaten Schlüssel zu erstellen. Durch den Schlüsselwechsel werden die Auswirkungen begrenzt, falls ein alter Schlüssel unbemerkt offengelegt wurde. Der Kompromiss ist einfach: Ein neuer Schlüssel muss überall, wo das Zertifikat verwendet wird, sorgfältig bereitgestellt werden. Bei den meisten Installationen auf einem einzelnen Server ist dieser Mehraufwand gering und lohnt sich.
Laden Sie nach der Ausstellung das Serverzertifikat und die von der Zertifizierungsstelle bereitgestellte Zwischenzertifikatskette herunter. Moderne Webserver benötigen häufig eine vollständige Zertifikatskettendatei, die das Endzertifikat und die Zwischenzertifikate enthält. Fehlende Zwischenzertifikate sind eine häufige Ursache für Vertrauensfehler in Browsern, insbesondere auf älteren Geräten oder bei weniger verbreiteten Clients.
Automatisierte ACME-Clients können die Schlüsselerstellung, Validierung, Erneuerung und Installations-Hooks übernehmen. Für Zertifikate, bei denen dies möglich ist, wird Automatisierung dringend empfohlen. Sie muss jedoch weiterhin überwacht werden. Eine automatische Erneuerungsaufgabe, die DNS nicht erreichen, nicht in das Zertifikatsverzeichnis schreiben oder NGINX nicht neu laden kann, ist nur in einem sehr optimistischen Sinne automatisch.
Stellen Sie das Zertifikat bereit, ohne Besucher zu beeinträchtigen
Kopieren Sie vor dem Ersetzen die aktuellen Zertifikate und die Konfiguration an einen geschützten Sicherungsort. Bewahren Sie das vorherige Zertifikat, den Verweis auf den Schlüssel und die bekanntermaßen funktionierende Konfiguration auf, bis die neue Installation überprüft wurde. So kann Ihr Team schnell ein Rollback durchführen, falls eine Kettendatei, eine Berechtigungseinstellung oder ein Syntaxdetail fehlerhaft ist.
Installieren Sie das neue Zertifikat und den dazugehörigen privaten Schlüssel am vorgesehenen Speicherort. Vergewissern Sie sich, dass der Webserver-Prozess die Dateien lesen kann, ohne den privaten Schlüssel für Unbefugte lesbar zu machen. Unter Linux sind restriktive Eigentümer- und Berechtigungseinstellungen wichtig. Ein Zertifikat ist grundsätzlich öffentlich; sein privater Schlüssel ist es nicht.
Überprüfen Sie die Konfiguration des Webservers, bevor Sie ihn neu laden. Verwenden Sie bei NGINX, Apache, HAProxy und ähnlichen Diensten zuerst den Konfigurationstest des jeweiligen Produkts. Laden Sie den Dienst anschließend nach Möglichkeit neu, anstatt ihn neu zu starten. Beim Neuladen wird das Zertifikat aktualisiert, während vorhandene Worker-Prozesse und aktive Verbindungen ordnungsgemäß abgeschlossen werden können. Ein vollständiger Neustart kann während eines Wartungsfensters akzeptabel sein, ist bei vielen gängigen Konfigurationen jedoch unnötig.
Wenn der Dienst auf mehreren Servern läuft, stellen Sie das Zertifikat auf allen Knoten einheitlich bereit, bevor Sie den Wechsel durchführen oder währenddessen. Load Balancer können aufeinanderfolgende Browseranfragen an unterschiedliche Backend-Server senden. Hat nur ein Knoten das neue Zertifikat, können gelegentlich Warnungen auftreten. Das ist besonders ärgerlich, weil es zunächst wie ein eingebildetes Problem wirkt – bis es keines mehr ist.
Überprüfen Sie das Zertifikat von außerhalb des Servers
Geben Sie sich nicht damit zufrieden, dass das Control-Panel die erfolgreiche Installation meldet. Überprüfen Sie das Zertifikat über ein externes Netzwerk und kontrollieren Sie den Hostnamen, den Besucher verwenden. Prüfen Sie den Common Name oder die SAN-Abdeckung, die ausstellende Stelle, das Ablaufdatum und die Zertifikatskette. Prüfen Sie sowohl den Root- als auch den www-Hostnamen, sofern beide öffentlich erreichbar sind.
Verwenden Sie einen Browser als eine Prüfmöglichkeit, verlassen Sie sich aber nicht ausschließlich darauf. Ein Browser kann Sitzungen oder Informationen zur Zertifikatskette zwischenspeichern. Testen Sie mit einem TLS-Client oder einer externen Überwachungsprüfung, die das unter der öffentlichen IP-Adresse bereitgestellte Zertifikat meldet. Prüfen Sie in komplexen Umgebungen für jede gehostete Domain mithilfe von Server Name Indication, kurz SNI, ob das richtige Zertifikat zurückgegeben wird.
Prüfen Sie anschließend das Verhalten der Anwendung: Melden Sie sich an, senden Sie ein Formular ab, rufen Sie einen API-Endpunkt auf und überprüfen Sie alle HTTPS-URLs für Rückrufe von Drittanbietern. Eine Zertifikatserneuerung sollte das Verhalten der Anwendung nicht verändern. Bei der Validierung und in Proxy-Regeln treten jedoch manchmal nicht damit zusammenhängende Konfigurationsprobleme zutage. Wenn sowohl die externe Zertifikatsprüfung als auch die Anwendungsprüfungen erfolgreich sind, erzählen die Protokolle nun dieselbe Geschichte.
Sorgen Sie dafür, dass die nächste Erneuerung unspektakulär verläuft
Der beste SSL-Erneuerungsprozess ist der, bei dem niemand in Zeitnot gerät. Dokumentieren Sie den Zertifikatsverantwortlichen, die Erneuerungsmethode, den DNS-Anbieter, den Speicherort des Dienstes, die betroffenen Hostnamen und die Rollback-Schritte. Speichern Sie diese Informationen an einem Ort, auf den das Betriebsteam zugreifen kann, und nicht nur im Gedächtnis einer einzelnen Person.
Bei verwalteten Servern sollte die Zertifikatsüberwachung neben Verfügbarkeits-, Festplatten-, Backup- und Dienstprüfungen eingerichtet sein. Ein bevorstehendes Ablaufdatum ist ein betriebliches Signal und nicht bloß eine Verwaltungsaufgabe. Bei kodu.cloud gehört diese regelmäßig anfallende Wartung ganz selbstverständlich zum Managed Support und Monitoring: Ermitteln Sie frühzeitig den Endpunkt, erneuern Sie das Zertifikat mit der passenden Validierungsmethode und überprüfen Sie anschließend den laufenden Dienst.
Wenn Ihr Zertifikat bald abläuft, prüfen Sie zuerst, welches Zertifikat aktuell öffentlich bereitgestellt wird. Arbeiten Sie sich dann über DNS und Validierung bis zur Serverkonfiguration vor. In der Regel gibt es einen klaren Weg nach vorn. Planen Sie genügend Zeit für die Erneuerung ein, überprüfen Sie sie von außerhalb, und Ihre Besucher werden lediglich bemerken, dass die Website weiterhin wie vorgesehen funktioniert.
Andres Saar, Kundenbetreuungsingenieur