Archiv für den Monat: April 2018

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)

RA-Zugang zur alten DFN-PKI Generation bei Neueinrichtung mit TS-Operator-Zertifikat aus der neuen DFN-PKI Generation 2

Wo ist mein bestehender RA-Zugang zur alten DFN-PKI Generation 1 in der Java RA-Oberfläche geblieben?

Nach einer kompletten Neuinstallation Ihres Betriebssystems oder der Neukonfiguration der Java RA-Oberfläche (z.B. unter einem anderen Nutzerkonto) mit einem TS-Operator-Zertifikat der neuen DFN-PKI Generation 2 steht der RA-Zugang zur alten DFN-PKI Generation 1 zunächst nicht mehr in der Java RA-Oberfläche zur Verfügung.

Um auch diesen RA-Zugang zur alten DFN-PKI Generation 1 in der Java RA-Oberfläche wieder herzustellen, ist etwas Handarbeit nötig: Die Konfigurationsdatei der Java RA-Oberfläche muss manuell von Ihnen angepasst werden:

  1. Ggf. beenden Sie die noch laufende Java RA-Oberfläche.
  2. Suchen Sie unterhalb Ihres Home-Verzeichnisses nach der Datei configuration.xml im Verzeichnis .dfn-pki.
  3. Machen Sie ggf. eine Sicherheitskopie dieser Datei.
  4. Öffnen Sie die Datei configuration.xml in einem ASCII-Text-Editor.
  5. Suchen Sie darin den aktuellen Abschnitt für den RA-Zugang zur neuen DFN-PKI Generation, z.B.

    <node type=“de.dfncert.guira.pki.DFNPKICATreeNode“>
    <property name=“caName“>dfn-ca-global-g2</property>
    <property name=“raAlias“>Alias-Name des TS-Operator-Zertifikats</property>
    <property name=“raSource“>/Pfad/zum/TS-Operator-Zertifikat-G2.p12</property>
    <property name=“displayName“>Uni Musterstadt CA G2</property>
    <property name=“raType“>PKCS12</property>
    </node>

  6. Kopieren Sie diesen Abschnitt einschließlich der den Abschnitt einfassenden <node type=…> und </node> Tags und fügen Sie ihn gleich dahinter nochmals ein.
  7. Im eingefügten Abschnitt ändern Sie jetzt die Properties für caName und displayName wie folgt ab:
    1. Als neuen CA-Namen setzen Sie den bekannten CA-Namen aus der alten DFN-PKI Generation 1. Diesen können Sie z.B. aus den alten Web-URLs zur Zertifikatsbeantragung in der alten DFN-PKI Generation 1 ableiten. Für eine beispielhafte Web-URL der Form https://pki.pca.dfn.de/uni-musterstadt-ca/cgi-bin/pub/… aus der alten DFN-PKI Generation 1 ist uni-musterstadt-ca der gesuchte CA-Name für diesen neuen Konfigurationsabschnitt.
    2. Ändern Sie auch den Display-Namen auf z.B. Uni Musterstadt CA G1 ab, so dass Sie diesen neuen Eintrag im Anzeigebaum der Java RA-Oberfläche wiedererkennen können.
    3. Der neue Abschnitt für den RA-Zugang zur alten DFN-PKI Generation 1 sieht dann nach unserem Beispiel wie folgt aus:

      <node type=“de.dfncert.guira.pki.DFNPKICATreeNode“>
      <property name=“caName“>uni-musterstadt-ca</property>
      <property name=“raAlias“>Alias-Name des TS-Operator-Zertifikats</property>
      <property name=“raSource“>/Pfad/zum/TS-Operator-Zertifikat-G2.p12</property>
      <property name=“displayName“>Uni Musterstadt CA G1</property>
      <property name=“raType“>PKCS12</property>
      </node>

      Die anderen Properties wurden hierbei unverändert übernommen.

  8. Speichern Sie die Datei ab.
  9. Starten Sie die Java RA-Oberfläche.

(rkm, 13.04.2018)