CAA, das unbekannte Wesen : Certification-Authority-Authorization (CAA) – was das ist und warum nicht mehr Websites darauf zurückgreifen

Von Patrick Nohe, Safety Harbor (US/FL)

Ein Certification-Authority-Authorization-(CAA)-Eintrag ist Bestandteil der Domain-Name-System-(DNS)-Angaben und ermöglicht es festzulegen, welche Zertifizierungsstellen (Certification Authorities, CAs) berechtigt sind, SSL-/TLS-Zertifikate (X.509 gem. RFC 5280) für die betreffende Domain auszustellen. Die Idee dahinter ist, Nutzer und Betreiber von Websites und anderen Diensten vor falsch ausgestellten, aber allgemein als vertrauenswürdig geltenden Zertifikaten zu schützen – denn solche Zertifikate kommen regelmäßig bei Angriffen und Betrugsversuchen zum Einsatz.

In der Praxis sind CAA-Einträge jedoch nie aktiv im großen Stil genutzt worden. Vor fast genau einem Jahrzehnt (im Oktober 2010) wurde ein erster Entwurf bei der Internet Engineering Taskforce (IETF) eingereicht und 2017 vom CA/Browser-Forum in ihren Baseline Requirements als verpflichtend zu beachten kodifiziert [1] – das CA/Browser-Forum ist das Branchengremium, das grundlegende Richtlinien für öffentliche vertrauenswürdige Zertifizierungsstellen festlegt. Trotzdem verwenden heute weniger als 8 % der weltweit führenden 150 000 Websites CAA-Einträge.

Verankerung im DNS

Das Vertrauens-Ökosystem für das Web spielt eine wesentliche Rolle, damit das Internet, wie wir es kennen, sicher funktioniert. Aber letztlich fristet genau dieses Ökosystem ein Nischendasein: Kaum ein durchschnittlicher Internetbenutzer versteht im Detail, wie Verbindungen zustande kommen, wie Clients und Server sich authentifizieren oder wie genau Daten bei der Übertragung verschlüsselt werden – es funktioniert einfach. Damit es allerdings „einfach funktioniert“, ist eine Reihe von Prüfmechanismen und Sicherheitsvorkehrungen vonnöten.

CAs sind per se stark regulierte Einrichtungen und haben die Aufgabe, Serverzertifikate auszustellen. Da diese Zertifikate „öffentlich vertrauenswürdig“ sind, hat es potenziell katastrophale Auswirkungen, wenn sie für den Falschen ausgestellt werden. Ein Beispiel: Ein Nationalstaat könnte mit einem gültigen Serverzertifikat für google.com den kompletten Datenverkehr zu und von dieser Website mit einem Man-in-the-Middle-Angriff abfangen – so ließen sich sowohl Bürger überwachen als auch eine weitreichende Zensur ausüben.

Um solche Szenarien auszuschließen und das Vertrauen in das Zertifikats-Ökosystem aufrechtzuerhalten, hat man eine Reihe von Sicherheitsvorkehrungen getroffen. Viele davon sind organisatorischer Art und sollen etwa gewährleisten, dass jede CA ethisch und verantwortungsbewusst arbeitet. Ein anderer Teil der Maßnahmen betrifft (Nicht-CA-) Organisationen und Websites, mit dem Ziel, sie vor möglicherweise falsch ausgestellten Zertifikaten zu schützen – und an dieser Stelle kommen CAA-Einträge ins Spiel.

CAA-Resource-Records

Syntax, Semantik und Prüfablauf für CAA-Einträge wurden ursprünglich in RFC 6844 definiert und später in RFC 8659 [2] vereinfacht. CAA-Informationen werden in einem DNS-Resource-Record (RR – nach RFC 1035) als Tag-Value-Paar abgelegt und sind somit über das Domain-Name-System öffentlich abfragbar. In seiner kanonischen Darstellung würde beispielsweise der folgende CAA-Eintrag festlegen, dass für die Domain nocerts.example.com überhaupt keine rechtmäßigen Zertifikate ausgestellt werden dürfen:

nocerts.example.com CAA 0 issue „;“

Will man etwa das Ausstellen von Zertifikaten für secure.example.org auf die GlobalSign-CA beschränken und zudem bei Problemen (Richtlinienverstößen) eine Zieladresse für Nachrichten im „Incident Object Description Exchange Format“ (IODEF, gem. RFC7970) vorsehen, so würde man diese Einträge hinterlegen (vgl. [3]):

