Certificate Transparency einfach erklärt: Logs, SCTs und Monitoring

Jede Zertifizierungsstelle, der Ihr Browser vertraut, kann technisch für jede Domain ein Zertifikat ausstellen, auch für Ihre. Wie würden Sie merken, wenn das jemand zu Unrecht tut? Die Antwort heißt Certificate Transparency (CT): Jedes öffentlich vertraute Website-Zertifikat muss in mehrere öffentliche, nur erweiterbare Protokolle eingetragen werden, die jeder durchsuchen kann. Dieser Artikel erklärt, warum CT entstanden ist, wie ein Zertifikat ins Log kommt, was SCTs sind, wie Merkle-Bäume Manipulation verhindern und wie Sie Ihre eigene Domain überwachen.

Das Problem: falsch ausgestellte Zertifikate

2011 brachen Angreifer bei der niederländischen CA DigiNotar ein und stellten unter anderem ein Zertifikat für alle Google-Domains aus. Damit ließen sich verschlüsselte Verbindungen im Iran mitlesen, ohne dass der Browser warnte. Aufgefallen ist das nur, weil Chrome für Google-Domains feste Schlüssel kannte. Für alle anderen Domains hätte niemand den Betrug bemerkt: Eine CA konnte Zertifikate ausstellen, ohne dass der Domaininhaber je davon erfuhr. Welche CAs überhaupt vertraut werden, erklärt Root Stores einfach erklärt.

Die Idee: ein öffentliches Logbuch für alle Zertifikate

Google-Ingenieure entwickelten daraufhin Certificate Transparency, 2013 als RFC 6962 veröffentlicht. Die Idee: Zertifikate gelten nur, wenn sie öffentlich protokolliert sind. Dazu gibt es CT-Logs, Server unabhängiger Betreiber wie Google, Cloudflare, DigiCert, Sectigo oder Let’s Encrypt. Ein Log nimmt Zertifikate an, kann aber nichts unbemerkt löschen oder ändern. Jeder kann die Logs lesen, und Monitore durchsuchen sie laufend nach auffälligen Einträgen.

CT verhindert keine Fehlausstellung, macht sie aber sichtbar. Chrome verlangt CT für alle Zertifikate, die nach dem 30. April 2018 ausgestellt wurden, Apple seit dem 15. Oktober 2018. Ein Zertifikat ohne gültige Log-Nachweise lehnen diese Browser ab.

Wie ein Zertifikat ins Log kommt

Die CA erzeugt zuerst ein Vorzertifikat (Precertificate): Es enthält alle Daten des späteren Zertifikats, ist aber durch eine besondere Erweiterung als unbrauchbar markiert. Dieses Vorzertifikat reicht die CA bei mehreren Logs ein. Jedes Log antwortet sofort mit einem Signed Certificate Timestamp (SCT), einem signierten Versprechen, das Zertifikat innerhalb von 24 Stunden aufzunehmen. Die CA bettet die SCTs in das endgültige Zertifikat ein, signiert es und liefert es aus. Wie eine CA sonst arbeitet, beschreibt Zertifizierungsstelle (CA) einfach erklärt.

Vier Schritte: Vorzertifikat, Einreichung bei mehreren CT-Logs, signierte Quittungen (SCTs), endgültiges Zertifikat mit eingebetteten SCTs. — Der Weg eines Zertifikats in die Certificate-Transparency-Logs.

SCTs: die Quittungen im Zertifikat

Der Browser prüft beim Verbindungsaufbau, ob das Zertifikat genügend gültige SCTs enthält. Chrome verlangt bei eingebetteten SCTs:

2 SCTs von verschiedenen Logs bei einer Laufzeit bis 180 Tage,
3 SCTs bei einer Laufzeit über 180 Tage,
dabei mindestens zwei verschiedene Log-Betreiber, damit kein einzelnes Unternehmen allein bestätigen kann.

Das Zertifikat von techuni.de mit 90 Tagen Laufzeit enthält genau zwei SCTs. Die Felder sieht man in der Zertifikatsansicht des Browsers oder mit OpenSSL; siehe X.509-Zertifikat einfach erklärt. SCTs können auch während des TLS-Handshakes geliefert werden; eingebettet ist aber der übliche Weg.

Tabelle: Bei bis zu 180 Tagen Laufzeit sind 2 SCTs nötig, darüber 3, jeweils von mindestens zwei Betreibern; das 90-Tage-Zertifikat von techuni.de hat 2. — Die SCT-Regeln von Chrome für eingebettete SCTs.

Merkle-Bäume: warum niemand heimlich löschen kann

