Zusammenfassung

  • RFC 6844 erlaubte Domaininhabern, im DNS die Zertifizierungsstellen zu nennen, die für einen Namen Zertifikate ausstellen dürfen. Die erste Suchregel konnte einem CNAME oder DNAME folgen und anschließend im Namensbaum des Ziels aufwärts suchen. So konnte die CAA-Regel eines Hosters in die Prüfung eines Kundennamens geraten.
  • RFC 8659 behielt die normale DNS-Auflösung von Aliasnamen bei, beschränkte den Aufstieg durch übergeordnete Namen aber auf den geprüften FQDN. Damit trennte die Änderung die Richtlinie des Kunden klarer vom Namensbaum des Hosters.

Auf eine DNS-Antwort folgt noch eine Zertifikatsfrage

Nehmen wir das ausdrücklich hypothetische Beispiel www.client.example als CNAME für tenant.platform.example. Der Kundenname führt in den Namensraum eines gemeinsam genutzten Hosters. Vor der Zertifikatsausstellung muss eine Zertifizierungsstelle eine weitere Frage beantworten: Welche CAA-Records gelten für www.client.example?

Schwierig wird es, sobald die Abfrage eine Grenze überschreitet. Der Kunde verwaltet einen DNS-Namensbaum, der Hoster einen anderen. Ein Resolver kann dem Alias in Sekundenbruchteilen folgen. Soll die Zertifizierungsstelle zusätzlich die übergeordneten Namen des Hosters durchsuchen und eine Regel anwenden, die der Kunde nie in seiner eigenen Zone veröffentlicht hat?

Der im Januar 2013 veröffentlichte RFC 6844 definierte den DNS-Resource-Record Certification Authority Authorization, Typ 257. Ein Domaininhaber konnte eine oder mehrere Zertifizierungsstellen benennen, die für diesen Namen ausstellen durften. Vor der Ausstellung musste eine konforme Stelle den relevanten CAA-Record-Satz prüfen und einen widersprechenden Antrag ablehnen, sofern keine Ausnahme aus ihrer Zertifikatspolitik oder ihrem Certificate Practice Statement galt.

CAA legte die Ausstellungsrichtlinie ins DNS, also dorthin, wo der Inhaber ohnehin weitere Angaben zu seinem Namen veröffentlichte. Die Zertifizierungsstelle erhielt eine Regel, die sie vor der Ausgabe prüfen musste. Was „relevant“ bedeutete, hing jedoch davon ab, wie weit eine DNS-Suche über Namen hinweg reichte.

2013 konnte die Suche zwei Namensbäume durchlaufen

Die Verarbeitungsregel in RFC 6844 stieg nicht nur vom angefragten Namen zu dessen Eltern auf. Wenn eine CAA-Abfrage bei einem Label keinen Eintrag fand und dort ein CNAME- oder DNAME-Alias lag, konnte das Verfahren dem Ziel folgen und dort erneut suchen. Blieb die Suche erfolglos, ging sie zum Elternnamen des ursprünglichen FQDN zurück.

Die Beispielnamen zeigen die Folge. Angenommen, www.client.example verweist auf tenant.platform.example, und der Hoster veröffentlicht bei platform.example den Eintrag CAA 0 issue "issuer.example". Die Rekursion aus RFC 6844 konnte dem Alias folgen, bis platform.example aufsteigen und dort diese Regel finden. Ein Record im übergeordneten Namensraum des Hosters konnte so in die Ausstellungsprüfung für einen Kundennamen eingehen.

Die Regel sollte den zuständigen CAA-Satz finden; sie übertrug dem Hoster nicht das Eigentum an der Kundendomäne. Doch DNS-Auflösung und Richtlinienvererbung liefen gemeinsam durch dieselbe Rekursion. Der Kundenname folgte dem Alias des Hosters und konnte anschließend dessen übergeordnete Namen erreichen. Bei gemeinsamem Hosting konnte so jeder Kundenalias eine Richtlinie mitbringen, die der Hoster weiter oben in seinem Namensbaum veröffentlicht hatte.

