Certificate Transparency erklärt: Was CT-Logs sind und warum sie wichtig sind

Certificate Transparency (CT) ist ein öffentliches, manipulationssicheres Protokollierungssystem, das jedes öffentlich vertrauenswürdige TLS-Zertifikat bei seiner Ausstellung erfasst. So kann jeder, auch du, prüfen, ob ohne dein Wissen ein Zertifikat für deine Domain erstellt wurde. CT verhindert nicht, dass eine abtrünnige oder kompromittierte Zertifizierungsstelle (CA) ein fehlerhaftes Zertifikat ausstellt. Es macht diese Fehlausstellung aber fast sofort sichtbar, statt dass sie monatelang verborgen bleibt.

Wenn du die CT-Logs für deine eigenen Domains noch nie geprüft hast, verlässt du dich vollständig darauf, dass deine CA korrekt arbeitet und nie gehackt wird. CT gibt dir eine unabhängige Möglichkeit, das zu überprüfen.

Was ist Certificate Transparency genau?

CT wurde ursprünglich in RFC 6962 (2013) definiert und später in RFC 9162 (Certificate Transparency Version 2.0, 2021) als IETF-Standard festgeschrieben. Die Grundidee: CAs reichen jedes Zertifikat, oder eine „Precertificate“-Version davon, vor oder bei der Ausstellung bei einem oder mehreren unabhängig betriebenen CT-Logs ein.

Jedes Log ist ein nur erweiterbarer, kryptografisch überprüfbarer Merkle-Baum. Ist ein Eintrag einmal hinzugefügt, lässt er sich nicht bearbeiten oder stillschweigend löschen, ohne den mathematischen Beweis des Baums zu zerstören, und jeder, der einen Monitor betreibt, kann eine solche Manipulation erkennen. Genau das macht CT-Logs vertrauenswürdig, obwohl jeder Einträge einreichen kann und die Log-Betreiber selbst keine CAs sind.

Drei Rollen sorgen dafür, dass das System funktioniert:

• Logs: Server, die Einreichungen annehmen und einen Inklusionsnachweis zurückgeben.
• Monitore: Dienste (oder Skripte), die Logs auf Zertifikate für die Domains überwachen, die sie interessieren.
• Auditoren: Clients (oft in Browser integriert), die prüfen, ob der Merkle-Baum eines Logs in sich konsistent ist und nicht verändert wurde.

Was ist ein SCT und warum ist er wichtig?

Wenn ein Log ein Zertifikat annimmt, gibt es einen Signed Certificate Timestamp (SCT) zurück: ein kryptografisches Versprechen, dass das Zertifikat innerhalb einer festgelegten Maximum Merge Delay (MMD), historisch etwa 24 Stunden, im Log erscheint. Der SCT kann auf drei Wegen ausgeliefert werden: direkt eingebettet im endgültigen Zertifikat, über eine TLS-Erweiterung während des Handshakes oder per OCSP-Stapling.

Moderne Browser verlangen eine Mindestanzahl gültiger SCTs aus Logs verschiedener, unabhängiger Betreiber, bevor sie einem öffentlich ausgestellten Zertifikat vertrauen. Chrome setzt CT-Konformität für alle öffentlich vertrauenswürdigen Zertifikate durch, die seit dem 30. April 2018 ausgestellt wurden. Ein Zertifikat ohne qualifizierende SCTs wird schlicht nicht als vertrauenswürdig eingestuft, egal wer es signiert hat.

NoteCT ersetzt die Vertrauenskette der Zertifikate nicht, sondern ergänzt sie. Wie diese Kette tatsächlich funktioniert, kannst du in SSL-Zertifikate erklärt nachlesen.

Wofür CT-Logs in der Praxis nützlich sind

Der praktische Nutzen für alle, die Infrastruktur betreiben, liegt nicht in der Kryptografie, sondern in der Transparenz. Mit CT-Logs kannst du:

• Unautorisierte Zertifikate aufspüren, die für deine Domain oder Subdomains von einer CA ausgestellt wurden, die du nie genutzt hast.
• Schatten-Subdomains entdecken: Eine CT-Suche fördert oft vergessene Staging-, Test- oder interne Hostnamen zutage, für die stillschweigend ein öffentliches Zertifikat ausgestellt wurde.
• Das Verhalten von CAs prüfen, nachdem ein Sicherheitsvorfall oder eine Fehlausstellung öffentlich bekannt wurde, indem du die Logs nach betroffenen Zertifikaten für deine Domains durchsuchst.
• Missbrauch von Wildcard-Zertifikaten erkennen, wenn ein Wildcard-Zertifikat für deine Domain aus einer Quelle auftaucht, die du nicht kennst.

