TLS-Zertifikate mit Certificate Transparency prüfen: Logs, Aussteller, Umfang

Gültigkeit ist mehr als ein Ablaufdatum

Wer die Gültigkeit eines Zertifikats prüft, landet rasch bei Ablaufdatum und Signatur. Für die Frage, ob eine Ausstellung nachvollziehbar protokolliert und überprüfbar ist, kommen drei Achsen hinzu: das Register, in dem die Ausstellung festgehalten ist; der Aussteller, also die Zertifizierungsstelle, die signiert hat; und der Umfang – abgedeckte Domainnamen, Laufzeit und Verwendungszweck.

Für TLS-Zertifikate im Web bildet Certificate Transparency (CT) dieses Register. CT protokolliert und überwacht die Ausstellung von TLS-Zertifikaten und erlaubt jedermann, Ausstellungen zu prüfen. Der Eintrag ist kein Nebenaspekt: Chrome akzeptiert nur Zertifikate, die in einem CT-Log protokolliert wurden.

Die drei Achsen greifen unterschiedlich weit. Der Registereintrag belegt die Einreichung, nicht den Produktivbetrieb. Der Aussteller beantwortet, ob die erwartete Stelle ausgestellt hat. Der Umfang klärt, ob Namen, Laufzeit und Zweck zum Einsatz passen. Die folgenden Abschnitte behandeln sie in dieser Reihenfolge.

Certificate Transparency: das öffentliche Register für TLS-Zertifikate

Kern sind öffentlich zugängliche Certificate Transparency Logs, betrieben von Organisationen wie Google, Cloudflare oder kommerziellen Zertifizierungsstellen. Bei der Erstellung eines Zertifikats wird üblicherweise ein Precertificate mit allen relevanten Daten in ein solches Log geschrieben und öffentlich wieder abrufbar gemacht. Die Logs sind öffentlich einsehbar und bestehen aus verketteten Hashes (Merkle-Trees), was sie vor Manipulationen schützt. Weil die Einträge für unabhängige Dritte einsehbar sind, lässt sich eine Ausstellung nicht unbemerkt nachträglich verändern.

Der Nachweis, dass ein Zertifikat bei einem Log eingereicht wurde, steckt im Zertifikat selbst: Mit dem Unterschriftsfeld lässt sich prüfen, ob es eingereicht wurde. Das Feld enthält den Signed Certificate Timestamp (SCT), die Bestätigung des Logs über den Eingang. Ein Prüfwerkzeug liest den SCT aus und vergleicht ihn mit dem Log.

In der Praxis heisst das: Ein Zertifikat ohne gültigen SCT aus einem massgebenden Log ist für Browser mit CT-Pflicht nicht brauchbar, auch wenn Signatur und Laufzeit stimmen. Inzwischen ist davon auszugehen, dass praktisch jedes weltweit ausgestellte Serverzertifikat mit Browser-Verankerung in den Logs erscheint.

Welche Logs zählen – und wann ein SCT nichts beweist

Es gibt nicht ein einziges Register, sondern eine Landschaft konkurrierender und sich ergänzender Logs. Let's Encrypt sendet alle ausgestellten Zertifikate an CT-Logs und betreibt selbst zwei öffentliche Logs namens Oak und Sapling. Oak ist in die CT-Programme von Apple und Google integriert, und die Produktions-ACME-Umgebung von Let's Encrypt übermittelt Zertifikate dorthin. Massgebend ist somit nicht irgendein Log, sondern eines, das der jeweilige Browser akzeptiert: In einem Beitrag von 2021 nannte die DFN-PKI 30 Logs, die Chrome akzeptiert.

Neben Produktionslogs existieren Testlogs, deren SCTs nicht gleichwertig sind. Let's Encrypt hält fest, dass SCTs aus diesen Testlogs nicht in öffentlich vertrauenswürdige Zertifikate eingefügt werden sollen. Sapling erhält Zertifikate sowohl aus der Produktions- als auch aus der Staging-ACME-Umgebung, doch die Produktionsumgebung verwendet die daraus resultierenden SCTs nicht; Sapling kann von anderen Zertifizierungsstellen für Testzwecke genutzt werden. Dasselbe gilt für die von Let's Encrypt getesteten, auf Sunlight basierenden Logs. Twig bleibt als Testlog erhalten und akzeptiert dieselben CAs wie Sapling. Willow und Sycamore akzeptieren dieselben CAs wie Oak und sollen zu Produktionslogs werden.

Daraus folgt für die Prüfung: Ein SCT allein belegt nicht, dass ein Zertifikat öffentlich vertrauenswürdig ist – er kann aus einem Testlog stammen. Zu prüfen ist, ob das Log auf der aktuell akzeptierten Liste steht. Log-Lebenszyklen ändern sich; Let's Encrypt verweist für Informationen zum Lebenszyklus seiner Logs auf eine eigene Übersicht. Wer Prüfregeln festlegt, sollte die akzeptierte Liste periodisch nachführen statt eine einmal kopierte Liste zu verwenden.

Produktionslog oder Testlog: nicht jeder SCT ist gleichwertig

Abfragen statt selbst mitlesen

Für punktuelle Prüfungen genügt ein Aggregator. crt.sh fragt kontinuierlich alle relevanten CT-Logs ab und bereitet die Daten leicht konsumierbar auf; der Dienst wird von Sectigo, einem CA-Anbieter, betrieben. crt.sh bietet ein einfaches API, um zu einer Domain ausgestellte Zertifikate zu erhalten, und liefert die Ergebnisse auf Wunsch als JSON. Weitere Angebote, die CT-Logs abfragen und aufbereiten, stammen von Censys.io, Cloudflare, sslmate, Google und Facebook, teilweise kostenpflichtig.

