Datahorses

Certificate Transparency Logs: was sie über Ihre Domains verraten

Von · · 4 Min. Lesezeit

Certificate Transparency (CT) ist ein System aus Logs, in die nur angefügt werden kann und die TLS-Zertifikate aufzeichnen, sobald Zertifizierungsstellen sie ausstellen. Jeder kann diese Logs lesen. Für Ihr Unternehmen bedeutet das 2 Dinge: Die Logs zeigen allen, für welche Hostnamen Sie Zertifikate haben, und sie lassen Sie ein Zertifikat für Ihre Domain bemerken, das auf Ihrer Seite niemand beantragt hat.

Das Protokoll wurde erstmals in RFC 6962 (Juni 2013) beschrieben und als Version 2.0 in RFC 9162 (Dezember 2021) aktualisiert. Beide sind Experimental RFCs, doch Browser stützen sich in der Praxis auf CT: Chrome verlangt, dass allgemein vertrauenswürdige TLS-Zertifikate CT-konform sind, und Apple hat eine eigene CT-Richtlinie für seine Plattformen.

Vertraut ein Browser also einem Zertifikat für yourcompany.com, gibt es dafür fast sicher einen Log-Eintrag.

Was die Logs über Ihr Unternehmen verraten

Ein CT-Eintrag enthält die Namen, die das Zertifikat abdeckt, die ausstellende Stelle und die Gültigkeitsdaten. Zusammengenommen zeigen die Einträge für Ihre Domain:

  • Ihre Subdomains. vpn.yourcompany.com, jira.yourcompany.com, staging-api.yourcompany.com: jeder Name, der jemals ein eigenes Zertifikat hatte.
  • Ihre Dienstleister. Aussteller und Namensmuster lassen oft erkennen, welche Hosting-, Mail- oder SaaS-Plattformen Sie nutzen.
  • Ihre Geschichte. Alte Einträge bleiben im Log, sodass Namen aus vor Jahren eingestellten Projekten sichtbar bleiben.
  • Neue Zertifikate, sobald sie erscheinen. Ein neuer Eintrag für einen Namen, den Sie nicht kennen, oder von einer Stelle, die Sie nicht nutzen, verdient eine Nachfrage.

Nichts davon ist ein Fehler von CT. Der Sinn des Systems ist, dass falsch ausgestellte Zertifikate nicht verborgen bleiben können. Die Folge ist, dass Ihre Liste von Hostnamen nicht privat ist, also lesen Sie sie besser, bevor es jemand anderes tut.

So durchsuchen Sie die Logs selbst

Am einfachsten geht es mit crt.sh, einer Suchoberfläche für CT-Logs. Geben Sie Ihre Domain ein oder nutzen Sie % als Platzhalter, um alle Subdomains einzuschließen:

https://crt.sh/?q=%25.yourcompany.com

Für eine weiterverarbeitbare Liste hängen Sie &output=json an:

curl -s 'https://crt.sh/?q=%25.yourcompany.com&output=json' \
  | jq -r '.[].name_value' | sort -u

Achten Sie beim Lesen der Ergebnisse auf:

  • Namen, die niemand kennt. Jeder sollte zu einem System mit bekanntem Verantwortlichen gehören.
  • Test- und Staging-Namen wie dev, test, old, beta. Sie verweisen oft auf vergessene Staging-Server.
  • Namen, die nicht mehr auflösen oder auf eine Plattform zeigen, die Sie verlassen haben. Prüfen Sie diese auf Dangling DNS und Subdomain Takeover.
  • Unerwartete Aussteller. Ein Zertifikat von einer Stelle, die Sie nie genutzt haben, sollten Sie mit dem Team klären, das Ihr DNS und Hosting betreut.
  • Aktuelle Daten, die Sie nicht erklären können. Ein frisches, von niemandem beantragtes Zertifikat für Ihren wichtigsten Login-Hostnamen ist der dringendste Fall.

Beachten Sie, dass Wildcard-Zertifikate (*.yourcompany.com) keine einzelnen Subdomains auflisten. Die Logs zeigen Ihnen also viel, aber nicht alles.

Wer ausstellen darf: der CAA-Eintrag

Mit einem CAA-Eintrag, definiert in RFC 8659, legen Sie fest, welche Zertifizierungsstellen für Ihre Domain ausstellen dürfen. Die Stellen prüfen ihn vor der Ausstellung. Eine typische Konfiguration:

yourcompany.com.  CAA 0 issue "letsencrypt.org"
yourcompany.com.  CAA 0 issuewild ";"
yourcompany.com.  CAA 0 iodef "mailto:security@yourcompany.com"

Das erlaubt eine Stelle, verbietet Wildcard-Zertifikate und nennt eine Adresse für Meldungen. CAA ersetzt CT nicht: Es schränkt ein, was ausgestellt werden kann, während CT zeigt, was tatsächlich ausgestellt wurde.

Zertifikate werden kürzer, die Logs voller

Gemäß CA/Browser Forum Ballot SC-081, inzwischen Teil der Baseline Requirements, beträgt die maximale Gültigkeit allgemein vertrauenswürdiger TLS-Zertifikate 200 Tage für Zertifikate ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und ab dem 15. März 2029 nur noch 47. Erneuerungen werden häufiger und meist automatisiert, Ihre Domains erzeugen also mehr CT-Einträge. Das macht manuelles Lesen unpraktischer und eine klare Basis „erwarteter“ Zertifikate wertvoller. Zur Erneuerungsseite dieser Änderung lesen Sie warum abgelaufene Zertifikate noch immer Websites lahmlegen.

Was tun, wenn Sie etwas Unerwartetes finden

  1. Klären Sie, wem es gehört. Fragen Sie IT, Marketing und Ihre Agenturen, ob sie das Zertifikat beantragt haben.
  2. Wenn niemand es war, kontaktieren Sie die ausstellende Stelle. Jede bietet einen Weg, falsch ausgestellte Zertifikate zu melden und einen Widerruf zu beantragen.
  3. Prüfen Sie DNS und Registrar. Ein unerwartetes Zertifikat kann auf eine DNS-Änderung folgen, gehen Sie also die Punkte aus unserem Artikel zu Nameserver- und Registrar-Änderungen durch.
  4. Ergänzen oder verschärfen Sie CAA, damit dieselbe Stelle nicht ohne Ihre Zustimmung erneut ausstellen kann.

Eine kurze Checkliste

  • Durchsuchen Sie crt.sh nach %.yourcompany.com und speichern Sie die Liste der Namen.
  • Ordnen Sie jedem Namen ein System und einen Verantwortlichen zu.
  • Entfernen oder korrigieren Sie Namen, die ins Leere zeigen.
  • Veröffentlichen Sie einen CAA-Eintrag mit den Stellen, die Sie nutzen.
  • Prüfen Sie neue Einträge regelmäßig, nicht einmal im Jahr.

Wo Datahorses ins Bild passt

Datahorses beobachtet Ihr Unternehmen jeden Tag von außen, und Certificate Transparency gehört zu den Dingen, die wir für Sie lesen: neue Zertifikate für Ihre Domains, neue Subdomains und die CAA-Einträge, die sie begrenzen sollten. Wir dringen nicht in Ihre Systeme ein und benötigen keine Zugänge. Wenn etwas nicht stimmt, erhalten Sie den Fund mit klaren Schritten, wie unter was passiert, wenn wir etwas finden beschrieben. Die vollständige Liste dessen, was wir überwachen, finden Sie auf der Startseite.

Weitere Artikel

Alle Artikel