TLS-Zertifikate wechseln: Was Administratoren jetzt tun müssen

Ein großer Zertifikataussteller für Webserver-Sicherheit hat angekündigt, eine Reihe von TLS-Zertifikaten vorzeitig ungültig zu machen. Für Administratoren bedeutet das kurzfristige Arbeit: Betroffene Zertifikate müssen bis zu einem bestimmten Termin erneuert werden, sonst drohen Ausfallzeiten. Dieser Ratgeber erklärt, was passiert ist, wer betroffen ist und welche Schritte jetzt wichtig sind.

Warum Zertifikate so plötzlich getauscht werden müssen

Der Grund für die vorzeitige Ungültigmachung liegt in einer Sicherheitsproblematik mit der Zertifikat-Infrastruktur. Ein Zertifikataussteller hat festgestellt, dass bestimmte bereits ausgestellte Zertifikate nicht den aktuellen Standards genügen und beschlossen, diese vorher als ungültig zu erklären, als ursprünglich geplant. Das ist im Sicherheitsbereich nicht ungewöhnlich, wenn Schwachstellen entdeckt werden.

Für betroffene Administratoren bedeutet das: Das bisherige Zertifikat funktioniert nach dem Stichtag nicht mehr, unabhängig davon, wie lange es ursprünglich gültig sein sollte. Browser und Clients werden die Verbindung ablehnen, weil das Zertifikat in der Sperrliste eingetragen ist. Ohne Austausch würde die Website oder der Service einfach nicht mehr erreichbar sein.

Wer ist von dem Zertifikat-Wechsel betroffen

Nicht jeder Administrator muss handeln. Nur wer ein Zertifikat von dem betroffenen Aussteller bezieht oder bezogen hat, ist betroffen. Das lässt sich leicht überprüfen: Im Browser kann man das Zertifikat einer Webseite anschauen und sieht dort, von wem es ausgestellt wurde. Auch der Zertifikat-Management-Server im eigenen Unternehmen zeigt, welche Aussteller verwendet werden.

Typischerweise sind größere Organisationen, Behörden und Unternehmen stärker betroffen als kleine Websites, weil sie größere Zertifikat-Infrastrukturen aufgebaut haben und möglicherweise mehrere Services mit diesen Zertifikaten betreiben. Wer mehrere Server, Mailserver oder APIs sichert, sollte eine vollständige Bestandsaufnahme machen.

Schritt für Schritt zum neuen Zertifikat

Der erste Schritt ist die Inventur: Alle Server und Services auflisten, die ein betroffenes Zertifikat nutzen. Dazu gehören Webserver, aber auch E-Mail-Server, VPN-Gateways oder API-Endpoints. Ein Blick in die Zertifikat-Verwaltung oder ein SSL-Scanner zeigt schnell, wie viele betroffene Zertifikate im Einsatz sind.

Danach muss ein neues Zertifikat beantragt werden. Das läuft über den gleichen Weg wie beim ersten Mal: Entweder direkt beim Zertifikataussteller oder über einen Reseller. Die Beantragung dauert typischerweise nur wenige Minuten bis Stunden, je nachdem, welche Validierungsmethode gewählt wird. Wichtig ist, rechtzeitig zu handeln und nicht erst kurz vor dem Stichtag zu beginnen, da Support-Teams in dieser Phase überlastet sein können.

Abschließend wird das neue Zertifikat auf den Servern installiert und der Service neu gestartet. Bei Systemen mit mehreren Services sollte man das gestaffelt tun, um keine unkontrollierte Ausfallzeit zu riskieren. Wer mehrere Server hat, kann nacheinander vorgehen und vorher testen.

Was passiert, wenn der Termin verpasst wird

Nach dem Stichtag gilt das alte Zertifikat als ungültig. Browser zeigen eine Sicherheitswarnung an, Clients lehnen die Verbindung ab. Für Website-Besucher sieht das aus wie ein Sicherheitsleck, obwohl technisch alles in Ordnung ist. Das Vertrauen ist schnell weg, und unkontrollierte Ausfallzeiten können teuer werden.

Allerdings ist auch nach dem Termin noch nicht alles verloren. Ein neues Zertifikat kann auch danach noch beantragt und installiert werden. Der Service ist dann zwar für die Zwischenzeit nicht nutzbar, kommt aber wieder zum Laufen, sobald das neue Zertifikat aktiv ist. Besser ist es trotzdem, vorausschauend zu arbeiten.