Möglicherweise haben Sie schon vor einigen Jahren von Certificate Transparency (CT) gehört, als Google die Anforderung für alle Extended Validation (EV) SSL/TLS-Zertifikate ankündigte, die nach dem 1. Januar 2015 ausgestellt worden sind. Seitdem hat Google die Anforderung auf alle Arten von SSL-Zertifikaten ausgedehnt und zuletzt eine Frist bis zum April 2018 gesetzt. Zertifikaten, die nicht CT-qualifiziert sind und die nach diesem Datum ausgestellt werden, wird in Chrome nicht vertraut.
GlobalSign hat im Hintergrund bereits daran gearbeitet, dass alle Zertifikate mit CT ausgestattet werden - Extended Validation (EV) seit 2015, Domain Validated (DV) seit August 2016 und Organisation Validated (OV) ab Oktober 2017 – GlobalSign-Kunden sind damit für den Fristablauf seitens Google gerüstet.
Für alle, die sich immer noch fragen, worum es bei CT geht, haben wir die wichtigsten Informationen zusammengestellt.
Hinweis: Aus Gründen der Einfachheit verwenden wir in diesem Beitrag den Begriff SSL anstelle von TLS (mit einer Ausnahme), da er häufiger benutzt wird. Für weitere Informationen lesen Sie bitte den zugehörigen Post.
Was ist Certificate Transparency?
Certificate Transparency ist eine offene Rahmenstruktur für die Überwachung von SSL-Zertifikaten. Domaininhaber halten es vielleicht für sinnvoll, die Zertifikatausstellung für ihre Domain zu überwachen und darüber auch falsch ausgestellte Zertifikate zu erkennen. Vor CT gab es keine effiziente Möglichkeit, eine umfassende Liste der für Ihre Domain ausgestellten Zertifikate zu bekommen.
Mit CT werden alle Zertifikate öffentlich bekannt gegeben, was einen tieferen Einblick und mehr Transparenz innerhalb des Web-PKI-Ökosystems gestattet. Das Projekt zur Certificate Transparency will drei Ziele erreichen:
- Es für eine CA unmöglich (oder zumindest sehr schwer) zu machen, ein SSL-Zertifikat für eine Domain auszustellen, ohne dass das Zertifikat für den Eigentümer dieser Domain sichtbar ist.
- Ein offenes Überprüfungs- und Überwachungssystem bereitzustellen, mit dem alle Domaininhaber oder CAs feststellen können, ob Zertifikate irrtümlich oder mit einer böswilligen Absicht ausgestellt wurden.
- Benutzer vor irrtümlich oder mit einer böswilligen Absicht ausgestellten Zertifikaten zu schützen.
Über das Certificate Transparency Framework kann man falsch ausgestellte Zertifikate schnell und effizient erkennen.
Anders als im alten System, bei dem unberechtigte Zertifikate Wochen oder Monate im Umlauf bleiben und potenziell verheerende Schäden anrichten, bevor sie entdeckt werden. Die frühzeitige Erkennung von verdächtigen Zertifikaten ermöglicht es CAs und Domaininhabern, schnell zu handeln und die Zertifikate zu widerrufen.
So funktioniert Certificate Transparency
Die beiden wichtigsten CT-Komponenten sind die CT-Logs und Monitore.
CT-Logs führen Aufzeichnungen von ausgestellten SSL-Zertifikaten. Diese Logs sind 'append-only', d. h. sobald ein Zertifikat in einem Log eingetragen wurde, können die Einträge weder gelöscht noch geändert werden. SSL-Zertifikate und Vorzertifikate (mehr dazu weiter unten) können in CT-Logs eingetragen werden. Beim Erhalt eines gültigen SSL-Zertifikats oder Vorzertifikats gibt das Log einen Signed Certificate Timestamp (SCT) zurück. Dieser weist nach, dass das Log die Anfrage erhalten hat. CT-Logs verwenden einen kryptografischen Mechanismus namens „Merkle Tree Hash“, der verhindert, dass Log-Einträge geändert oder gelöscht werden. Wenn sie also einmal eingetragen sind, sind sie für die Öffentlichkeit immer sichtbar. Browser verlangen eventuell SCTs (die anzeigen, dass das Zertifikat öffentlich bekannt gegeben wurde) während der Verarbeitung von SSL-Zertifikaten bei der Einrichtung einer TLS-Sitzung. Diese SCTs sind also ein zunehmend wichtiges Merkmal in der Web-PKI. Mehr dazu später.
Monitore fragen CT-Logs ab und können Zertifikate zum späteren Reporting herunterladen und speichern. Monitore zergliedern die Zertifikate in Teilfelder und erlauben ihren Benutzern, Abfragen für Zertifikate zu erstellen und auszuführen. Domain-Besitzer sind sicherlich daran interessiert, Benachrichtigungen für Zertifikate zu erhalten, die für ihre Domains ausgestellt wurden, oder für Zertifikate, die mit ihrem Unternehmensnamen übereinstimmen. Compliance-Teams achten auf die Einhaltung der CA/Browser Forum Baseline Requirements oder Root-Programm Anforderungen. Unabhängig davon gibt es viele weitere Zwecke für Monitore. Einige Drittanbieter-Dienste haben CT-Monitoring-Tools veröffentlicht oder damit begonnen, sie in bestehende Lösungspakete einzubinden. Facebook hat beispielsweise Ende vergangenen Jahres seinen eigenen kostenlosen Monitoring-Service gestartet.
Was sind Vorzertifikate?
CT-Logs akzeptieren SSL-Vorzertifikate und Zertifikate. Ein Vorzertifikat enthält die gleichen Daten wie das "echte" Zertifikat. Es enthält aber auch eine zusätzliche Erweiterung, die das Zertifikat unbrauchbar macht. Diese Erweiterung wird als „Gifterweiterung“ bezeichnet und unterscheidet das Vorzertifikat vom „echten“. Alle von einer CA ausgestellten Zertifikate enthalten eindeutige Seriennummern. Das Vorzertifikat und Zertifikat haben aber die gleiche Seriennummer. Deshalb ist es wichtig, eines von beiden ungültig oder nicht nutzbar zu machen.
Wozu sind Vorzertifikate gut?
Es gibt mehrere Methoden für die Bereitstellung von SCTs für die Browser-Verarbeitung. Die zuverlässigste und sinnvollste ist die, SCTs in das Zertifikat einzufügen. Um SCTs vor der Ausstellung zu erhalten (so können sie in das Zertifikat eingefügt werden), muss die CA ein Vorzertifikat erstellen, es in CT-Logs eintragen, SCTs erhalten und sie dann in das endgültige Zertifikat einfügen.
Vor der Ausstellung eines Zertifikats kann eine CA ein Protokoll im CT-Log eintragen, mit der Absicht das entsprechende Zertifikat auszustellen. In der Tat wird die Erstellung und Veröffentlichung eines Vorzertifikats, das nicht ordnungsgemäß validiert oder formatiert ist, als eine Falschausstellung betrachtet.
Wer kann Zertifikate in CT-Logs eintragen?
Jeder kann Zertifikate in CT-Logs eintragen, aber nur CAs tragen Vorzertifikate ein. Suchmaschinen und Website-Betreiber tragen ebenfalls häufig Zertifikate in CT-Logs ein.
Einige CT-Log-Betreiber akzeptieren Zertifikate nur unter bestimmten Roots, einige akzeptieren keine abgelaufenen Zertifikate, und alle Zertifikate (oder Vorzertifikate) müssen als SSL-Zertifikate verwendet werden (d. h. Sie können keine S/MIME- oder Code Signing Zertifikate in CT-Logs eintragen).
Die Verwendung von SCTs
Der SCT - der Nachweis, dass das Zertifikat gelogged wurde - muss dem Webbrowser zur Verfügung gestellt werden um das SSL-Zertifikat ordnungsgemäß zu evaluieren. Das genaue Browserverhalten und die Anforderungen an SCTs variieren je nach Browser. Aber in allen Fällen muss der Browser die SCTs bekommen. Theoretisch könnte auch der Browser beim Erstellen einer TLS-Sitzung SSL-Zertifikate in Logs eintragen um SCTs zu erhalten. Die Kosten wären aber kaum tragbar.
Es gibt im Wesentlichen drei Methoden um dem Browser SCTs zur Verfügung zu stellen:
1. Zertifikatserweiterung
Die am häufigsten verwendete und zuverlässigste Methode für die CA zur Bereitstellung von SCTs an den Browser, ist es, SCTs in das Zertifikat einzufügen. Da der Browser das SSL-Zertifikat braucht, um die TLS-Sitzung herzustellen, ist das Zertifikat garantiert vorhanden und kann immer zum Lesen von SCTs verwendet werden.
Einige Website-Inhaber wollen möglicherweise nicht, dass ihre Website-URL vor dem Start der betreffenden Website bekannt wird. Das wäre gegebenenfalls ein Grund, Zertifikate nicht im Voraus in CT-Logs einzutragen und lieber eine andere Methode zu wählen.
2. TLS (SSL) -Erweiterung
Der Website-Betreiber kann SCTs auch im TLS-Protokoll bereitstellen. In diesem Modell übergibt der Website-Betreiber/Webserver das Zertifikat an die CT-Logs und erhält im Gegenzug die SCTs. Die SCTs sind im TLS-Handshake über eine TLS-Erweiterung unter dem Namen "signed_certificate_timestamp" enthalten. Der "Nachteil" dieser Bereitstellungsmethode ist, dass Webserver-Betreiber ihre Standard-Webserver-Konfigurationen ändern müssen und nicht alle Webserver diese Option unterstützen.
3. OCSP-Stapling
OCSP-Meldungen lassen sich ebenfalls für das Verteilen von SCTs an den Browser verwenden. Dazu müssen zwei Voraussetzungen erfüllt sein:
- Der Website-Betreiber muss einen Webserver verwenden, der OCSP-Stapling unterstützt und er muss seinen Server so konfigurieren, dass er eine gültige OCSP-Antwort anfordert und herunterlädt. Geschieht das nicht, gibt es keine Garantie, dass der Browser die OCSP-Nachricht mit den SCTs abruft (viele Browser unterstützen OCSP nicht, sodass dies kein zuverlässiger Bereitstellungsmechanismus ist, es sei denn, die OCSP-Antwort ist im TLS-Protokoll enthalten).
- Die CA muss ihren OCSP-Service so konfigurieren, dass er SCT-Stapling unterstützt. Nachdem das Zertifikat ausgestellt wurde, trägt die CA es in mehrere Logs ein und bekommt anschließend die SCTs. Wenn OCSP-Antworten generiert werden, fügt die CA die SCTs zur OCSP-Nachricht hinzu. Damit hat der Browser sowohl den Widerrufstatus als auch die notwendigen SCTs.
Während Methode 2 und 3 eine spezielle Serverkonfiguration erfordern, bieten sie im Vergleich zu Option 1 mehr Flexibilität. Wenn Zertifikat-Logs nicht mehr vertrauenswürdig sind, können Websitebetreiber und die CA die verwendeten Logs dynamisch neu konfigurieren.
Die Google CT-Richtlinie
Um "CT-qualifiziert" zu sein, verlangt Google, dass ein Zertifikat in mehreren Logs erscheint (mindestens ein Google- und ein Nicht-Google-Log). Und die Anzahl der benötigten SCTs hängt vom Gültigkeitszeitraum des Zertifikats ab. Weitere Informationen finden Sie in Googles Certificate Transparency in Chrome.
Eine Liste mit Logs finden Sie hier.
Was muss ich tun, um CT-konform zu sein?
Sie kennen nun die CT-Grundlagen. Die beste Lösung, um sicherzustellen, dass Sie konform sind, ist, eine CA auszuwählen, die gemäß der Google CT-Richtlinie SCTs zum ausgestellten Zertifikat hinzufügt. Die überwiegende Mehrheit unserer SSL-Zertifikate ist bereits zur Google-Richtlinie konform, in wenigen Monaten sind es alle. Volle 5 Monate vor Ablauf der Google-Frist vom April 2018.
Bisher ist Google der einzige Browser-Anbieter, der Zeitpläne für seine CT-Anforderungen veröffentlicht hat. Mozilla hat zwar auch eine Richtlinie entworfen, allerdings wurden noch keine Termine bekannt gegeben. Sehr wahrscheinlich werden sie mit denen von Google kompatibel sein.
Verfolgen Sie die Diskussion hier mit. Wir aktualisieren unsere Blogeinträge, wenn weitere Ankündigungen veröffentlicht werden.
Haben Sie Fragen zur Certificate Transparency und dazu, ob Ihre Zertifikate konform sind? Kontaktieren Sie uns jederzeit. Wir helfen Ihnen gerne weiter.