Damit ein Log nichts nachträglich entfernen kann, ist es als Merkle-Baum aufgebaut: Jedes Zertifikat ergibt einen Hashwert, je zwei Hashwerte werden zu einem neuen zusammengefasst, und so weiter bis zur Wurzel. Der Hash der Wurzel steht damit für den gesamten Inhalt. Das Log veröffentlicht regelmäßig eine signierte Wurzel (Signed Tree Head).

Beispiel mit vier Zertifikaten A bis D: Aus H(A) und H(B) wird H(AB), aus H(C) und H(D) wird H(CD), und daraus die Wurzel H(ABCD). Um zu beweisen, dass C enthalten ist, genügen H(D) und H(AB): Wer daraus die Wurzel nachrechnet, weiß, dass C dazugehört. Bei einer Million Einträgen sind dafür nur rund 20 Hashwerte nötig, weil 2²⁰ ≈ 1 Million. Ein zweiter Beweis zeigt, dass eine neue Wurzel alle alten Einträge enthält. Würde ein Log einen Eintrag löschen, passte die Rechnung nicht mehr. Zu Hashfunktionen siehe Hashfunktionen einfach erklärt, zum Zusammenhang zwischen Einträgen und Beweislänge Logarithmus einfach erklärt.

Baum mit vier Blättern H(A) bis H(D), zwei Zwischenknoten H(AB) und H(CD) und der Wurzel H(ABCD); für den Nachweis von C sind H(D) und H(AB) hervorgehoben. — Ein Merkle-Baum: kurzer Nachweis, dass ein Eintrag enthalten ist.

Monitoring: die eigene Domain überwachen

Der größte Nutzen von CT für Website-Betreiber: Sie können sehen, welche Zertifikate für ihre Domains existieren.

crt.sh ist eine kostenlose Suchmaschine für CT-Logs. Für techuni.de zeigte sie im November 2026 110 Einträge seit Juni 2018. Gültig waren vier: das aktuelle Let’s-Encrypt-Zertifikat zweimal (Vorzertifikat und endgültiges Zertifikat), ein Wildcard-Zertifikat von Google Trust Services, das über den DNS-Anbieter Cloudflare bestellt wurde, und ein Zertifikat für weitere Subdomains.
Benachrichtigungsdienste wie Cert Spotter oder die CT-Überwachung von Cloudflare schicken eine E-Mail, sobald ein neues Zertifikat für eine Domain auftaucht.

Taucht ein Zertifikat auf, das Sie nicht bestellt haben, sollten Sie die ausstellende CA kontaktieren. Wie CT schon geholfen hat: 2015 fiel so auf, dass Symantec ohne Erlaubnis Testzertifikate für google.com ausgestellt hatte, was später zum Vertrauensentzug beitrug. CT-Monitore helfen auch, Phishing-Domains zu finden, die bekannten Namen ähneln; siehe Phishing erkennen.

Nebenwirkung: Subdomains werden öffentlich

Weil jedes Zertifikat öffentlich wird, sind auch alle darin enthaltenen Namen öffentlich, etwa intern.firma.de oder test.firma.de. Angreifer werten die Logs laufend aus und rufen neue Domains oft wenige Minuten nach der Ausstellung auf, zum Beispiel um halb eingerichtete Installationen zu übernehmen. Daraus folgt:

Keine vertraulichen Projektnamen in Zertifikatsnamen verwenden.
Neue Server erst absichern, dann das Zertifikat beantragen.
Für interne Namen eine eigene, private CA nutzen, deren Zertifikate nicht protokolliert werden.
Ein Wildcard-Zertifikat verrät einzelne Subdomain-Namen nicht, hat aber andere Nachteile.

Häufige Fragen

Muss ich als Website-Betreiber selbst etwas eintragen? Nein. Die CA erledigt das bei jeder Ausstellung automatisch.

Gilt CT auch für private Zertifikate? Nein. Zertifikate einer eigenen Firmen-CA werden nicht protokolliert und von Browsern auch nicht darauf geprüft, solange die Root manuell installiert wurde.

Kann man Einträge aus einem CT-Log löschen lassen? Nein. Logs sind nur erweiterbar, das ist der Kern des Verfahrens.

Wer betreibt die Logs? Einige große Unternehmen und CAs. Browser führen eine Liste anerkannter Logs und entfernen Logs, die ihre Regeln verletzen.

Fazit

Certificate Transparency macht jede Ausstellung eines öffentlichen Website-Zertifikats nachprüfbar. CAs tragen Vorzertifikate in mehrere Logs ein, betten die Quittungen ins Zertifikat ein, und Merkle-Bäume sorgen dafür, dass nichts heimlich verschwindet. Für Betreiber lohnt ein Blick auf crt.sh oder eine Benachrichtigung bei neuen Zertifikaten. Mehr in der Übersicht Verschlüsselung und IT-Sicherheit.