TLS-Zertifikate im Betrieb: Warum Ablaufdaten ausfallen lassen und wie Automatisierung das verhindert

Ein abgelaufenes Zertifikat ist eine der unspektakulärsten und zugleich ärgerlichsten Ausfallursachen. Der Dienst läuft, der Server ist erreichbar, die Datenbank antwortet, und trotzdem sehen alle Nutzer eine Sicherheitswarnung des Browsers. Die Ursache ist fast nie technisch anspruchsvoll, sondern organisatorisch: Jemand hätte etwas erneuern müssen und hat es nicht getan.

Dieser Beitrag beschreibt, wie Sie den Lebenszyklus von TLS-Zertifikaten so aufsetzen, dass er ohne Kalendereinträge und ohne Heldentaten funktioniert - für Webserver ebenso wie für interne Dienste.

Warum Zertifikate ausgerechnet dort ablaufen, wo man es nicht erwartet

Die öffentliche Website ist meistens nicht das Problem. Sie ist sichtbar, jemand kümmert sich, oft läuft dort ohnehin schon eine automatische Erneuerung. Probleme entstehen an den Rändern.

Typische Kandidaten sind ein Mailserver mit manuell hinterlegtem Zertifikat, ein Loadbalancer, bei dem das Zertifikat vor Jahren einmal hochgeladen wurde, eine interne API hinter der Firewall, ein VPN-Gateway, ein Monitoring-Frontend oder ein Datenbankserver mit TLS-verschlüsselter Verbindung. Diese Systeme haben eines gemeinsam: Sie wurden einmal eingerichtet und danach nicht mehr angefasst.

Dazu kommt die Verteilung. Selbst wenn die Erneuerung automatisch läuft, heißt das nicht, dass die neue Datei auch dort ankommt, wo sie gebraucht wird. Ein Zertifikat, das auf dem Reverse Proxy erneuert wird, aber zusätzlich im Java-Keystore einer Anwendung liegt, ist an einer Stelle aktuell und an der anderen nicht.

Automatische Ausstellung als Standard, nicht als Sonderfall

Der wichtigste Schritt ist eine Entscheidung: Jedes Zertifikat, das ein System benötigt, wird automatisiert ausgestellt und erneuert, oder es wird begründet, warum das im Einzelfall nicht geht. Die Beweislast liegt bei der manuellen Variante, nicht umgekehrt.

Für öffentlich erreichbare Namen ist ACME das Mittel der Wahl. Das Protokoll regelt Domainvalidierung, Ausstellung und Erneuerung ohne menschliches Zutun. Clients gibt es für praktisch jede Plattform, und viele Reverse Proxies bringen die Funktion direkt mit. Kurze Gültigkeitszeiträume sind dabei kein Nachteil, sondern der eigentliche Punkt: Wer alle paar Wochen erneuert, merkt einen Fehler in der Automatisierung sofort und nicht erst nach einem Jahr.

HTTP-01 oder DNS-01

Die Validierungsmethode entscheidet, wie flexibel Sie später sind. Bei HTTP-01 beantwortet der Webserver eine Anfrage auf einem bestimmten Pfad. Das ist einfach, setzt aber voraus, dass der Name von außen auf Port 80 erreichbar ist. Für interne Systeme, Wildcard-Zertifikate oder Hosts hinter einer Firewall funktioniert das nicht.

DNS-01 legt stattdessen einen TXT-Eintrag in der Zone ab. Das erfordert einen DNS-Anbieter mit API und ein Token mit möglichst eng begrenzten Rechten, erlaubt dafür aber Zertifikate für Namen, die nie öffentlich erreichbar sind. In gemischten Umgebungen ist DNS-01 oft die ruhigere Wahl, weil eine Methode für alle Fälle reicht.

Zentral ausstellen oder pro Host

Zwei Muster sind verbreitet. Entweder holt sich jeder Host sein Zertifikat selbst, oder eine zentrale Stelle stellt aus und verteilt anschließend über die Konfigurationsverwaltung oder ein Secret-Management-System.

Pro Host ist einfacher und hat weniger bewegliche Teile. Zentral lohnt sich, sobald derselbe Name auf mehreren Systemen gebraucht wird, etwa bei mehreren Loadbalancern oder einem Cluster. Wichtig ist nur, sich pro Umgebung für ein Muster zu entscheiden und nicht beides halb umzusetzen.

Der oft vergessene Teil: Reload nach der Erneuerung

Eine erneuerte Datei auf der Festplatte ändert nichts, solange der Prozess das alte Zertifikat im Speicher hält. Jede Automatisierung braucht deshalb einen definierten Schritt nach der Erneuerung.