secure.example.org
CAA 0 issue „globalsign.com“
secure.example.org
CAA 0 iodef „mailto:reportabuse@globalsign.com“

Weitere Formate stehen etwa für Angaben zu Wildcard-Zertifikaten (*.example.net) sowie die Festlegung von Kundennummern zur Verfügung. Zudem lassen sich auch mehrere CAs zur Ausstellung von Zertifikaten eintragen.

Bei der Erstellung der gewünschten Einträge können einige kostenlose Webservices dienlich sein:

• Certificate Search [4] liefert eine Historie der genutzten Zertifikate/Zertifizierungsstellen (CAs) für eine (Sub-)Domain.
• Der CAA Record Helper [5] hilft bei der Erstellung der CAA-RRs.
• Mit dem SSL Server Test von Qualys lässt sich überprüfen, ob die vorgenommenen Einstellungen korrekt sind.

Verpflichtende Überprüfung bei Zertifikatsanträgen

Seit September 2017 muss jede CA vor der Ausstellung eines Zertifikats die Zieldomain auf einen CAA-Eintrag hin prüfen. Gibt es keinen CAA-Eintrag, dann ist jede CA berechtigt, ein SSL-Zertifikat auszustellen. Ist er hingegen vorhanden, dürfen nur aufgeführte CAs für die jeweiligen (Sub-)Domains tätig werden. Sollte eine Zertifizierungsstelle die im Eintrag enthaltenen Bestimmungen nicht beachten, wird das wie eine Falschausstellung behandelt. Das zieht Strafen nach sich, die sogar dazu führen können, dass eine CA ihre Geschäftstätigkeit aufgeben muss.

Auf den ersten Blick scheinen CAA-Einträge also eine taugliche Sicherheitsvorkehrung zu sein, die wenig zusätzlichen Aufwand erfordert – daran sollte jeder Betreiber interessiert sein.

Unkenntnis und Unverständnis?

Warum verwendet also nur ein kleiner Teil selbst der weltweit führenden Websites CAA-Einträge? Es gibt dafür keinen einzelnen wesentlichen Grund. Verantwortlich ist vielmehr eine ganze Reihe von Ursachen und eine eher unangenehme Wahrheit: Das Vertrauens-Ökosystem im Internet ist selbst für Aufgeklärte und Profis nicht gerade „täglich Brot“. Das liegt zum einen daran, dass es komplex ist; zum anderen neigen sowohl der durchschnittliche Nutzer als auch viele Admins (mehr oder minder notgedrungen) dazu, sich möglichst wenig Gedanken zu machen. Für die meisten Website-Betreiber besteht der einzige diesbezügliche Berührungspunkt darin, einmal pro Jahr ein Zertifikat zu erwerben und zu installieren. Wer sich schon einmal selbst mit der X.509-Welt und ihren Tools beschäftigt hat, dürfte eher selten die Erfahrung reiner Freude gemacht haben.

Kaum jemand außerhalb des Betreiberzirkels des Zertifikate-Ökosystems denkt über SSL nach, bis es an der Zeit ist, eigene Zertifikate zu ersetzen. Durch die unlängst seitens der Browseranbieter beschlossenen Laufzeitbeschränkungen (siehe etwa [7]) auf eine maximale Gültigkeitsdauer von 13 Monaten ist das nun allerdings häufiger der Fall. Das hat zu einem Schönheitsfehler für das gesamte Ökosystem geführt – und ist auch ein Umstand, der es erschwert, auf offene Ohren für einen neuen Standard wie CAA-Einträge zu treffen.

