Certificate Transparency (CT)

Du gibst deinem NAS unter nas.home.example.com ein echtes Zertifikat und erzählst niemandem davon. Öffentlich ist der Name trotzdem – das Zertifikat wurde veröffentlicht, mit Absicht.

Kurz gesagt

Certificate Transparency (CT) ist ein System öffentlicher Logs, in die TLS-Zertifikate nur angehängt werden, damit jeder nachprüfen kann, was Zertifizierungsstellen ausstellen [1][2]. Browser wie Chrome und Safari akzeptieren öffentlich vertrauenswürdige Zertifikate nur mit Nachweis der Protokollierung [1][4]. Warum tauchen deine Subdomains auf? Jedes Zertifikat nennt die Namen, für die es gilt, und jeder kann die Logs abfragen; so wird jeder Hostname in einem öffentlichen Zertifikat sichtbar, auch interne [1]. Unsere Einschätzung: CT hilft dir als Domaininhaber, solange du Namen, die privat bleiben sollen, aus öffentlichen Zertifikaten heraushältst.

So funktioniert’s

1. Logs, die nur wachsen. Ein CT-Log ist ein Verzeichnis von Zertifikaten, an das nur angehängt wird. Es ist als Merkle-Baum aufgebaut, sodass jeder ein Log abfragen und prüfen kann, ob es sich korrekt verhält [1][2].
2. Die Quittung. Reicht eine Zertifizierungsstelle ein Vorzertifikat ein, gibt das Log einen Signed Certificate Timestamp (SCT) zurück, das Versprechen, das Zertifikat innerhalb der Maximum Merge Delay aufzunehmen, meist 24 Stunden [1]. Meist steckt der SCT im Zertifikat selbst; OCSP-Stapling und eine TLS-Erweiterung sind seltenere Wege [1].
3. Browser prüfen. Safari und Chrome verlangen mindestens zwei SCTs, je nach Laufzeit des Zertifikats [1]. Chrome verlangt CT für alle öffentlich vertrauenswürdigen TLS-Zertifikate, die nach dem 30. Apr. 2018 ausgestellt wurden [4].
4. Wer protokolliert. Let’s Encrypt reicht jedes ausgestellte Zertifikat bei CT-Logs ein und betreibt eigene Logs, Sycamore und Willow, auf Basis von Sunlight; die älteren Logs nach RFC 6962 sind am Ende ihrer Laufzeit [3].
5. Die Normen. RFC 9162 vom Dezember 2021 beschreibt CT in Version 2.0 als experimentelles Protokoll und ersetzt RFC 6962 [2]. Die Richtlinie von Chrome verweist weiterhin auf RFC 6962, erweitert um die static-ct-api [4].
6. Überwachen. Monitore sind öffentlich betriebene Server, die regelmäßig alle Logs abrufen und nach verdächtigen Zertifikaten suchen; Domaininhaber können sie abonnieren oder selbst einen betreiben [1]. RFC 9162 beschreibt genau diesen Zweck: prüfen, ob für Domains, für die du verantwortlich bist, unerwartete Zertifikate ausgestellt wurden [2].
7. Die Nebenwirkung. Unsere Lesart: Weil die Logs öffentlich sind, verrät ein Zertifikat für nas.home.example.com jedem, dass es diesen Namen gibt. Ein Wildcard-Zertifikat für *.home.example.com zeigt nur die Wildcard, nicht die Namen der einzelnen Dienste.

Ein Praxisbeispiel

Dein Homelab, also deine eigenen Server zu Hause, nutzt Namen wie nas.home.example.com hinter einem Reverse Proxy. Statt eines Zertifikats je Dienst beantragst du ein einziges Wildcard-Zertifikat für *.home.example.com; bei Let’s Encrypt geht das nur mit der DNS-01-Challenge, die unser Eintrag dazu erklärt. In den Logs steht dann *.home.example.com, aber nicht, welche Dienste dahinter laufen. Danach suchst du einmal auf einer CT-Suchseite wie crt.sh nach deiner Domain, um zu sehen, was schon öffentlich ist, und abonnierst einen Monitor, der neue Zertifikate meldet [1]. Die Namen sind ausgedachte Beispiele und keine unserer Hosts.

Prüfliste

• Durchsuche die CT-Logs einmal nach deiner Domain, um zu sehen, welche Hostnamen schon öffentlich sind.
• Abonniere einen CT-Monitor oder betreibe selbst einen, damit du von neuen Zertifikaten für deine Domain erfährst [1].
• Nutze ein Wildcard-Zertifikat für interne Dienste, deren Namen privat bleiben sollen.
• Halte verräterische Wörter wie admin oder backup aus Hostnamen in öffentlichen Zertifikaten heraus.
• Geh jedem Zertifikat für deine Domain nach, das du nicht beantragt hast [2].
• Schütze die Dienste selbst, denn ein versteckter Name ist keine Zugangskontrolle.