Bei den meisten Webservern genügt ein Reload ohne Verbindungsabbruch. Bei Mailservern, Datenbanken oder Anwendungsservern kann ein Neustart nötig sein, und der gehört dann in ein Wartungsfenster oder hinter einen Loadbalancer. Container bringen eine eigene Variante mit: Liegt das Zertifikat im Image statt im Volume, hilft nur ein neuer Rollout.

Prüfen Sie diesen Schritt aktiv. Der Klassiker ist eine Erneuerung, die seit Monaten sauber läuft, während der Dienst unverändert das erste Zertifikat ausliefert und beim nächsten Neustart plötzlich ein völlig anderes Datum zeigt.

Monitoring auf das ausgelieferte Zertifikat

Überwachen Sie nicht die Datei, sondern das, was der Dienst tatsächlich ausliefert. Ein Check baut eine Verbindung zum Endpunkt auf, liest das Zertifikat und prüft Restlaufzeit, Kettenvollständigkeit und ob der angefragte Name überhaupt enthalten ist.

Sinnvoll sind zwei Schwellen: eine frühe Warnung, die genug Zeit für eine ruhige Korrektur lässt, und eine harte Schwelle kurz vor Ablauf, die auch nachts jemanden erreicht. Bei kurzen Laufzeiten sollte die erste Warnung deutlich vor dem regulären Erneuerungszeitpunkt greifen, damit ein stiller Fehler in der Automatisierung auffällt, bevor es eng wird.

Der Check muss aus der Perspektive der Nutzer erfolgen. Ein intern erfolgreicher Test sagt nichts darüber aus, ob der Reverse Proxy nach außen eine unvollständige Kette ausliefert. Genau dieser Fehler fällt in Browsern oft nicht auf, bricht aber Verbindungen von API-Clients und mobilen Anwendungen.

Ein Inventar, das auch die stillen Ecken kennt

Automatisierung hilft nur bei Systemen, von denen Sie wissen. Führen Sie deshalb eine Liste aller TLS-Endpunkte mit Name, System, Aussteller, Erneuerungsmethode und verantwortlicher Rolle.

• Öffentliche Websites und Reverse Proxies
• Mail-, IMAP- und SMTP-Dienste
• VPN- und Fernzugriffs-Gateways
• Interne Admin-Oberflächen, Monitoring, CI-Systeme
• Datenbank- und Message-Broker-Verbindungen mit TLS
• Client-Zertifikate für Maschine-zu-Maschine-Kommunikation

Ergänzen Sie die Liste um einen aktiven Scan der eigenen Netze auf offene TLS-Ports. Erfahrungsgemäß taucht dabei mindestens ein Endpunkt auf, den niemand mehr auf dem Schirm hatte.

Interne Dienste und eine eigene CA

Für Systeme ohne öffentlichen Namen ist eine interne PKI die saubere Lösung. Sie stellt Zertifikate für interne Hostnamen aus, das Root-Zertifikat wird auf den Clients verteilt, und selbstsignierte Einzelstücke verschwinden.

Der Aufwand ist real: Die CA braucht sichere Schlüsselablage, klare Ausstellungsregeln, ein Verfahren für Sperrungen und einen Plan für den Wechsel des Root-Zertifikats. Wer diesen Aufwand nicht tragen will, fährt mit öffentlich ausgestellten Zertifikaten per DNS-01 auch für interne Namen oft besser, solange die Namen in einer Zone liegen, die Sie kontrollieren.

Schlüsselmaterial und Widerruf

Private Schlüssel gehören mit restriktiven Rechten auf das Dateisystem und niemals in ein Repository. Ein Zertifikat ohne den passenden Schlüssel ist wertlos, ein Schlüssel in falschen Händen ist ein Sicherheitsvorfall.

Planen Sie den Fall eines kompromittierten Schlüssels, bevor er eintritt. Wichtig ist nicht der Widerruf allein, sondern die Geschwindigkeit des Austauschs. Wenn die Ausstellung ohnehin automatisiert ist, reduziert sich der Vorfall auf einen Neuausstellungslauf und einen Reload statt auf einen Tag Handarbeit.

Was sich in der Praxis bewährt

Drei Punkte machen den Unterschied zwischen einem Thema, das Aufmerksamkeit kostet, und einem, das einfach läuft: automatisierte Erneuerung mit kurzen Laufzeiten, ein verlässlicher Reload-Schritt und ein Monitoring, das den ausgelieferten Endpunkt von außen prüft. Alles andere ist Dokumentation.

Die beste Kontrolle ist ein bewusster Test. Setzen Sie in einer Testumgebung die Systemzeit vor oder erzwingen Sie eine Erneuerung außer der Reihe und schauen Sie zu, ob am Ende wirklich das neue Zertifikat ausgeliefert wird. Ein Verfahren, das nie unter Beobachtung durchgelaufen ist, ist eine Annahme und kein Prozess.