{"id":1839,"date":"2015-01-28T12:40:18","date_gmt":"2015-01-28T11:40:18","guid":{"rendered":"https:\/\/www.psw-group.de\/blog\/?p=1839"},"modified":"2026-02-16T08:46:15","modified_gmt":"2026-02-16T07:46:15","slug":"certificate-transparency-ct-wichtige-aenderungen-bei-ihren-ssltls-zertifikaten","status":"publish","type":"post","link":"https:\/\/www.psw-group.de\/blog\/certificate-transparency-ct-wichtige-aenderungen-bei-ihren-ssltls-zertifikaten\/","title":{"rendered":"Certificate Transparency (CT): wichtige \u00c4nderungen bei Ihren SSL\/TLS-Zertifikaten (Update)"},"content":{"rendered":"

Googles Initiative \u201eCertificate Transparency<\/a>\u201c (CT)<\/strong> soll Zertifikate<\/strong>, die von Certificate Authorities (CAs) ausgestellt wurden, protokollieren, kontrollieren und \u00fcberwachen<\/strong>. Die Idee dahinter ist, dass CAs keine Public Key-Zertifikate ausstellen sollen, ohne den Eigent\u00fcmer der Domain dar\u00fcber zu informieren.\u00a0Chrome verlangt<\/strong> von allen CAs, dass diese \u00fcber ihre gesamten EV-SSL-Zertifikate \u00f6ffentliche Protokolle f\u00fchren<\/strong>. So bleibt die gr\u00fcne Adresszeile auch weiterhin aktiv<\/strong>. Welche genauen \u00c4nderungen geplant sind, verraten wir Ihnen gerne:<\/p>\n

<\/p>\n

Hintergr\u00fcnde: Deshalb kam es zu CT<\/h3>\n

SSL\/TLS-Zertifikate sind ein essenzieller Sicherheitsfaktor bei eCommerce-Transaktionen, E-Mail-Verkehr und beim Online-Banking<\/strong>. Die beiden Hauptaufgaben von SSL\/TLS-Zertifikaten<\/strong> sind: Auf der einen Seite wird \u00fcber Zertifikate die Verschl\u00fcsselung von Informationen zwischen dem Webbrowser und dem besuchten Webserver<\/strong> erm\u00f6glicht.\u00a0Somit sch\u00fctzen Sie beispielsweise Kreditkartendaten vor dem Zugriff durch unbefugte Dritte. Auf der anderen Seite, und dies ist nicht weniger wichtig, wird dem Besucher einer Webseite erm\u00f6glicht, die Vertrauensw\u00fcrdigkeit des Webseiten-Betreibers zu \u00fcberpr\u00fcfen<\/strong>.<\/p>\n

CAs, die SSL-Zertifikate<\/a> ausstellen, wie Symantec<\/a>, Comodo<\/a> oder SwissSign<\/a>, k\u00f6nnen sich bei der Validierung der Angaben nicht den geringsten Fehler erlauben<\/strong>. Daher investieren vertrauensw\u00fcrdige Zertifizierungsstellen viel Geld in die Qualifizierung ihres Personals und die zur Anwendung kommenden Sicherheitsstandards. Damit soll sichergestellt werden, dass die Standards zur Unternehmens-\/Identit\u00e4tspr\u00fcfung unter allen Umst\u00e4nden greifen<\/strong>, bevor organisationsvalidierte oder Extended Validation-(EV)-Zertifikate ausgestellt werden.<\/p>\n

Leider arbeiten nicht alle augenscheinlich vertrauensw\u00fcrdigen CAs nach denselben Standards<\/strong>, sodass in der Vergangenheit durchaus Zertifikate f\u00fcr bekannte Webseiten auch an nicht autorisierte Antragsteller ausgestellt<\/strong> wurden. Nun gilt es, diese falsch ausgestellten Zertifikate zeitnah ausfindig zu machen<\/strong> und den Schaden, der durch die nicht erlaubte Verwendung dieser Zertifikate entstanden sein kann, auf ein Minimum zu beschr\u00e4nken. Certificate Transparency (CT) m\u00f6chte praktikable Werkzeuge bieten, um diesen Missstand zu korrigieren.<\/p>\n

Die Praxis: So soll CT funktionieren<\/h3>\n

Vier elementare Teilnehmer<\/strong> sind bei der Certificate Transparency beteiligt: Certification Authorities (CAs)<\/strong>, Log-Server<\/strong> (dienen als \u00f6ffentliche Datenbanken f\u00fcr SSL\/TLS-Zertifikate), Auditoren<\/strong> (Gegenstellen oder Webbrowser, die mit SSL-Zertifikaten arbeiten) und Monitoring-Dienste<\/strong>. Vor dem Ausstellen eines Zertifikats ist es notwendig, dass alle relevanten Informationen des Zertifikats durch die CA an mindestens einen Log-Server<\/strong>, dem die CA und die Auditoren gemeinsam vertrauen, geschickt werden. Der Log-Server empf\u00e4ngt nun das SSL-Zertifikat<\/strong> und antwortet der CA mit einer unver\u00e4nderbaren und einzigartigen Best\u00e4tigung<\/strong>. Diese Signed Certificate Timestamp (SCT)<\/strong> genannte Best\u00e4tigung wird bei Ausstellung eines Zertifikats hinzugef\u00fcgt<\/strong>. Es existieren auch andere M\u00f6glichkeiten der Nachweiserbringung, die wir Ihnen an anderer Stelle vorstellen werden.<\/p>\n

Was \u00e4ndert sich durch CT?<\/h3>\n

Wird durch den Browser eine SSL-gesch\u00fctzte Webseite aufgerufen<\/strong>, pr\u00fcft der\u00a0Browser das Zertifikat anhand einer offiziell vorbestimmten Checkliste<\/strong>. Certificate Transparency erg\u00e4nzt das Prozedere durch eine zus\u00e4tzliche \u00dcberpr\u00fcfung<\/strong>, bei der Browser, die eine Auditorenrolle \u00fcbernehmen, auch den SCT-Nachweis<\/strong>, welcher im Zertifikat inkludiert ist, \u00fcberpr\u00fcfen<\/strong>.<\/p>\n

Die \u00dcberpr\u00fcfung der SCT-Nachweise erfolgt unter Zuhilfenahme vertrauensw\u00fcrdiger Log-Server<\/strong>. F\u00fcr die G\u00fcltigkeit eines SCT-Nachweises gilt, dass der Webbrowser den Public-Key des ausstellenden Log-Servers in seiner lokalen Datenbank wiederfindet.<\/strong> Die angeforderte \u00dcberpr\u00fcfung findet nicht in Echtzeit<\/strong> statt. Googles Browser Chrome<\/strong> ist im Augenblick der einzige Browser, der CT unterst\u00fctzt<\/strong>. Im Rahmen von Certificate Transparency ist die Hauptaufgabe des Webbrowsers, bei den CAs durchzusetzen, dass die Zertifikatsausstellung \u00f6ffentlich publiziert<\/strong> wird und der Nachweis direkt enthalten ist.<\/p>\n

Jeder<\/strong>, der neu in den Log-Server aufgenommenen Zertifikate einsehen m\u00f6chte, kann die CT-Monitoring-Dienste nutzen<\/strong>. Die Idee dahinter ist, dass man durch das Monitoren der Log-Server falsch ausgestellte SSL\/TLS-Zertifikate f\u00fcr Webseiten ausfindig machen<\/strong> kann. Es ist nicht notwendig, dass SCT-Nachweise direkt in das Zertifikat implementiert werden<\/strong>. Denn auch TLS-Erweiterungen oder OCSP-Stapelung k\u00f6nnen dies \u00fcbermitteln. Jedoch sind hierf\u00fcr spezielle Konfigurationen auf Seiten des Webservers notwendig<\/strong>. CT eignet sich also, um alle ausgestellten Zertifikate in einer oder mehreren Datenbanken zug\u00e4nglich zu machen<\/strong>. Dabei bleibt es dem Browser \u00fcberlassen, wie er sich verh\u00e4lt, sollte sich eine CA dazu entschieden haben, die ausgestellten Zertifikate nicht auf Log-Servern zu ver\u00f6ffentlichen.<\/p>\n

Es ist sehr wahrscheinlich, dass Googles Browser Chrome keine gr\u00fcne Omnibox darstellt, wenn die EV-Zertifikate keine Nachweise zur CT enthalten<\/strong>. M\u00f6glich w\u00e4re auch, dass man statt der \u00dcberpr\u00fcfung von \u00f6ffentlichen Archiven die Zertifikate \u00fcberpr\u00fcft, die \u00f6ffentlich zug\u00e4nglich sind. Jedoch w\u00fcrde dies ungleich mehr Zeit beanspruchen. Dieser Zeitvorteil ist der eigentliche Ansatz in Sachen Certificate Transparency. Momentan kann, aufgrund fehlender CT-Auditoren, das volle Potenzial von CT nicht genutzt werden<\/strong>. Neben Google hat kein anderer Browser-Anbieter angek\u00fcndigt, CT zu unterst\u00fctzen. Klar ist, dass neben den Browsern auch die Desktop-Anwendungen, Applikationen auf Mobilger\u00e4ten und webbasierte Dienste nachziehen m\u00fcssen<\/strong>, wenn diese Teil der SSL-Welt sind.<\/p>\n

CT-Monitoring<\/strong> stellt also soweit die bessere und z\u00fcgigere Methode bei der Entdeckung falscher SSL-Zertifikate<\/strong> dar – verglichen mit dem umst\u00e4ndlichen Scannen des Internets. Zugleich wird nicht jeder Inhaber eines SSL-Zertifikats die Mittel zur Verf\u00fcgung haben, um sich Certificate Transparency-Monitore anschaffen zu k\u00f6nnen. Dies wird sich auf die gr\u00f6\u00dferen Unternehmen beschr\u00e4nken.<\/p>\n

Existieren Alternativen zu CT?<\/h3>\n

Festzuhalten gilt, dass CT nicht die Problematik der falsch ausgestellten Zertifikate l\u00f6st<\/strong>. Vielmehr ist es wesentlich einfacher, die falsch ausgestellten zu ermitteln<\/strong>. Alternativ lassen sich andere Wege beschreiten. CCA, zum Beispiel. Dabei werden die unautorisiert ausgestellten Zertifikate anders ermittelt. Mit CCA<\/strong> werden in den DNS-Einstellungen die CAs benannt, die Zertifikate f\u00fcr die eigene Domain ausstellen d\u00fcrfen<\/strong>. CAs, die CAA unterst\u00fctzen, sollten zun\u00e4chst den erforderlichen CAA-Eintrag in den DNS-Einstellungen pr\u00fcfen, bevor Zertifikate ausgegeben werden. Dies ist jedoch momentan noch nicht verbindlich geregelt<\/strong>. W\u00fcrden Auditoren und Browser dies durchsetzen, g\u00e4be es eine zus\u00e4tzliche effektive Methode zur Vermeidung von unautorisiert ausgestellten Zertifikaten<\/strong>.<\/p>\n

Und wie steht es um den Datenschutz?<\/h3>\n

Aus Sicht des Datenschutzes ist CT eine echte Herausforderung<\/strong>. Denn jeder legitimer Webseitenbetreiber hat mit CT-f\u00e4higen Browsern Schwierigkeiten bei der Darstellung der gr\u00fcnen Adressleiste<\/strong>, insofern er nicht bereit ist, seine Zertifikatsinformationen in der Datenbank der Log-Server anzuzeigen. Ein m\u00f6glicher Grund daf\u00fcr w\u00e4re beispielsweise ein SSL-Zertifikat f\u00fcr ein noch in der Entwicklung befindliches Produkt oder ein Regierungsprojekt<\/strong>, welches der Geheimhaltung unterliegt. Es m\u00fcssen also M\u00f6glichkeiten geschaffen werden, den Datenschutz auch bei umfassender CT-Unterst\u00fctzung zu gew\u00e4hrleisten<\/strong>.<\/p>\n

Die PSW GROUP unterst\u00fctzt Sie!<\/h3>\n

Sie sehen: CT steckt noch in den Kinderschuhen, Cyberkriminalit\u00e4t durch falsche SSL-Zertifikate kann hingegen schon laufen<\/strong>. Haben sich f\u00fcr Sie Fragen ergeben, nutzen Sie gern unseren Support<\/a>, der Sie auch zur\u00fcckruft.\u00a0Allgemeine Fragen zum Thema k\u00f6nnen Sie auch in den Kommentaren stellen, sodass andere Fragesteller ebenfalls direkt Antworten erhalten.<\/p>\n

27.10.16 – Update: Google treibt Certificate Transparency voran<\/h3>\n

Google treibt seine Initiative „Certificate Transparency“ voran: Der Suchmaschinenriese erkl\u00e4rt<\/a>, dass voraussichtlich ab Oktober 2017 alle neu ausgestellten SSL\/TLS-Zertifikate vor Ausstellung in das \u00f6ffentliche Log eingetragen werden m\u00fcssen. Geschieht das nicht, akzeptiert Googles Browser Chrome die Zertifikate nicht mehr.<\/p>\n

Das erschwert das Missbrauchen des Zertifikate-Systems ungemein: unberechtigt ausgestellte Zertifikate fliegen h\u00f6chstwahrscheinlich auf.<\/p>\n

Transparenz: Log-Daten kann jeder einsehen<\/h3>\n

Jeder kann die Daten der Logs einsehen. Das Auslesen der Daten geschieht mittels HTTP-API gem\u00e4\u00df der Dokumentation im RFC 6962<\/a>. Alternativ kann das Webinterface unter crt.sh, welches Comodo betreibt, genutzt werden.<\/p>\n

Im Schnitt dauert es rund 1,5 Stunden, bis ein SSL\/TLS-Zertifikat im Log erfasst ist. Im Hintergrund werkelt ein recht komplexes Kryptografie-Verfahren, das mittels Merkle-Trees<\/a> f\u00fcr konsistente Logs sorgt.<\/p>\n

CT: was soll das Ganze noch mal?<\/h3>\n

Pannen von Zertifizierungsstellen, j\u00fcngst machten etwa WoSign und StartCom von sich Reden<\/a>, werden mit Certificate Transparency wom\u00f6glich bald komplett der Vergangenheit angeh\u00f6ren. Denn das Vertuschen etwaiger Fehler durch Zertifizierungsstellen wird nahezu unm\u00f6glich! Googles Logserver vermerken mit CT jedes falsch ausgestellte Zertifikat.<\/p>\n

Auch andere Pannen kann CT aufdecken. So berichtete etwa Facebooks Sicherheitsteam<\/a> von einem Vorfall: F\u00fcr eine Subdomain von fb.com wurde ein Zertifikat ausgestellt, \u00fcber das das Sicherheitsteam nichts wusste. F\u00e4lschlicherweise hatte eine andere Abteilung dieses Zertifikat beantragt, ohne das Sicherheitsteam dar\u00fcber zu informieren. Beim Checken der Logs fiel die interne Verletzung der Facebook-Sicherheitsrichtlinie auf.<\/p>\n