Ein TLS-Zertifikat ist eines dieser Dinge, an die im Unternehmen niemand denkt — bis es abläuft. Dann fallen innerhalb einer Stunde der Shop, das Kundenportal, der Browser-Login zum ERP und die Hälfte der Integrationen aus, an die sich niemand mehr erinnert. Es lohnt sich, dafür ein System zu haben, bevor sich das System rächt.
Wir haben es aus der Nähe bei einem 30-Personen-Metallverarbeiter gesehen: Das B2B-Portal, über das Kunden Bestellungen aufgaben, hatte ein SSL-Zertifikat, das am Sonntag um 23:00 Uhr ablief. Niemand bekam einen Alarm (denn die Alarme gingen an die E-Mail eines ehemaligen Administrators), und am Montag um 8:00 Uhr sahen die Kunden statt des Bestellformulars „Ihre Verbindung ist nicht privat". Vier Stunden Stillstand, gut ein Dutzend verlorene Aufträge, geschätzt etwa 60 000 PLN Umsatz zum Zurückholen. Die technische Reparatur dauerte 20 Minuten. Das Vertrauen einiger großer Kunden zurückzugewinnen — mehrere Monate.
Dieser Text handelt davon, wie ein Unternehmen mit 10–50 Mitarbeitern die Zertifikatsverwaltung so organisieren kann, dass sich diese Situation nicht wiederholt. Ohne aufwendige PKI, ohne teure Enterprise-Tools. Ein paar Gewohnheiten und eine Tabelle reichen.
Fang mit einer Inventur an — du hast mehr Zertifikate, als du denkst
Die erste Frage, die in einem typischen Unternehmen niemand beantworten kann: „Wie viele aktive TLS-Zertifikate haben wir gerade, und wo sind sie?". „Das auf der Startseite" reicht selten. In der Praxis findest du im KMU Zertifikate an mindestens diesen Stellen:
- Die Firmenwebsite und ihre regionalen Varianten.
- Der Online-Shop, das B2B-Portal, das Kundenportal.
- Browser-Login-Panels zu Systemen (Webmail, HR-Portal, ERP-Serviceportal).
- Mailserver (SMTP/IMAPS) — auch bei Microsoft 365 besitzt ihr eigene Subdomains mit Zertifikaten für Autodiscover oder SPF/DMARC-Endpunkte.
- VPN-Server und Firewalls (Fernzugriff, Admin-Panel).
- Interne Apps und APIs über HTTPS, auch im LAN.
- Netzwerkgeräte mit HTTPS-Panels (Drucker, NAS-Geräte, Industriekameras).
- Code-Signing-Zertifikate (wenn ihr eine Desktop-App oder Installer ausliefert).
Mach eine einfache Übersicht — Excel oder Google Sheets. Spalten: Name (FQDN), Ort der Installation (Server/Gerät), Aussteller, Ablaufdatum, fachlicher Verantwortlicher (nicht die IT — die Person, die bestätigt „ja, dieses Portal ist kritisch"), Ablage des privaten Schlüssels, letzte Erneuerung. Diese Tabelle hat zwei Funktionen: Sie sagt dir, was du hast, und legt offen, was du vergessen hattest. Der erste Durchlauf bei einem Kunden fördert typischerweise 2–3 Zertifikate zutage, von denen niemand wusste.
Trenne „automatisch" von „manuell"
Für die meisten externen Zertifikate (Website, Portal, Shop) ist ACME die beste Antwort — meistens Let's Encrypt — mit automatischer Erneuerung alle 60–75 Tage. Das Zertifikat gilt 90 Tage, der Client (certbot, acme.sh, der eingebaute Mechanismus des Webservers) erneuert es ohne menschliches Zutun. Wenn die Automatik läuft, läuft nichts ab. Wenn sie nicht läuft, erfährst du das aus einem Alarm, nicht aus einem Anruf des Kunden.
Es gibt trotzdem Situationen, in denen du einmal im Jahr manuell erneuerst:
- EV- / OV-Zertifikate, die z. B. manche Bankintegrationen oder Konzernkunden verlangen.
- Zertifikate auf Geräten, die ACME nicht erreicht (Firewall ohne passende API, alter Drucker, PLC-Controller mit HTTPS-Panel).
- Code-Signing-Zertifikate — die erneuern sich per Definition nicht selbst.
- Zertifikate für Integrationen, bei denen die Gegenseite eine Whitelist der Aussteller pflegt (z. B. der öffentliche Sektor).
Für diese „manuellen" brauchst du eine Prozedur, denn nichts erinnert dich von selbst.
Alarme bei 60, 30, 14, 7 und 1 Tag
Verlass dich nicht darauf, dass der Aussteller (Let's Encrypt, DigiCert, Sectigo) dich erinnert. Doch, sie schicken E-Mails — aber oft an einen Administrator, der vor zwei Jahren gegangen ist, oder mit Betreffzeilen, die wie Spam aussehen. Betreibe eigenes Monitoring, das regelmäßig ein Dutzend öffentlicher Domains prüft und einen gemeinsamen Kanal alarmiert (das Postfach des IT-Teams, einen Teams-/Slack-Kanal — nicht das Postfach einer Einzelperson).
Ein praxistaugliches Set an Alarmschwellen im KMU:
- 60 Tage vor Ablauf — weiche Warnung, informativ. Landet im Postfach, kann ignoriert werden, aber du weißt, dass es kommt.
- 30 Tage — behandle es als Aufgabe: erneuern oder diagnostizieren, warum die Automatik nicht erneuert hat.
- 14 Tage — Alarm. Jemand übernimmt es und schließt es diese Woche ab.
- 7 Tage — rotes Licht. IT-Leitung einbeziehen, an den fachlichen Verantwortlichen der Dienstleistung eskalieren.
- 1 Tag — Anruf beim Bereitschaftsdienst. Ernsthaft.
Um öffentliche TLS-Zertifikate zu prüfen, reicht ein kleines Cron-Skript, das openssl s_client aufruft und notAfter ausliest, oder kostenlose Tools wie Uptime Kuma mit TLS-Modul. Du musst keine Plattform für 20 000 im Jahr kaufen. Wichtig ist, dass die Alarme an einen Teamkanal, nicht an ein einzelnes Postfach gehen.
Private Schlüssel — wo sie liegen und wer Zugang hat
Das Zertifikat ist die halbe Geschichte. Der private Schlüssel ist die andere Hälfte. Wenn der Schlüssel abhandenkommt, muss das Zertifikat widerrufen und neu ausgestellt werden — am besten gestern. Im KMU leben private Schlüssel meist an drei Orten: direkt auf dem Produktionsserver, im Konfigurations-Repository (leider manchmal in git ohne Verschlüsselung) und „für alle Fälle" in einem Ordner namens alte_zertifikate auf dem Netzlaufwerk.
Regeln, an denen es sich festzuhalten lohnt:
- Der private Schlüssel wird auf dem Gerät erzeugt, auf dem er arbeiten soll — nicht auf dem Admin-Laptop, dann per Mail herumgeschickt.
- Die Sicherung des Schlüssels (irgendwann muss jemand den Server neu aufbauen) liegt in einem verschlüsselten Secrets-Manager oder in einem Offline-Archiv, nicht auf einem gemeinsamen Netzlaufwerk.
- Wer Zugriff auf den Schlüssel hatte, hatte ihn — nach seinem Weggang aus der Firma wird der Schlüssel zusammen mit dem Zertifikat rotiert.
- Schlüssel gehören nicht ins git-Konfigurations-Repository. Nie. Auch nicht in ein „privates" Repo.
Das klingt nach selbstverständlicher Hygiene. Ist es nicht. In der Praxis finden wir noch immer .pem-Dateien mit privaten Schlüsseln in PowerPoint-Onboarding-Decks und in E-Mail-Anhängen von vor fünf Jahren.
Wildcard, SAN und interne CA
Zwei technische Entscheidungen, die man bewusst treffen sollte, nicht aus Trägheit:
- **Wildcard (
.firma.de) vs. SAN (mehrere Domains in einem Zertifikat).* Wildcard ist bequem — ein Zertifikat deckt alle Subdomains. Aber wenn es abhandenkommt, ist der Schaden größer, weil es den ganzen Raum abdeckt. SAN gibt mehr Kontrolle, muss aber bei jeder neuen Subdomain aktualisiert werden. In einem KMU mit 5–10 Subdomains gewinnt meist SAN. In einer Firma, in der Subdomains wie Pilze aus dem Boden schießen, ist ein kurzlebiger Wildcard ein fairer Kompromiss. - Interne Zertifikate (eigene CA) für das LAN. Wenn ihr ein Dutzend interne Panels habt (Drucker, NAS, interne Apps), stellt eine kleine interne CA auf (z. B.
step-ca,smallstep) und verteilt die Root-CA per GPO / Intune an die Browser. Die Alternative — überall selbstsignierte Zertifikate, die der Browser ignoriert — trainiert das Team, „Trotzdem akzeptieren" zu klicken, und genau diesen Reflex wollt ihr nicht.
Wie geht es weiter
Fang mit vier Fragen an:
- Wann hat zuletzt jemand die Liste aller eurer TLS-Zertifikate geprüft — öffentliche und interne?
- Wo landen die Ablauf-Alarme? Im Postfach einer Einzelperson oder in einem Teamkanal?
- Welche Zertifikate werden manuell erneuert, und wer konkret hat das im Kalender?
- Wo liegen die privaten Schlüssel der kritischsten Zertifikate, und wer hat heute — nicht „historisch" — Zugang dazu?
Wenn eine der Antworten „ich bin mir nicht sicher" lautet — nimm es als Einladung, in dieser Woche die Inventur zu machen. Eine Stunde mit einer Person aus der IT reicht für einen ersten Entwurf. Wenn ihr Hilfe braucht, Monitoring und Erneuerungsprozedur aufzusetzen, wir helfen KMU regelmäßig dabei. Das erste Gespräch ist kostenlos und dauert eine halbe Stunde.
Das Zertifikat, an das sich niemand erinnert, läuft immer am Freitagabend ab. Nie am Mittwoch um 10:00.