Certificate Transparency: wie öffentliche Logs Zertifikate sichtbar machen

Certificate Transparency (CT) ist ein System öffentlicher Logs, in die Zertifizierungsstellen ihre TLS-Zertifikate eintragen. Die Logs wachsen nur an, Einträge werden nie gelöscht, und jeder kann sie lesen. So fallen falsch ausgestellte Zertifikate auf, und Browser wie Chrome akzeptieren öffentliche Zertifikate nur noch mit Nachweis eines Logeintrags.

Lange Glasvitrine in einer ruhigen Museumshalle mit einer Reihe kleiner versiegelter Umschläge unter weichem Licht
Bild: KI-generiert

Zertifizierungsstellen stellen jeden Tag sehr viele Zertifikate aus. Lange konnte niemand von außen sehen, ob darunter eines für eine fremde Domain war. Certificate Transparency macht diese Ausstellungen öffentlich und prüfbar. Das Verfahren haben Ben Laurie, Adam Langley und Emilia Kasper von Google im Juni 2013 als RFC 6962 beschrieben [1]. Die Version 2.0 steht seit Dezember 2021 in RFC 9162, das RFC 6962 ablöst. Beide sind als experimentell eingestuft [1, 2].

Wie ein CT-Log funktioniert

Ein Log ist ein Merkle-Baum, in dem jedes Zertifikat ein Blatt bildet. Neue Einträge werden nur angehängt [1]. Über die Hashwerte im Baum lässt sich nachweisen, dass eine neuere Fassung des Logs alle älteren Einträge enthält. Ein Log, das verschiedenen Prüfern verschiedene Inhalte zeigt, fällt dadurch auf [1].

Reicht eine Zertifizierungsstelle ein Zertifikat ein, bekommt sie sofort einen Signed Certificate Timestamp, kurz SCT. Damit verspricht das Log, das Zertifikat innerhalb einer festen Frist aufzunehmen [1]. Der Server liefert mindestens einen SCT mit dem Zertifikat aus, entweder im Zertifikat selbst, über eine TLS-Erweiterung oder über OCSP Stapling [1].

Wer die Logs prüft

RFC 6962 unterscheidet zwei Rollen. Monitore beobachten die Logs laufend und suchen nach Zertifikaten, die sie interessieren, etwa für die eigenen Domains. Auditoren prüfen, ob die Logs sich korrekt verhalten und ob ein bestimmtes Zertifikat wirklich darin steht [1]. Als Betreiber einer Website bist du in der Rolle des Monitors, wenn du nachsiehst, welche Zertifikate für deine Domain existieren.

Was Chrome verlangt

Chrome prüft öffentliche Zertifikate gegen eine eigene CT-Richtlinie. Bei SCTs im Zertifikat braucht ein Zertifikat mit bis zu 180 Tagen Laufzeit Einträge aus mindestens zwei verschiedenen Logs, bei längerer Laufzeit aus drei. Mindestens zwei davon müssen von verschiedenen Logbetreibern stammen [3]. Erfüllt ein Zertifikat das nicht, lehnt Chrome es ab [3]. Für dich heißt das: Jedes öffentlich vertrauenswürdige Zertifikat, das ein Besucher in Chrome ohne Warnung sieht, steht in öffentlichen Logs.

Folgen für Subdomains

Weil die Logs alle Namen im Zertifikat enthalten, werden damit auch Subdomains bekannt, etwa test.beispiel.de oder intern.beispiel.de. Genau das nutzt der Subdomain-Finder: Er fragt über die Suchmaschine crt.sh die Logs ab und listet jede Subdomain, für die es ein öffentliches Zertifikat gab. Der SSL-Check zeigt die zuletzt ausgestellten Zertifikate einer Domain. Wer interne Namen nicht preisgeben will, kann ein Wildcard-Zertifikat verwenden, dann steht nur *.beispiel.de im Log. Welche Stelle überhaupt für deine Domain ausstellen darf, legst du mit einem CAA-Eintrag fest. Wie Angreifer öffentliche Informationen über Firmen sammeln, beschreibt Social Engineering auf betrug.domain-root.de.

Lupe liegt auf einer großen leeren Landkarte, die auf einem Holztisch ausgebreitet ist, seitliches Lampenlicht
Bild: KI-generiert
  1. Gesetz RFC 6962: Certificate Transparency. IETF. Stand Juni 2013. abgerufen am 29.10.2026
  2. Gesetz RFC 9162: Certificate Transparency Version 2.0. IETF. Stand Dezember 2021. abgerufen am 29.10.2026
  3. Organisation Chrome Certificate Transparency Policy. Google Chrome. Stand laufend. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.

Weitere Artikel