CAA RRs – Reihenfolge im DNS

[Update 29.09.2017: Hinweis zur Konfiguration von Windows Server 2016 ergänzt]

[Update 13.09.2017: Hinweis auf noch nicht gültiges Errata 5065 entfernt, Formulierung zu „;“ korrigiert, Unterstrich aus Beispiel-PKIs entfernt, IN bei den Beispielen ergänzt, RFC 3597-Kodierung von pki.dfn.de CAA RR für BIND < 9.9.6 ergänzt ]

 

Seit 08.09.2017 müssen alle PKIs, die die Baseline Requirements des CA/Browserforums erfüllen, vor der Ausstellung eines Serverzertifikats CAA Resource Records im DNS nach RFC 6844 abfragen.

Die DFN-PKI erfüllt selbstverständlich diese Anforderung. Die Prüfung wird von den technischen Systemen der DFN-PKI automatisch durchgeführt, ohne dass der Teilnehmerservice eingreifen muss (oder kann).

Ebenfalls gilt:  Es ist keine Pflicht, im eigenen DNS CAA RRs zu setzen. Wird ein DNS-Administrator nicht tätig und setzt keine CAA RRs, ändert sich zunächst nichts. Alle PKIs, die bisher verwendet wurden, können weiter genutzt werden. Einschränkungen gibt es nur dann, wenn im DNS in einer höheren Ebene ein CAA RR gesetzt wird.

Eine Einführung in die Technik finden Sie unter:

https://blog.pki.dfn.de/2017/03/rfc-6844-certification-authority-authorization-caa/

Das Grundprinzip ist einfach, allerdings befördert die hierarchische Struktur des DNS komplexe Szenarien mit eventuell nicht sofort einsichtigen Auswirkungen. Mit einigen Beispielen sollen hier die Konsequenzen von verschiedenen Szenarien erläutert werden.

issue

Mit CAA RRs kann ein Zonenadministrator die PKIs benennen, die für Server seiner Zone Zertifikate ausstellen dürfen. Ein Beispiel in der Syntax für BIND ≥ 9.9.6, um die nutzbaren PKIs auf die DFN-PKI und eine weitere Beispiel-PKI zu beschränken:

hs-musterstadt.de. IN CAA 0 issue "pki.dfn.de"
hs-musterstadt.de. IN CAA 0 issue "weitere-beispiel-pki.de"

Damit dürfen Systeme unterhalb von hs-musterstadt.de (beispielsweise www.hs-musterstadt.de oder www.first-sub.hs-musterstadt.de) prinzipiell nur von der DFN-PKI und der weiteren Beispiel-PKI mit Zertifikaten ausgestattet werden.

BIND < 9.9.6 kennt CAA RRs noch nicht. Hier kann die Darstellung nach RFC 3597 verwendet werden (gilt auch für Windows Server 2016):

;                    RFC 3597-Darstellung von: CAA 0 issue "pki.dfn.de"
hs-musterstadt.de. IN TYPE257 \# 17 00056973737565706B692E64666E2E6465

Für Windows Server 2016 wird zur Konfiguration die PowerShell verwendet:

#  Setzt für den Namen und die Zone hs-musterstadt.de CAA 0 issue "pki.dfn.de"
Add-DnsServerResourceRecord -Name hs.musterstadt.de -RecordData 00056973737565706b692e64666e2e6465 -Type 257 -ZoneName hs-musterstadt.de

Auswertungsreihenfolge

Kompliziert wird CAA durch die Auswertungsregeln, die in RFC 6844 festgelegt sind: Ein FQDN, der in ein Zertifikat aufgenommen werden soll, wird von links nach rechts durchgeprüft, bis entweder ein CAA RR gefunden wurde oder die DNS Root erreicht ist. Dabei werden auch CNAMEs verfolgt. Der erste gefundene CAA RR wird ausgewertet und ist maßgeblich.

Dies bedeutet konkret: Gibt es CAA RRs auf unterschiedlichen Ebenen im DNS, „gewinnt“ die tiefere Ebene.  Wieder ein Beispiel (ohne SOA, NS, o.ä.):

hs-musterstadt.de.            IN CAA 0 issue "pki.dfn.de"
hs-musterstadt.de.            IN CAA 0 issue "weitere-beispiel-pki.de"
second-sub.hs-musterstadt.de. IN CAA 0 issue "example-pki.org"