2019 blieb der Aufstieg im Baum des angefragten Namens

Der im November 2019 veröffentlichte RFC 8659 löste RFC 6844 ab und änderte den Algorithmus. Die Zertifizierungsstelle fragt weiterhin den CAA-Record für den angefragten FQDN mit normalem DNS-Verhalten ab; dabei kann die Auflösung Aliassen folgen. Liefert die Abfrage keinen CAA-Satz, steigt der Algorithmus bei den Eltern des geprüften FQDN auf. Die Elternbäume jedes gefundenen CNAME- oder DNAME-Ziels werden nicht mehr separat durchlaufen.

Der Unterschied ist eng umrissen und dennoch wichtig. Ein CAA-Record direkt am Aliasziel kann weiterhin als DNS-Antwort zurückkommen. Weggefallen ist der zweite, eigenständige Aufstieg zu den Eltern dieses Ziels. Eine Richtlinie in der Kundenzone kann weiterhin für deren Subdomains gelten. Die übergeordnete Regel des Hosters gelangt nicht allein deshalb in die Kundensuche, weil ein CNAME in den Namensraum des Hosters weist.

RFC 8659 nennt den Grund selbst: Die Suche im Baum des Namens und zusätzlich in jedem Aliasbaum war bei langen Ketten ineffizient. Außerdem erschwerte sie es Hostern, CAA-Regeln für ihre eigenen FQDNs einzurichten, ohne möglicherweise unerwünschte Regeln auf Kunden-FQDNs anzuwenden. Die Neufassung stellte eine engere Frage: Welcher CAA-Satz gilt nach der normalen DNS-Auflösung für diesen angefragten Namen, und was sagen dessen eigene Eltern?

Die Richtlinie entscheidet bei der Ausstellung, nicht im Browser

CAA wirkt vor der Ausstellung. Es fordert Browser nicht auf, bereits ausgegebene Zertifikate neu zu beurteilen; eine DNS-Änderung widerruft kein bestehendes Zertifikat. Der Standard verbietet es Zertifikatsnutzern, aktuelle CAA-Records zur Zertifikatsvalidierung heranzuziehen. Der Record beschreibt die Ausstellungsberechtigung zu einem bestimmten Zeitpunkt.

Der CAA-Record authentifiziert auch nicht von selbst die DNS-Antwort. RFC 8659 empfiehlt DNSSEC für CAA nachdrücklich, schreibt es aber nicht vor. Wird eine Abfrage blockiert, kommt eine fehlerhafte Antwort zurück oder wird eine leere Antwort falsch behandelt, hat die Zertifizierungsstelle noch keine verlässliche Richtlinienauskunft. Der RFC zählt solche Betriebsprobleme auf, weil eine Zugriffsregel nur wirkt, wenn der Aussteller sie abrufen und verstehen kann.

CAA kennt zudem mehrere Properties. issue betrifft gewöhnliche Zertifikate; issuewild regelt Wildcard-Anträge, wenn es vorhanden ist. Ein leerer Ausstellerwert kann verlangen, dass keine Stelle für den Namen ausstellt. Diese Tags beschreiben den Inhalt der Richtlinie. Die Änderung von 2019 präzisiert, in welchem Namensbaum die Stelle danach sucht.

Das ist der historische Schritt: Der erste CAA-Standard gab Domaininhabern einen Ort im DNS, um Aussteller festzulegen. Sein Nachfolger zog eine schärfere Linie zwischen diesem Namensbaum und dem Baum des Hosters. DNS löst Aliasse weiterhin auf. Die Autorisierungssuche behandelt aber nicht mehr die Eltern jedes Ziels als Eltern des Kundennamens.

Die Namen in diesem Beispiel sind aus den Algorithmen gebildet, kein berichteter Vorfall. Die RFCs belegen die vorgesehenen Suchregeln. Um die Umsetzung einzelner Zertifizierungsstellen zu messen, wären deren Abfrage- und Ausstellungsprotokolle mit Namen und Zeitstempeln nötig.

Quellen