Certificate Authority Authorization oder kurz CAA heißt die neueste Waffe im Kampf gegen missbräuchlich ausgestellte TLS-Zertifikate für Websites.
CAA erlaubt es Domaineigentümern, direkt im DNS-Datensatz einer jeden Domain festzulegen, welche Zertifizierungsstelle (Certificate Authority, CA) für die Ausgabe von TLS-Zertifikaten berechtigt ist.
CAA seit September 2017 für alle CAs verbindlich
Die Methode erscheint auf den ersten Blick so simpel wie genial: In einem weiteren Nameserver-Eintrag werden einfach diejenigen CAs definiert, welchen es erlaubt ist, Zertifikate auf den Namen der Domain zu generieren. Mehr ist von Seiten des Domaineigentümers nicht erforderlich.
Der Standard CAA ist aber keineswegs neu. Bereits 2013 hat die Internet Engineering Taskforce (IETF) unter RFC 6844 diese Methode der Öffentlichkeit vorgestellt. Doch erst im Frühjahr 2017 entschied das CA/Browser Forum eine für alle Zertifizierungsstellen verbindliche Einführung zum Stichtag 8. September 2017.
Das CA/Browser Forum ist ein im Jahr 2005 gegründetes Konsortium aus Zertifizierungsstellen, Softwareunternehmen und Webbrowser-Entwicklern, die gemeinsame Standards für Verschlüsselungstechniken im Web erarbeiten und festlegen.
So funktioniert CAA in der Praxis
Der Zonendatei einer Domain werden die folgenden CAA-Records hinzugefügt, zum Beispiel:
14all-magazin.com. IN CAA 0 issue "letsencrypt.org"
14all-magazin.com. IN CAA 0 issuewild ";"
14all-magazin.com. IN CAA 0 iodef "mailto:info@14all-magazin.com"Die Eigenschaft „issue“ enthält eine kommagetrennte Liste der zulässigen Zertifizierungsstellen. Die erforderliche Bezeichnung kann bei der Registrierungsstelle erfragt werden, meist handelt es sich schlicht um deren Domainname (ohne „www.“).
Im Feld „issuewild“ werden diejenigen CAs festgelegt, welche Wildcard-Zertifikate ausstellen dürfen. Fehlt diese Angabe, gelten für Wildcards automatisch die Einträge in „issue“. Ein Semikolon weist darauf hin, dass für diese Domain niemand berechtigt ist, Wildcard-Zertifikate auszustellen.
Die dritte Angabe „iodef“ erlaubt die Kommunikation zwischen der CA und dem Domaininhaber. Beispielsweise können Fehlerberichte an eine E-Mail-Adresse abgesetzt werden. Bei Angabe einer URL (HTTP oder HTTPS) wird stattdessen eine Nachricht via POST-Request versendet.
Derzeit nutzt jedoch keine einzige Zertifizierungsstelle diese Art des Reportings.
Anlaufschwierigkeiten und Grenzen von CAA
Überhaupt liegt eine flächendeckende Unterstützung von CAA im Augenblick noch in weiter Ferne:
Zum einen scheint es bei den Zertifizierungsstellen selbst zu Anlaufschwierigkeiten zu kommen. So berichteten mehrere Nutzer übereinstimmend, dass selbst große CAs die Umsetzung zum Stichtag 8. September schlicht versäumten bzw. nur lückenhaft auf CAA-Records prüften.
Zum anderen erfordert das Hinzufügen von CAA-Einträgen in die Zonendatei einer Domain einen aktuellen DNS-Server seitens des Domain-Providers. Die Software BIND unterstützt CAA ab Version 9.9.6 und PowerDNS ab Version 4.0.0.
Da gerade DNS-Server einen kritischen Bereich im Hosting darstellen, werden Updates von den meisten Providern erst nach gründlichen internen Tests in die eigene Systemumgebung übernommen. Bis also alle kommerziellen Provider CAA unterstützen, kann deshalb durchaus noch einige Zeit ins Land ziehen.
Grundsätzlich keinen Schutz bietet CAA bei böswillig agierenden oder kompromittierten Zertifizierungsstellen. In diese Kerbe schlagen komplexere Mechanismen wie „Certificate Transparency“ oder „HTTP Public Key Pinning“.
CAA – sinnvoll oder sinnlos?
Certificate Authority Authorization kann im Gesamtbauwerk Web-Sicherheit nur ein Baustein von vielen sein. Da es leicht zu etablieren ist und abgesehen von einer Änderung der Zonendatei keine Modifikationen an Domain oder Website vorgenommen werden müssen, lohnt sich die Nutzung von CAA allemal.
Autor: Tobias Eichner | Datum der Veröffentlichung: September 2017
Wichtig: Bitte beachten Sie die Nutzungsbedingungen und rechtlichen Hinweise für diesen Beitrag!
