Schlagwort-Archive: CAA

Der CAA-Record im DNS ist nicht passend gesetzt

Seit September 2017 muss jede CA, die den Regeln des CA/Browser-Forums unterliegt, vor der Ausstellung eines Serverzertifikats CAA Resource Records im DNS prüfen. Eine Beschreibung des Systems findet sich in den folgenden Artikeln:

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

https://blog.pki.dfn.de/2017/09/caa-rrs-reihenfolge-im-dns

In der DFN-PKI im Sicherheitsniveau Global wird die Prüfung direkt im Anschluss an das Genehmigen eines Serverzertifikat-Antrags in der Java RA-Oberfläche durchgeführt. Der Prüf-Mechanismus läuft dabei selbstverständlich auf den Servern der DFN-PKI, nicht in der Java RA-Oberfläche. Ist die Prüfung nicht erfolgreich, erscheint die folgende Fehlermeldung:


Hierfür kann es mehrere Ursachen geben. Zur Untersuchung können die DNS-Abfragen, die das DFN-PKI-System durchführt, manuell nachgestellt werden. Ein nützliches Werkzeug ist dig. Achtung: Nur relativ neue Versionen unterstützen die Abfrage von CAA-Records in einer leserlichen Form. Eine Alternative sind Web-Werkzeuge wie z.B. die Dig-Toolbox von Google https://toolbox.googleapps.com/apps/dig/#CAA/

Erscheint die Fehlermeldung beispielsweise für den Namen www.sub1.hs-musterstadt.de, so sollten nacheinander die folgenden Abfragen durchgeführt werden:

dig +adflag www.sub1.hs-musterstadt.de CAA
dig +adflag sub1.hs-musterstadt.de CAA
dig +adflag hs-musterstadt.de CAA
dig +adflag de CAA

Wichtig: Der verwendete rekursive Resolver muss security-aware sein und DNSSEC validieren. Wenn der Standard-Resolver Ihrer Einrichtung dies nicht leistet, muss ein alternativer validierender Resolver wie 1.1.1.1 oder 8.8.8.8 verwendet werden.

Ergibt eine Abfrage einen CNAME, muss auch das CNAME-Target auf CAA-Records abgefragt werden.

Im Idealfall ergeben alle Abfragen einen Status NOERROR oder NXDOMAIN (kein SERVFAIL). Wenn CAA-Records gefunden werden, so sollten diese immer auch den Wert pki.dfn.de enthalten.

Die Prüfung bricht stets beim ersten gefundenen CAA-Record ab.

Mögliche Fehlerursache: CAA-Record für falsche PKI gesetzt

Wenn Sie beispielsweise nur folgenden Record finden, ist es der DFN-PKI nicht erlaubt, Zertifikate auszustellen:

sub1.hs-musterstadt.de. IN CAA 0 issue "letsencrypt.org"

Lösung: Zusätzlichen CAA-Record hinzufügen.

sub1.hs-musterstadt.de. IN CAA 0 issue "letsencrypt.org"
sub1.hs-musterstadt.de. IN CAA 0 issue "pki.dfn.de"

Mögliche Fehlerursache: Defekter CAA-Record gesetzt

Mindestens ein uns bekanntes DNS-Management-Werkzeug produziert defekte CAA-Records, die die Ausstellung von Zertifikaten verhindern (beachten Sie den fehlenden Typ „issue“ vor dem Wert „pki.dfn.de“):

sub1.hs-musterstadt.de. IN CAA 0 0 "pki.dfn.de"

Lösung: Defekten CAA-Record entfernen oder Werkzeug dazu überreden, korrekte Records zu setzen.

Mögliche Fehlerursache: Abfrageprobleme (SERVFAIL) in Kombination mit DNSSEC

Bei Fehlern bei der DNS-Abfrage muss die DFN-PKI prüfen, ob die Zone mit DNSSEC gesichert sein sollte. Wenn dies der Fall ist, muss die Ausstellung von Zertifikaten abgelehnt werden. Insbesondere verhindern Nameserver, die (aus welchen Gründen auch immer) nicht aus dem Internet erreichbar sind, die Ausstellung von Zertifikaten, wenn die übergeordnete Zone mit DNSSEC gesichert ist.

Beispiel: Bei der Abfrage von sub1.hs-musterstadt.de kommt es zu einem Fehler, erkennbar am Header-Feld „status: SERVFAIL“:

$ dig +adflag sub1.hs-musterstadt.de
; <<>> DiG 9.11.3 <<>> +adflag sub1.hs-musterstadt.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62481

Wie ist nun der Zustand der übergeordneten Zone?

$ dig +adflag hs-musterstadt.de

; <<>> DiG 9.11.3 <<>> +adflag hs-musterstadt.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36721
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7

Da „flags: …ad“ zurückgeliefert wird, ist hs-musterstadt.de DNSSEC-geschützt. Damit kann die DFN-PKI keine Zertifikate für sub1.hs-musterstadt.de ausstellen.

Die Lösung hängt von der Ursache des SERVFAIL ab. Ist der eingetragene Nameserver nur für interne Zwecke vorgesehen und aufgrund von Router-ACLs nicht erreichbar, so bleibt leider keine andere Möglichkeit, als entweder für die DFN-PKI eine Erreichbarkeits-Ausnahme zu implementieren, oder aber die Zonen-Delegation aus der externen Sicht der hs-musterstadt.de-Nameserver zu entfernen (unterschiedliche Views für interne und externe Abfrager).

Liegt der Abfragefehler bei einer defekten DNSSEC-Konfiguration, so sollte diese repariert werden. Für eine genauere Analyse müssen in der Regel weitere Werkzeuge wie z.B. http://dnsviz.net verwendet werden.

Sollte die Ursache für die Fehlermeldung „Der CAA-Record im DNS ist nicht passend gesetzt“ weiterhin unklar bleiben, so helfen wir Ihnen gerne bei der Analyse. Kontakt: mailto:dfnpca@dfn-cert.de

(jbr, 30.04.2018)

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)