Wer nicht auf einen Fremddienst abstellen will, kann die Logs direkt untersuchen. Mit certspotter steht dafür fertige Software für den Selbstbetrieb zur Verfügung.

Der Selbstbetrieb verlangt jedoch Konzept und Ressourcen. Aufgrund der Menge weltweit ausgestellter Serverzertifikate kann der Bedarf insbesondere an Bandbreite beträchtlich sein. Einige Logs wachsen um mehrere hundert Zertifikate pro Sekunde, liefern mitunter aber nicht in entsprechender Rate aus, so dass es teilweise gar nicht möglich ist, die im Log vorhandenen Zertifikate kontinuierlich zu überwachen. Auch Aggregatoren haben Grenzen: crt.sh weist auf Limitierungen bei der Ergebnisgrösse hin. Für eine einmalige Abfrage genügt ein Aggregator; für Dauerbetrieb über viele Domains braucht es eine eigene Architektur und genügend Übertragungskapazität.

Die eigene Domain im Blick behalten

Das Register lässt sich für die eigene Organisation nutzen. Es dient als weitere Datenbasis für das organisations-eigene Zertifikatsmanagement und zur schnellen Erkennung fälschlich oder betrügerisch ausgestellter Zertifikate.

Ausserdem dient es als zentrales Monitoring über die in der Organisation eingesetzten CAs. Es hilft, zusätzliche Zertifikate im Zusammenhang mit CDN- oder Cloud-Diensten zu erkennen.

Gerade der letzte Punkt ist praktisch: Zertifikate, die über einen vorgelagerten Dienst dazukommen, tauchen im eigenen Inventar oft nicht auf, im Log aber schon.

Die DFN-PKI nutzt dieses System seit 2018. Weil praktisch jedes weltweit ausgestellte Serverzertifikat mit Browser-Verankerung in den Logs erscheint, ist die Abdeckung für öffentlich vertrauenswürdige Zertifikate hoch.

Die Erkennung falsch ausgestellter Zertifikate steht unter einer Bedingung: Die Mechanismen der CA zum Schreiben in die CT-Logs müssen intakt sein, also vom Angreifer nicht überwunden worden sein. Ist diese Voraussetzung erfüllt, liefert die laufende Abfrage der Logs zu den eigenen Domains ein Frühwarnsignal, das unabhängig von der CA-eigenen Kommunikation funktioniert.

Umfang: was die Prüfung nicht abdeckt

Zertifikate aus internen CAs, die nicht per Default im Browser oder Betriebssystem als vertrauenswürdig erscheinen, werden mit Certificate Transparency nicht erfasst. Für solche Zertifikate – etwa innerhalb einer Organisation, zwischen Systemen oder in einer eigenen PKI – liefert das Register keinen Nachweis; dort braucht es eigene Prüfwege, etwa eine eigene Ausstellungsübersicht und eine eigene Vertrauensliste.

Ein gültiger Logeintrag belegt die Einreichung des Zertifikats, nicht dessen Einsatz. Ob das Zertifikat tatsächlich auf einem Server ausgeliefert wird, ob der private Schlüssel dazu passt und ob die Konfiguration korrekt ist, lässt sich daraus nicht ableiten. Diese Fragen beantwortet nur der eigene Betrieb – über ein Inventar der eingesetzten Zertifikate und eine Kontrolle der Serverkonfiguration.

Auch die Aussage des Zertifikats selbst ist begrenzt: Zertifikate garantieren in der Regel, dass man mit einer bestimmten Domain kommuniziert, aber nicht mit dem richtigen Unternehmen oder der richtigen Organisation. Ein Zertifikat kann gefälscht sein und der Server kann sich damit für jemanden ausgeben, der er nicht ist. CT macht gefälschte oder betrügerische Zertifikate leichter erkennbar, ersetzt aber keine Prüfung der Organisation hinter einer Domain.

Zusätzlich kontrolliert werden muss bei Zertifikaten aus internen CAs, bei Zertifikaten, deren tatsächlicher Einsatz belegt werden soll, und immer dann, wenn die Domain-Angabe für den Geschäftsvorfall nicht genügt. In diesen Fällen kommen Nachweise ausserhalb des Registers dazu, die direkt beim Aussteller oder im eigenen Betrieb erhoben werden.

Drei Prüfschritte, die zusammenpassen müssen

Erster Schritt: Eintrag im Register prüfen. Der SCT im Unterschriftsfeld muss aus einem Log stammen, das der Browser akzeptiert – nicht aus einem Testlog wie Sapling, Twig oder einem Sunlight-basierten Log. Zweiter Schritt: Aussteller prüfen. Die signierende Zertifizierungsstelle muss die erwartete sein; unerwartete Aussteller für die eigenen Domains sind ein Warnsignal. Dritter Schritt: Umfang prüfen. Abgedeckte Domainnamen, Laufzeit und Verwendungszweck müssen zum geplanten Einsatz passen.

Diese Reihenfolge lässt sich als wiederkehrende Routine in ein bestehendes Zertifikatsmanagement einhängen: die Registerabfrage für die eigenen Domains laufend, die Aussteller- und Umfangsprüfung bei jeder Neuausstellung und bei jeder Inventur. Punktuell genügt eine Abfrage bei einem Aggregator wie crt.sh; für den Dauerbetrieb braucht es eine eigene Lösung mit ausreichender Bandbreite. Beide Wege liefern dasselbe Ergebnis: einen Registereintrag, der zusammen mit Aussteller und Umfang die Gültigkeit belegt.