Das ist besonders für Organisationen mit mehreren Teams und für Agenturen relevant, die viele Domains bei verschiedenen Registraren und Cloud-Anbietern verwalten. Dort kann es passieren, dass ein Entwickler ein Zertifikat über einen nicht freigegebenen Anbieter beantragt, ohne dass es jemand bemerkt.

Wie prüfst du CT-Logs konkret?

Du musst keinen eigenen Log-Monitor betreiben, um von CT zu profitieren. Einige praktische Möglichkeiten:

1. Durchsuche öffentliche CT-Log-Aggregatoren (crt.sh und ähnliche Dienste) nach deiner Domain, um jedes Zertifikat zu sehen, das jemals dafür protokolliert wurde.
2. Prüfe die SCTs eines Live-Zertifikats direkt mit unserem SSL-Check-Tool: Es zeigt dir die Zertifikatskette und die Gültigkeit, sodass du bestätigen kannst, was in der Produktion tatsächlich ausgeliefert wird.
3. Richte eine fortlaufende Überwachung ein, damit du sofort benachrichtigt wirst, sobald ein neues Zertifikat für deine Domain auftaucht, statt nur ab und zu manuell nachzusehen.

Hier ein vereinfachtes Beispiel dafür, wie ein Suchergebnis in den CT-Logs für eine Domain aussieht:

Genau nach der dritten Zeile suchst du: ein Zertifikat, das du nicht beantragt hast, von einer CA, die du nicht kennst. Wenn du so etwas für eine Domain siehst, die du kontrollierst, widerrufe das Zertifikat und stelle sofort ein neues aus. Untersuche außerdem, wie der Antragsteller die Domain-Validierung bestehen konnte.

TipWenn du Zertifikate bei mehreren Anbietern verwaltest, kombiniere die Prüfung der CT-Logs mit einer aktiven Überwachung des Ablaufdatums. Unter Zertifikatsverwaltung behältst du Verlängerungstermine und den Zustand der Zertifikatskette in einem Dashboard im Blick, statt in den Konsolen der einzelnen Anbieter.

Verhindert CT fehlerhaft ausgestellte Zertifikate?

Nein, und genau das wird am häufigsten missverstanden. CT ist erkennend, nicht vorbeugend. Eine bösartige oder kompromittierte CA kann weiterhin ein fehlerhaftes Zertifikat ausstellen. CT garantiert lediglich, dass diese Ausstellung öffentlich sichtbar wird, in der Regel innerhalb von etwa 24 Stunden (der MMD), statt auf unbestimmte Zeit verborgen zu bleiben. Die eigentliche Schutzebene sind CAA-Einträge, die CAs mitteilen, welche von ihnen überhaupt für deine Domain ausstellen dürfen. Falls du die noch nicht gesetzt hast, bringt dir das mehr und kostet weniger als CT-Monitoring allein. Die CAA-Syntax findest du im Leitfaden zu DNS-Eintragstypen.

Im Zusammenspiel senkt CAA das Risiko einer Fehlausstellung, und das Monitoring der CT-Logs fängt alles ab, was trotzdem durchrutscht. Keines von beiden ist allein eine vollständige Lösung.

CT-Logs vs. allgemeines SSL-Monitoring

Es lohnt sich, klar zu unterscheiden, was dir jede Ebene tatsächlich verrät:

Die Suche in CT-Logs ist rückblickend und umfasst die gesamte Domain; Live-SSL-Checks sind Momentaufnahmen für einen bestimmten Host. Du brauchst beides. Für die Monitoring-Seite erklärt Website-Monitoring erklärt, wie Uptime- und SSL-Ablaufprüfungen zusammenspielen.

So startest du mit der CT-Überwachung

Wenn du mehr als eine Handvoll Domains verwaltest, reicht eine manuelle Suche auf crt.sh einmal im Quartal nicht aus. Zertifikate werden laufend ausgestellt, und ein bösartiges kann monatelang aktiv sein, bevor es jemand bemerkt. Der realistische Ansatz: Wisse, welche CAs du tatsächlich nutzt, achte auf alles außerhalb dieser Liste, und halte Ablaufdaten und den Zustand der Zertifikatsketten unter aktiver Überwachung, statt erst zu reagieren, wenn etwas kaputtgeht.

Prüfe jetzt sofort eine beliebige Domain mit dem kostenlosen SSL-Check-Tool, oder bündle die Zertifikatsüberwachung über alle Anbieter hinweg in der Zertifikatsverwaltung von InfraNest, damit du dich nicht auf dein Gedächtnis verlassen musst, um zu erkennen, was die CT-Logs längst wissen.