Zertifikate laufen nicht ab.
Sie werden vergessen.
certs24 übernimmt den Teil der TLS-Verwaltung, den sonst ein Cronjob, ein Wiki-Eintrag und die Hoffnung erledigen sollen: beobachten, erneuern, ausrollen — bevor jemand eine Ablauf-Mail wegklicken muss.
Was ein TLS-Zertifikat tatsächlich tut
Ein TLS-Zertifikat bindet einen öffentlichen Schlüssel an einen Hostnamen und wird von einer Zertifizierungsstelle (CA) signiert. Der Client prüft die Signatur gegen seinen Trust Store und baut die verschlüsselte Verbindung nur auf, wenn die Kette bis zu einem vertrauenswürdigen Root passt. Nichts Magisches — aber jedes Glied der Kette hat ein Ablaufdatum, und das Blatt-Zertifikat hat meistens das kürzeste.
Transportverschlüsselung
Der TLS-Handshake handelt Session-Keys aus. Danach ist die Verbindung zwischen Client und Server verschlüsselt — Passwörter, Tokens und Payloads sind auf dem Weg nicht mehr im Klartext lesbar.
Chain of Trust
Leaf-Zertifikat, Intermediate, Root — jede Stufe signiert die nächste. Fehlt ein Glied oder ist es abgelaufen, bricht die Kette und der Client lehnt ab, unabhängig vom Rest der Konfiguration.
Kurze Laufzeit ist Absicht
Let's Encrypt stellt seit Jahren auf 90 Tage aus, das CA/Browser-Forum drückt die Branche weiter Richtung kürzerer Laufzeiten. Kompromittierte Schlüssel sollen schneller wertlos werden — manuell erneuert man das irgendwann nicht mehr rechtzeitig.
Ein abgelaufenes Zertifikat ist kein Warnhinweis mehr
Browser lassen sich seit Jahren nicht mehr wegklicken — abgelaufen heißt harter Stop, nicht gelbes Dreieck. Und Zertifikate laufen meist nicht ab, weil niemand es wusste, sondern weil die Zuständigkeit zwischen zwei Reorgs verloren gegangen ist und die Kalendererinnerung an eine Person ging, die nicht mehr im Team ist.
Harter Stop im Handshake
Kein Klick-durch-Warnhinweis mehr. Der Browser bricht die Verbindung ab, bevor die Seite überhaupt lädt.
Server-zu-Server bricht lautlos
Webhooks, interne APIs, mTLS zwischen Services — kein Nutzer sieht eine Fehlermeldung, nur Timeouts und Retries in euren Logs.
Der Postmortem schreibt sich von selbst
„Root cause: certificate expired" ist einer der unangenehmsten Sätze in einem Incident-Report — weil er komplett vermeidbar war.
Auditoren finden es sofort
SSL Labs, Qualys, interne Scanner — ein abgelaufenes Zertifikat ist eines der am leichtesten zu findenden Findings in jedem Audit.
Was Zertifikatsverwaltung heute wirklich kostet
Ohne Automatisierung ist das kein einmaliges Setup, sondern ein Prozess, der alle paar Wochen wieder anfängt — verteilt auf mehrere Personen, mit jedem Durchlauf ein neues Risiko für einen Fehler.
-
01
Inventar pflegen
Jede Domain, Subdomain und jeder interne Host mit eigenem Zertifikat — meist in einem Spreadsheet, das eine Person aktuell hält.
-
02
Ablauf im Blick behalten
Kalendererinnerung 30 Tage vorher — im besten Fall kommt sie an, bevor die zuständige Person im Urlaub oder gekündigt ist.
-
03
CSR, Validierung, Ausstellung
CSR erzeugen, Domain-Validierung per DNS-01 oder HTTP-01 durchführen, auf die Antwort der CA warten.
-
04
Rollout ohne Verbindungsabbruch
Neues Zertifikat auf jeden Node, Load Balancer und jedes CDN-Profil ausrollen — reihum, ohne aktive Verbindungen zu kappen.
Bei einer Handvoll Domains ist das ein Nachmittag im Quartal. Bei 50, 200 oder 1.000 Domains ist es eine Teilzeitstelle, die in keinem Organigramm auftaucht.
Was certs24 im Hintergrund erledigt
Kein Feature-Bingo — der komplette Lebenszyklus eines Zertifikats, von der Ausstellung bis zum Rollout.
Automatische Erneuerung
ACME-Flow (HTTP-01, DNS-01, TLS-ALPN-01) läuft im Hintergrund. Neue Zertifikate werden ausgestellt, bevor das alte sein Limit erreicht.
Zentrales Inventar
Jede Domain, Subdomain und jeder interne Host in einer Liste — mit dem echten Ablaufdatum, nicht dem, der zuletzt im Wiki stand.
Alerts bei echten Problemen
Webhook, Slack oder E-Mail, wenn eine Erneuerung fehlschlägt — nicht erst, wenn das Zertifikat schon abgelaufen ist.
Rollout ohne Verbindungsabbruch
Rolling Reload auf Load Balancern und Reverse Proxies, ohne bestehende Verbindungen zu trennen.
Frei wählbare CA
Let's Encrypt, ZeroSSL oder eine eigene interne CA per ACME — austauschbar, ohne den Rest der Pipeline anzufassen.
Audit-Log
Jede Ausstellung, Erneuerung und jeder Fehlversuch protokolliert — exportierbar für den nächsten Auditor, der danach fragt.
Läuft mit dem, was ihr schon im Einsatz habt
Kein proprietäres Format, kein Lock-in. Rollout läuft über Standard-Protokolle auf eure bestehende Infrastruktur — Reverse Proxy, Load Balancer oder Orchestrierung, so wie es schon konfiguriert ist.
Config-Reload ohne Verbindungsabbruch
Runtime-Update über die Socket-API
SDS-kompatible Zertifikatsrotation
Dynamische Konfiguration, kein Neustart
TLS-Secrets werden automatisch aktualisiert
Import direkt über die ACM-API
Nativer ACME-Client, direkt angebunden
iControl REST für Enterprise-Setups
Fehlt euer Setup in der Liste? Die REST-API und Webhooks decken so gut wie jede eigene Rollout-Pipeline ab.
Manuell vs. automatisiert, ohne Beschönigung
Kein Prozess wird durch Automatisierung „einfacher" — er wird nur nicht mehr von einer Person getragen, die auch noch andere Dinge zu tun hat.
Vier Schritte, dann läuft es im Hintergrund
Host verbinden
DNS-Eintrag oder ACME-Endpunkt hinterlegen. Kein Agent, den ihr auf jedem Server pflegen müsst.
Monitoring läuft an
Ablauf, Kette und Konfiguration werden laufend geprüft — nicht nur einmal beim Setup.
Erneuerung & Rollout
ACME-Request, Validierung, Rollout auf alle konfigurierten Ziele — automatisch, mit Retry bei Fehlern.
Log-Eintrag, fertig
Bestätigung im Audit-Log, optional eine Zeile in Slack. Kein Ticket, keine Rückfrage nötig.
Bevor ihr das Team fragt
Brauche ich einen Agenten auf jedem Server?
Nein. certs24 spricht ACME direkt mit eurem Load Balancer, Reverse Proxy oder eurer DNS-Zone. Ein Agent ist optional — für Setups ohne öffentlich erreichbaren HTTP-01-Endpunkt.
Funktioniert das mit einer internen/privaten CA?
Ja, über einen eigenen ACME-Endpunkt. Intermediates und Root lassen sich genauso einbinden wie bei Let's Encrypt oder ZeroSSL — die Pipeline dahinter bleibt identisch.
Was passiert, wenn ein Rollout fehlschlägt?
Automatischer Retry mit Backoff, das alte Zertifikat bleibt aktiv, bis der Austausch erfolgreich war. Bei wiederholtem Fehlschlag geht ein Alert raus, bevor es kritisch wird — nicht danach.
Unterstützt ihr Wildcard- und SAN-Zertifikate?
Ja, beides. Wildcards laufen über DNS-01-Validierung, SAN-Zertifikate lassen sich mit beliebig vielen Hostnamen pro Zertifikat konfigurieren.
Wie lange dauert das Onboarding für bestehende Domains?
Ein paar Minuten pro Zielsystem — DNS oder ACME-Endpunkt verbinden, der Rest läuft über die Konfiguration, die ihr ohnehin schon habt.
Ein abgelaufenes Zertifikat sollte kein Vorfall sein, über den man redet.
Richtet certs24 einmal ein und nehmt Zertifikatsablauf von der Liste der Dinge, die nachts anrufen können.