Soll der FQDN www.institut.second-sub.hs-musterstadt.de in ein Zertifikat aufgenommen werden, so wird die PKI mit folgenden DNS-Abfragen nach CAA RRs suchen:

www.institut.second-sub.hs-musterstadt.de
    institut.second-sub.hs-musterstadt.de
             second-sub.hs-musterstadt.de

Bei second-sub.hs-musterstadt.de. wird sie dann fündig und erhält den oben genannten CAA RR zurück.

Damit darf für Systeme unterhalb von second-sub.hs-musterstadt.de. nur die „Example PKI“ Zertifikate ausstellen. Die CAA RRs von hs-musterstadt.de sind überschrieben.

CNAMEs

Eine weitere gedankliche Herausforderung stellen CNAMEs dar. Hierbei müssen PKIs auf der Suche nach CAA RRs dem CNAME bis zur DNS Root folgen.

Wird im CNAME-Zweig kein CAA RR gefunden, muss dann beim Ursprung des CNAMEs in der Original-Domain weiter bis zur DNS Root hinauf gesucht werden.

Im Beispiel (wieder ohne SOA, NS, o.ä.):

hs-musterstadt.de.       IN CAA 0 issue "pki.dfn.de"
hs-musterstadt.de.       IN CAA 0 issue "weitere-beispiel-pki.de"
cname.hs-musterstadt.de. IN CNAME sub.uni-musterstadt.de.

; Kein CAA in sub.uni-musterstadt.de und uni-musterstadt.de.

Eine PKI wird in dieser Konstellation die folgenden Domains auf CAA RRs abfragen:

cname.hs-musterstadt.de => CNAME sub.uni-musterstadt.de
   sub.uni-musterstadt.de
       uni-musterstadt.de
                       de
hs-musterstadt.de

In hs-musterstadt.de. wird erstmals ein CAA RR gefunden, und es greift die Begrenzung auf die DFN-PKI und die „Weitere PKI“

Anders sieht es aus, wenn uni-musterstadt.de. selbst CAA RRs setzt:

hs-musterstadt.de.       IN CAA 0 issue "pki.dfn.de"
hs-musterstadt.de.       IN CAA 0 issue "weitere-beispiel-pki.de"
cname.hs-musterstadt.de. IN CNAME sub.uni-musterstadt.de.

uni-musterstadt.de.      IN CAA 0 issue "example-pki.org"

In diesem Beispiel  werden nur die folgenden Abfragen gemacht, da in uni-musterstadt.de ein CAA RR gefunden wird:

cname.hs-musterstadt.de  => CNAME sub.uni-musterstadt.de
 sub.uni-musterstadt.de
     uni-musterstadt.de

Damit darf nur die „Example PKI“ für cname.hs-musterstadt.de ausstellen.

issuewild

Neben dem bisher betrachteten Feld issue ist im RFC das Feld issuewild definiert. issuewild beschränkt die Ausgabe von Wildcard-Zertifikaten. (Informationen zu Wildcard-Zertifikaten finden Sie unter: https://www.pki.dfn.de/faqpki/faqpki-allgemein/#c18091)

Dabei ist die Logik wie folgt:

  • Existieren issuewild-Einträge, werden Wildcard-Zertifikate auf die angegebenen PKIs beschränkt.
  • Existiert kein issuewild, aber issue-Einträge, werden diese auch zur Beschränkung von Wildcard-Zertifikaten herangezogen.

Hiermit lässt sich die Ausstellung von Wildcard-Zertifikaten ganz unterbinden:

hs-musterstadt.de. IN CAA 0 issue "pki.dfn.de"
hs-musterstadt.de. IN CAA 0 issuewild ";"

In diesem Beispiel ist für Wildcard-Zertifikate nur der Wert „;“ angegeben; damit dürfen diese für hs-musterstadt.de von keiner PKI ausgestellt werden. Für alle anderen Zertifikate wird die DFN-PKI verwendet.

Fazit

CAA RRs geben eine Policy vor, die von Unterdomains oder über CNAME-Verlinkungen überschrieben oder geändert werden können. Die Auswertungsregeln von RFC 6844 können zu überraschenden Ergebnissen führen. Es empfiehlt sich daher, die Einführung von CAA RRs geplant und mit Bedacht durchzuführen.

(jbr, 12.09.2017)