Original-URL des Artikels: https://www.golem.de/news/tls-zertifikate-zertifizierungsstellen-muessen-caa-records-pruefen-1709-129981.html    Veröffentlicht: 11.09.2017 16:08    Kurz-URL: https://glm.io/129981

TLS-Zertifikate

Zertifizierungsstellen müssen CAA-Records prüfen

Mittels eines Standards namens Certificate Authority Authorization können Domaininhaber via DNS definieren, wer für sie TLS-Zertifikate ausstellen darf. Ab sofort müssen diese Records geprüft werden. Bei einem Test schlampte Comodo und stellte fälschlicherweise ein Zertifikat aus.

Ein neuer DNS-Record kann in manchen Situationen helfen, fehlerhaft ausgestellte TLS-Zertifikate zu vermeiden. CAA oder Certificate Authority Authorization heißt der neue Nameservereintrag. Ein Domaininhaber kann darin definieren, welchen Zertifizierungsstellen er erlaubt, Zertifikate für die entsprechende Domain auszustellen. Bei manchen Zertifizierungsstellen hakt es aber noch. Comodo, eine der größten Zertifizierungsstellen, prüft CAA bisher trotz anderweitiger Versprechen überhaupt nicht.

Der Standard für CAA - RFC 6844 - wurde bereits 2013 verabschiedet. Doch bislang war es für Zertifizierungsstellen nicht verpflichtend, sich daran zu halten. Im Frühjahr hatte das CA/Browser-Forum in einer Abstimmung entschieden, dass die Prüfung von CAA künftig verpflichtend wird. Der Stichtag dafür war der 8. September 2017.

DNS-Records definieren zulässige Zertifizierungsstelle

Für den Recordtyp CAA können dabei drei Eigenschaften definiert werden: issue, issuewild und iodef. Als "issue"-Eigenschaft kann man einen von der CA definierten Domainnamen angeben, üblicherweise ist das schlicht der Domainname der Webseite der jeweiligen Zertifizierungsstelle. Im Feld "issuewild" kann man separat angeben, wer Wildcard-Zertifikate für die entsprechende Domain ausstellen darf. Wird diese Eigenschaft nicht angegeben, gilt dafür derselbe Wert wie für "issue".

Das Feld iodef ermöglicht es, einen Reporting-Mechanismus zu definieren. Sprich: Wenn eine CA die Ausstellung eines Zertifikats für die Domain verweigert, kann sie damit einen Fehlerbericht an den Inhaber senden. Dort kann man entweder eine HTTP- oder HTTPS-URL oder eine Mailadresse mit vorangestelltem "mailto:" angeben. Bei HTTP/HTTPS-URLs wird ein Fehlerbericht mittels eines POST-Requests verschickt. Das Verschicken von Fehlerberichten ist bisher allerdings optional und wird von den meisten Zertifizierungsstellen nicht unterstützt.

Ein Beispiel für eine entsprechende Zonendatei sähe dabei so aus:

Hier wird festgelegt, dass nur Let's Encrypt Zertifikate für die Domain example.com ausstellen darf. Wildcard-Zertifikate sollen überhaupt nicht ausgestellt werden, dafür wird der Platzhalter ";" eingefügt. Fehlerberichte sollen, falls unterstützt, an postmaster@example.org gemailt werden.

CAA ist dabei ein weiterer Baustein, um das System der TLS-Zertifikate zu verbessern. Hilfreich ist CAA vor allem, um bei möglichen Fehlern in der Domainprüfung einen zusätzlichen Sicherheitsmechanismus zu bieten. Wenn eine Zertifizierungsstelle beispielsweise einen Bug hat, der die Domainvalidierung austrickst, sind davon Nutzer, die via CAA nur die Ausstellung von anderen Zertifizierungsstellen zulassen, nicht betroffen. Vorausgesetzt natürlich, dass die Zertifizierungsstelle CAA korrekt prüft.

Keinen Schutz bietet CAA gegen vollständig kompromittierte oder böswillig agierende Zertifizierungsstellen, da natürlich immer die Voraussetzung ist, dass CAA auch geprüft wird. Gegen bösartige Zertifizierungsstellen können aber andere Mechanismen wie Certificate Transparency oder HTTP Public Key Pinning helfen.

Comodo stellt fehlerhafterweise Zertifikat aus