Ähnlich verhält es sich mit Bedrohungen, die von SSL-Zertifikaten ausgehen können – vielen Website-Administratoren dürfte das damit verbundene dunkle Potenzial überhaupt nicht oder nicht ausreichend bewusst sein. Im Idealfall hätte eine Organisation wie das CA Security Council (https://casecurity.org) eine Kommunikationskampagne zum Thema CAA angestoßen. Das Jahr 2017 wäre ein guter Zeitpunkt gewesen – als nämlich die Zertifizierungsstellen beauftragt wurden, CAA-Prüfungen in ihren Workflow beim Ausstellen von Zertifikaten einzubauen. Man hat sich stattdessen entschieden, CAA-Einträge nicht aktiv zu promoten.

Tatsächlich wären ohnehin die Browseranbieter weit besser in der Lage, eine größere Web-Community über CAA-Einträge und ihren Nutzen zu informieren. 2016 und 2017 war etwa Google maßgeblich für die internetweite Umstellung von HTTP auf HTTPS verantwortlich. Aber der Konzern hatte sichtlich Mühe, die Anwender über diese Änderungen und ihre Auswirkungen zu informieren. Die Chrome-Benutzeroberfläche war anfänglich irreführend, was zu einer Explosion beim HTTPS-Phishing führte – ein Trend, der kaum zu vermeiden war; das User-Interface von Google Chrome und die unklare Kommunikation haben ihn allerdings noch befeuert. Einige Unternehmen, wie Amazon, haben sogar den ernsthaften Versuch unternommen, ihre Kunden über die Vorteile eines CAA-Eintrags aufzuklären – trotzdem erwies sich die Einführung der neuen CA-Regeln nicht als besonders erfolgreich, und es ist fraglich, ob sie das jemals sein wird.

Es gibt allerdings noch eine andere unbequeme Wahrheit, die man dabei nicht außer Acht lassen sollte: Zertifizierungsstellen wie Browseranbieter stehen in direkter Konkurrenz zueinander und CAA-Einträge sind, zumindest in einer Hinsicht, nicht gerade geschäftsfördernd: Wer einen CAA-Eintrag einrichtet, legt ja fest, welche CAs berechtigt sind, Zertifikate für die eigene Domain auszustellen. Man ist also ein potenzieller Kunden weniger für jede CA, die in diesem Eintrag nicht aufgeführt ist. Vor einem Wechsel müsste man erst den Eintrag revidieren, sonst schlüge jeder Zertifikatsantrag bei einem Wettbewerber fehl.

Wer wollte einer ganzen Reihe von Websites vorschreiben (oder zumindest empfehlen), einen DNS-Eintrag hinzuzufügen, der einschränkt, wer für sie Zertifikate ausstellen darf? Das will jedenfalls keine CA – es sei denn, es geht um die eigenen Kunden. Auch wenn eine breite Kampagne zur Einführung von CAA hilfreich gewesen wäre, verwundert es unter dieser Prämisse also nicht, dass das CA Security Council sich hier zurückgehalten hat.

Fazit

Es gibt keinen einen Grund, warum sich CAAEinträge nicht flächendeckend oder zumindest stärker durchgesetzt haben – ob es die Nischenexistenz des Zertifikate-Ökosystems ist, ob es daran liegt, dass unterschiedliche Akteure unterschiedliche Tagesordnungspunkte haben, oder ob es eher anekdotische Gründe sind, wie die Tatsache, dass einige Web-Administratoren, es schlicht ablehnen, mit DNS-Einträgen herumzuspielen …

Seit Januar 2020 ist der Anteil angelegter CAAEinträge bei den Top-Websites im Internet jedenfalls nur um einen einzigen Prozentpunkt gestiegen (von 6,8 % auf 7,8 %). Ohne eine konzertierte Anstrengung der Industrie wird sich dieses Schneckentempo vermutlich nicht nennenswert beschleunigen – und daran scheint (zugunsten des einfacheren Wettbewerbs?) offenbar kein Interesse zu bestehen.

Patrick Nohe ist Senior Product Marketing Manager bei GlobalSign.

Literatur

[1] CA/Browser Forum, Ballot 187 – Make CAA Checking Mandatory, März 2017, https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/
[2] P. Hallam-Baker, R. Stradling, J. Hoffman-Andrews, DNS Certification Authority Authorization (CAA) Resource Record, IETF RFC 8659, November 2019, https://tools.ietf.org/html/rfc8659
[3] GlobalSign, CAA Checking for SSL Certificates – Overview and Common Errors, https://support.globalsign.com/ssl/general-ssl/caa-checking-ssl-certificates
[4] crt.sh – Certificate Search, Sectigo Ltd., 2020, https://crt.sh
[5] SSLMate, CAA Record Helper, Opsmate Inc., 2018, https://sslmate.com/caa/
[6] Qualys, SSL Server Test, www.ssllabs.com/ssltest/analyze.html
[7] Dieter Petereit, HTTPS: Apple, Mozilla und Google einigen sich auf verkürzte Laufzeit für SSL/TLS-Zertifikate, t3n,
August 2020, https://t3n.de/news/https-apple-mozillagoogle-fuer-1313064/