Schlagwort-Archive: CAA

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)

RFC 6844 Certification Authority Authorization (CAA)

Seit Anfang 2013 gibt es den RFC 6844 „Certification Authority Authorization“ (CAA). CAA spezifiziert einen gleichnamigen Resource Record zur Ablage im DNS, mit dem ein Domain-Inhaber festlegen kann, welche Zertifizierungsstelle (CA) für seine Domain Zertifikate ausgeben darf.

Das CA/Browser-Forum verpflichtet mit Ballot 187 jede CA, ab spätestens September 2017 diese CAA Resource Records auszuwerten und zu beachten.

In der DFN-PKI wird dieser Mechanismus zum Sommer 2017 unterstützt werden.

Mechanismus

CAA RRs werden vor der Ausstellung von Zertifikaten durch die CA ausgewertet. Es wird geprüft, ob der Domain-Inhaber einen CAA RR mit der entsprechenden CA gesetzt hat. Gibt es keinen CAA RR, so kann jede CA für die Domain zertifizieren.

CAA wird also nicht von Nutzern von Zertifikaten ausgewertet, sondern ausschließlich von Zertifizierungsstellen exakt zum Zeitpunkt der Ausstellung des Zertifikats. Eine Auswertung durch Nutzer zum Zweck der Zertifikatvalidierung ist im RFC explizit ausgeschlossen.

Im RFC wird empfohlen, CAA in Kombination mit DNSSEC einzusetzen. Die Nutzung ohne DNSSEC ist aber ebenfalls erlaubt.

CAA definiert drei Properties:

  • issue enthält als Wert die Domain der CA, die für die Domain, in der die CAA RRs definiert sind, Zertifikate ausstellen darf.
  • issuewild hat dieselben Eigenschaften wie issue, wird aber für Wildcard-Zertifikate ausgewertet. Ist kein issuewild gesetzt, wird auch für Wildcard-Zertifikate issue ausgewertet
  • iodef spezifiziert Kontaktadressen des Domain-Inhabers, unter denen Probleme oder Verletzungen der CAA-Policy gemeldet werden können.

Die Properties können mehrmals spezifiziert werden, so dass mehreren CAs die Erlaubnis zur Zertifizierung für eine Domain gegeben werden kann.

Die Auswertung geschieht, wie im DNS üblich, hierarchisch aufsteigend und unter Befolgung von CNAME oder DNAME Einträgen. Für eine Zertifikatanfrage für den Domainnamen X.Y.Z wird zunächst im DNS unter X.Y.Z nach CAA RRs gesucht, dann unter Y.Z, dann unter Z.

Ein Beispiel einer Zonendatei mit CAA RRs für die DFN-PKI:

$ORIGIN hs-musterstadt.de
. CAA 0 issue "pki.dfn.de"
. CAA 0 iodef "mailto:certadmin@hs-musterstadt.de"

Werte für die DFN-PKI

Die DFN-PKI wird die issue-Werte „pki.dfn.de“ und „dfn.de“ akzeptieren:

. CAA 0 issue "pki.dfn.de"

oder

. CAA 0 issue "dfn.de"

Konsequenzen für die Web-RA-Schnittstelle

Die Auswertung von CAA ist nur mit erheblicher Implementierungsarbeit umzusetzen. Diese können wir leider nur für die SOAP-Schnittstelle der DFN-PKI (und damit für die Java RA-Oberfläche) realisieren.

Daher werden wir leider das Genehmigen von Zertifikatanträgen in der Web-RA-Schnittstelle für PKIs im Browserverankerten Sicherheitsniveau „Global“ deaktivieren müssen. Bitte verwenden Sie zum Genehmigen von Zertifikatanträgen die Java RA-Oberfläche (Java Webstart https://pki.pca.dfn.de/guira/guira.jnlp).

(jbr, 17.03.2017)