Der Softwareentwicker Michael Kliewe von mail.de wies uns schon vor einigen Wochen darauf hin, dass man bei Comodo offenbar mit der Umsetzung von CAA geschlampt hat. Zwar kündigt die Comodo-Webseite an, dass man dort schon seit mindestens zwölf Monaten CAA-Records prüfe. Trotzdem wurde für eine Domain, für die via CAA-Record nur eine andere Zertifizierungsstelle als erlaubt angegeben war, ein Zertifikat ausgestellt.

Das alleine wäre zwar ein Widerspruch zu Comodos eigener Webseite gewesen, aber damals galt noch keine verpflichtende Prüfung von CAA-Records. Doch bei einem Test von Golem.de wurde auch am Samstag von Comodo noch ein Zertifikat für eine Domain ausgestellt, für die ein anderweitiger CAA-Record gesetzt war.

Auch bei anderen Zertifizierungsstellen hapert es noch mit der Umsetzung von CAA. Andrew Ayer von der Firma SSLMate hat eine Testsuite mit zahlreichen Domains erstellt, die diverse Varianten von CAA umsetzen. Bei den Tests von Ayer stellte Digicert mehrere Zertifikate fälschlicherweise aus.

Da der Record-Typ noch vergleichsweise neu ist, benötigt man eine vergleichsweise aktuelle Version des entsprechenden DNS-Servers. BIND hat die Unterstützung von CAA in Version 9.9.6 eingeführt, PowerDNS in Version 4.0.0. Unbound unterstützt CAA ebenfalls, allerdings fanden wir keine Informationen, ab welcher Version das der Fall ist.

Unterstützung bei Hostern bisher noch mangelhaft

Bei Web- und DNS-Hostern ist die Situation noch durchwachsen. Viele bieten bislang keine Möglichkeit, den neuen DNS-Record-Typ zu konfigurieren. Wir haben bei verschiedenen deutschen Webhostern nachgefragt. Von 1&1 hatten wir zur Fertigstellung des Artikels noch kein Statement. Bei http.net, einem der größten deutschen Domainhoster, konnten wir in einem Test keine CAA-Records anlegen.

Hetzner schreibt in seinem Wiki, dass man CAA erst unterstützen möchte, wenn DNSSEC zur Verfügung steht. Einen logischen Grund dafür gibt es nicht, denn CAA lässt sich - anders als die Hetzner-Dokumentation nahelegt - auch unabhängig von DNSSEC nutzen.

Strato teilte uns auf Nachfrage Folgendes mit: "Das Sicherheitsrisiko, das durch CAA-Records beseitigt werden soll, besteht bei uns derzeit nicht, da Strato-Kunden auf unserer Plattform automatisiert SSL-Zertifikate zur Verfügung gestellt werden."

Nachvollziehen können wir auch dieses Statement nicht. CAA soll ja dazu dienen, dass andere Zertifizierungsstellen nicht fehlerhafterweise Zertifikate ausstellen. Was die automatisierte Zertifikatsausstellung von Strato damit zu tun hat, bleibt wohl deren Geheimnis.

Google-Domains unterstützt CAA bislang nicht, was überrascht, da Google-Vertreter im CA/Browser-Forum die Einführung von verpflichtenden CAA-Checks vorangetrieben haben. Cloudflare hat vor kurzem einen Betatest mit CAA-Records gestartet.

Einen Überblick über die Unterstützung bei DNS-Servern und Hostern gibt es bei SSLMate und auf einer von Royce Williams verwalteten Übersichtsseite auf Github.

Gängige TLS-Test-Tools wie SSL Labs und Hardenize prüfen den CAA-Record schon seit einer Weile. Bei DNS Spy gibt es zudem einen Validator für CAA-Records, der mögliche Fehlerquellen aufspürt.  (hab)


Verwandte Artikel:
Bluetooth-Technologie fürs Auto   
(27.09.2000, https://glm.io/9999 )
ROBOT-Angriff: Arbeitsagentur nutzt uralte Cisco-Geräte   
(09.03.2018, https://glm.io/133258 )
HSTS: Facebook verschlüsselt alle ausgehenden Links, wenn möglich   
(06.03.2018, https://glm.io/133157 )
Zertifikate: Trustico verwundbar für Root-Code-Injection   
(01.03.2018, https://glm.io/133089 )
HTTPS: Chrome will HTTP Public Key Pinning wieder aufgeben   
(29.10.2017, https://glm.io/130871 )

© 1997–2019 Golem.de, https://www.golem.de/