Archiv des Autors: Juergen Brauckmann

Firefox 59, Windows und Probleme mit dem Zertifikatexport

[Update 22.3.: Thunderbird Im-/Export als weiteren Workaround]

Seit wenigen Tagen ist Firefox 59 verfügbar. Bei dieser Version kommt es beim Export von Zertifikaten zu einem Problem im Zusammenspiel mit Windows: Die aus Firefox exportierten Zertifikate im PKCS#12-Format sind nicht mehr in den Windows-Systemstore importierbar. Die Meldung von Windows lautet: „Das eingegebene Kennwort ist falsch“.

Mutmaßlicher Hintergrund: Firefox 59 setzt die Iterationen der Schlüsselableitungsfunktion zum Verschlüsseln des PKCS#12 auf den Wert 1.000.000 (Wert bei Firefox 58 war 100.000). Mit diesem Wert kommt anscheinend die Krypto-Bibliothek von Windows nicht zurecht.

Ticket bei Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1436873

Mögliche Abhilfe: Exportierte PKCS#12-Files können mit openssl oder einem anderen Werkzeug umkodiert werden. Dabei wird dann üblicherweise eine Windows-kompatible Anzahl an Iterationen verwendet.

Anleitung openssl: https://blog.pki.dfn.de/2018/02/pkcs12-akrobatik/

Fertiges Werkzeug (Windows-Executable) von den Kollegen vom Steinbuch Centre for Computing des KIT: https://git.scc.kit.edu/KIT-CA/RecodeCertificate/blob/master/README.md

Auch ein Import des PKCS#12 in den Mailclient Thunderbird (getestet mit Version 52.6.0) mit anschließendem Export erzeugt ein Objekt, das in Windows importiert werden kann.

(jbr, 21.03.2018)

Ausblick: Umstellung der Verfahren zur Freischaltung von Domains

[Update 21.03.: SOA-RR ergänzt]

Anfang Februar hat das CA/Browser Forum mit Ballot 218 festgelegt, dass
bestimmte auch in der DFN-PKI verwendete Verfahren zur Prüfung der
berechtigten Aufnahme von Domains in Serverzertifikaten umgestellt werden müssen.

Auf der letzten DFN-Betriebstagung am 14.-15.03.18 haben wir weitere Details der aktuellen Umstellungspläne vorgestellt, die Sie im Abschnitt „Validierung von Domains“ der Folien finden: https://www.dfn.de/fileadmin/3Beratung/Betriebstagungen/bt68/BT68_Sicherheit_NeuesPKI_Brauckmann.pdf

Nachtrag 21.03.:

Zusätzlich zu den Methoden, die in den Folien der Betriebstagung genannt sind, werden wir direkt im ersten Schritt eine Challenge-E-Mail an die E-Mail-Adresse des Zonenverwalters unterstützen. Diese E-Mail Adresse ist im SOA Resource Record zu der zu validierenden Domain im DNS hinterlegt (RNAME im SOA RR nach RFC 1035).

Beispiel anhand des SOAs für example.net:

example.net. 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2018013032 7200 3600 1209600 3600

Der Teilnehmerservice könnte in diesem Beispiel bestimmen, dass für eine Validierung die Challenge-E-Mail an noc@dns.icann.org gesendet wird. Auch die in den Folien bereits genannten Adressen hostmaster@example.net, webmaster@example.net, postmaster@example.net, admin@example.net, administrator@example.net wären zulässig.

(jbr, 19.03.2018)

Version 3.8 der Zertifizierungsrichtlinie DFN-PKI Global

Zum 19.03.2018 tritt die Zertifizierungsrichtlinie 3.8 im Sicherheitsniveau „Global“ in Kraft.

Änderungen in Version 3.8:

* Kapitel 3.2.2, Domain-Autorisierungen umgearbeitet.

Die neue Zertifizierungsrichtlinie (CP) finden Sie unter der folgenden URL:

https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.8.pdf

Mit Änderungsmarkierungen:

https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_redline_V3.8.pdf

(jbr, 19.03.2018)

 

 

Version 3.7 des CP DFN-PKI „Global“, Änderungen an weiteren Dokumenten

Als Ergebnis des letztjährigen Audits der DFN-PKI tritt zum 15.02.2018 eine neue Version 3.7 der Zertifizierungsrichtlinie der DFN-PKI im Sicherheitsniveau „Global“ in Kraft.

Die wichtigsten Änderungen sind im Einzelnen:

  • Neuer Audit-Standard ETSI EN 319 411-1
  • Klarstellungen bzgl. Verbots von E-Mail-Adressen in Serverzertifikaten
  • Klarstellungen bzgl. der Sperrgründe in Kapitel 4.9.1

Das neue CP finden Sie unter der folgenden URL:
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.7.pdf

Mit Änderungsmarkierungen:
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.7_redline.pdf

Änderungen an den Dokumenten „Pflichten der Teilnehmer“ und „Informationen für Zertifikatinhaber“

In „Pflichten der Teilnehmer“ wurden Regelungen für den Betrieb von Mailgateways aufgenommen. Des Weiteren wurde ein Passus zum regelmäßigen Audit der DFN-PKI „Global“ und die Notwendigkeit der Unterstützung durch die Teilnehmer ergänzt.

In „Informationen für Zertifikatinhaber“ wurden Hinweise für den Betrieb von Mailgateways und zur oben aufgeführten Veröffentlichung von Serverzertifikaten in Certificate Transparency eingeführt.

Die Dokumente finden Sie unter:

https://www.dfn.de/fileadmin/PKI/anleitungen/Pflichten-der-Teilnehmer_V1.3.pdf

https://www.dfn.de/fileadmin/PKI/anleitungen/Informationen-fuer-Zertifikatinhaber_V1.2.pdf

Mit Änderungsmarkierungen:

https://www.dfn.de/fileadmin/PKI/anleitungen/Pflichten-der-Teilnehmer_V1.3_redline.pdf

https://www.dfn.de/fileadmin/PKI/anleitungen/Informationen-fuer-Zertifikatinhaber_V1.2_redline.pdf

(jbr, 30.01.2018)

Certificate Transparency in der DFN-PKI

Als Konsequenz aus Problemen mit den Zertifizierungsprozessen bei einigen CAs, die in den letzten Jahren offenbar wurden, haben Forscher u.a. von Google ein System namens Certificate Transparency (CT) entwickelt.

Hierbei handelt es sich um einen Mechanismus, mit dem ausgestellte Serverzertifikate von einer oder mehreren Sammelpunkten öffentlich einsehbar gehalten werden. Ziel ist die Erhöhung der Transparenz der Browser-PKI durch die komplette Überprüfbarkeit der CAs durch die Öffentlichkeit.

Diese Sammelpunkte sind die Kernkomponenten des Certificate Transparency Systems, sie werden als Certificate Transparency Logs (CT-Logs) bezeichnet und von beliebigen Parteien betrieben. Über kryptographische Beweise (Consistency Proofs über Merkle Hash Trees) ist sichergestellt, dass Außenstehende eine nachträgliche Manipulation des CT-Logs bemerken können.

Einen technischen Überblick über die Funktionsweise bietet https://www.certificate-transparency.org

Weitere Erläuterungen finden sich in folgendem Golem-Artikel (die dort dargestellte Timeline von Google Chrome ist allerdings überholt): https://www.golem.de/news/certificate-transparency-betrug-mit-tsl-zertifikaten-wird-fast-unmoeglich-1610-124024.html

Praktischer Einsatz

Google hat angekündigt, dass sein Browser Chrome ab Frühjahr 2018 erzwingen wird, dass neu ausgestellte Serverzertifikate der öffentlichen Browser-PKI in CT-Logs veröffentlicht werden. Chrome setzt dies um, indem beim TLS-Verbindungsaufbau das Vorhandensein von mehreren sogenannten Signed Certificate Timestamps (SCTs), kryptographisch gesicherte Artefakte von der Veröffentlichung eines Zertifikats, geprüft wird. Können von Chrome keine SCTs geprüft werden, wird die Webseite als unsicher klassifiziert, wobei die genaue Art der Darstellung in Chrome noch unbekannt ist.

Es gehört inzwischen zu den Qualitätsmerkmalen einer PKI, am Certificate Transparency System teilzunehmen und ausgestellte Serverzertifikate über CT-Logs verfügbar zu machen. Auch die DFN-PKI wird selbstverständlich Certificate Transparency unterstützen. Ab 26.02.2018 werden alle Serverzertifikate in der DFN-PKI Sicherheitsniveau Global in CT-Logs veröffentlicht.

Wichtig: Es gibt keine Auswirkungen auf bereits ausgestellte Serverzertifikate! Diese sind nicht betroffen, bleiben nach unserem Kenntnisstand auch in Google Chrome voll gültig und müssen nicht ausgetauscht werden.

Die DFN-PKI wird die folgenden CT-Logs verwenden:
https://plausible.ct.nordu.net
https://mammoth.ct.comodo.com
https://sabre.ct.comodo.com
https://ct.googleapis.com/rocketeer
https://ct.googleapis.com/pilot

(Diese Liste stellt den aktuellen Stand vom Februar 2018 dar. Die von der DFN-PKI verwendeten CT-Logs können sich kurzfristig und ohne Vorankündigung ändern. Zertifikate aus der DFN-PKI können über Uploads von Dritten auch in anderen als den aufgeführten CT-Logs erscheinen. Eine aktuelle Liste ist erhältlich über https://www.pki.dfn.de/faqpki/faqpki-allgemein/#c19130)

Auslieferung von SCTs

Die DFN-PKI stellt die oben erwähnten notwendigen Signed Certificate Timestamps direkt als Erweiterung in den ausgestellten Serverzertifikaten zur Verfügung („Embedded SCT“). Ein Beispiel mit eingebetteten SCTs finden Sie unter: https://crt.sh/?id=313019897

Grundsätzlich gibt es im Certificate Transparency System noch weitere Möglichkeiten, wie die SCTs einem Browser zugänglich gemacht werden können („OCSP Stapling“, „TLS Extension“). Diese anderen Varianten setzen aber üblicherweise Konfigurationseingriffe des Serveradministrators voraus.

Durch die von der DFN-PKI gewählte Variante der Embedded SCT müssen Serveradministratoren keine Änderungen an ihrem System vornehmen.

Zustimmung zur Veröffentlichung

Neben der rein technischen Anbindung, die von der DFN-PKI in den letzten Monaten umgesetzt worden ist, ergibt sich eine Änderung für Antragssteller: Wird ein Serverzertifikat in der DFN-PKI im Sicherheitsniveau Global beantragt, so muss in Zukunft der Antragssteller der Veröffentlichung zustimmen. Ohne diese Zustimmung wird in der DFN-PKI in Zukunft kein Serverzertifikat mehr erstellt werden können.

Des Weiteren ist eine Rücknahme dieser Zustimmung nicht mehr möglich. Technischer Hintergrund: Ein einmal mit Certificate Transparency veröffentlichtes Zertifikat kann technisch nicht mehr „depubliziert“ werden.

Nutzerzertifikate sind selbstverständlich von dieser Änderung nicht betroffen und werden generell nicht durch die DFN-PKI in den CT-Logs veröffentlicht. Je nach Grundeinstellung Ihres PKI-Zugangs sind auch weiterhin nicht-öffentliche Nutzerzertifikate möglich, die damit dann auch nicht über die von der DFN-PKI selbst betriebenen Verzeichnisdienste (LDAP und Web-Suche) veröffentlicht werden. Die gesetzlich vorgeschriebenen Widerrufsmöglichkeiten werden für Nutzerzertifikate natürlich ebenfalls vollumfänglich angeboten.

 (jbr, 30.01.2018)

Löschen privater Schlüssel in Firefox

Firefox speichert die privaten Schlüssel zu importierten Zertifikaten in einer Datenbank im Benutzerprofil. Dabei können zwei unterschiedliche Datenbankformate zur Anwendung kommen: Bisheriger Standard war die Berkeley DB, mit Firefox 58 wird ausschließlich SQLite zum Einsatz kommen.

Löschprobleme

Die aktuell überwiegend verwendete Berkeley DB markiert zu löschende Schlüssel lediglich als gelöscht, statt sie tatsächlich zu entfernen. Ist die DB nicht durch ein Masterpasswort geschützt, lassen sich die Schlüssel nach dem vermeintlichen Löschen weiterhin auslesen. (Die Verwendung eines Masterpassworts ist grundsätzlich ratsam, da die privaten Schlüssel sonst permanent ungeschützt auf der Festplatte liegen.)

In einem einfachen Experiment lässt sich das Problem nachvollziehen:

Unter der besonderen Adresse „about:support“ lässt sich das Profilverzeichnis öffnen; dort findet sich die key3.db, in der Firefox die privaten Schlüssel speichert. Beobachtet man diese Datei in einem Hexeditor, während man ein Zertifikat importiert, stellt man fest, dass sich ein signifikanter Block durch den neu hinzukommenden Schlüssel ändert. Löscht man das Zertifikat wieder, ist der Unterschied nur wenige Bytes groß. Der Schlüssel wird also nicht korrekt entfernt.

Won’t fix

Dieses Verhalten wird von den Entwicklern als Bug eingestuft, aber vermutlich nicht mehr behoben, da neue Firefox-Versionen nicht mehr betroffen sein werden:

https://bugzilla.mozilla.org/show_bug.cgi?id=1413994

Ab Firefox 58 wird eine bestehende Berkeley DB von Firefox auf eine SQLite-DB aktualisiert. Das neue Format hat das Löschproblem nicht mehr, daher wird es auch keine Aktualisierung der zugrunde liegenden Bibliothek geben.

Problematisch ist jedoch, dass bestehende key3.db-Dateien nicht entfernt werden. In langlebigen Profilordnern oder deren archivierten Backups werden also auch noch in einigen Jahren die längst gelöscht geglaubten Schlüssel zu finden sein.

Abhilfe

Der wichtigste Schritt ist das Setzen eines Masterpassworts. Ohne ein Masterpasswort sind die privaten Schlüssel nicht ausreichend geschützt. Denn unabhängig vom identifizierten Bug können ungeschützte private Schlüssel durch forensische Analyse aus früheren Versionen der key3.db von einer Festplatte extrahiert werden.

Das Passwort kann in den Einstellungen unter „Sicherheit“ gesetzt werden. (Direkt erreichbar unter about:preferences#security)

Unabhängig davon, ob ein Masterpasswort aktiv verwendet wird oder nicht, sorgt ein zwischenzeitliches Ändern des Passwortes (falls man kein Masterpasswort verwenden möchte: Aktivieren –> Setzen –> wieder Deaktivieren) für die Verwendung eines neuen Salzes, so dass die Datenbank neu verschlüsselt wird. Gelöschte Schlüssel werden dabei nicht verändert und können mit dem neuen Salz nicht mehr entschlüsselt werden. Daher sorgt eine Änderung des Masterpasswortes dafür, dass gelöschte Schlüssel unzugänglich werden.

Linux-Benutzer können mit folgenden Befehlen auf der Kommandozeile ein neues Masterpasswort setzen:

# Pfad zum Firefoxprofil (bei mehreren Profilen das Sternchen ersetzen)
 profile=~/.mozilla/firefox/*.default
 # Anzeigen vorhandener privater Schlüssel
 certutil -d $profile -K
 # Setzen eines neuen Masterpasswortes
 certutil -d $profile -W

Falls bislang kein Masterpasswort gesetzt war, kann die entsprechende Frage einfach mit Enter beantwortet werden.

Wichtig: Firefox muss vollständig beendet worden sein, bevor versucht wird, mit separaten Programmen wie certutil auf die Datenbank zuzugreifen! Andernfalls kann die Datenbank unwiderruflich beschädigt werden.

Für die Verwendung von certutil gibt es weitere Informationen unter:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Reference/NSS_tools_:_certutil

Nach dem Umstieg auf Firefox 58 kann die key3.db gelöscht (eventuell mit vorherigem Backup auf USB-Stick o.ä.) und damit alle potentiellen Altlasten entfernt werden.

(11.01.2018, Finn Nielsen)

ETSI-Audit 2017 abgeschlossen

Auch 2017 wurde die DFN-PKI selbstverständlich auditiert. Im Gegensatz zu den vergangenen Jahren wurde diesmal der Standard ETSI EN 319 411-1 verwendet.

Hintergrund hierfür: Zur Umsetzung der eIDAS-Verordnung wurden die europäischen technischen Richtlinien und Standards für Trust Service Provider durch die ETSI grundlegend umgestaltet. Damit wurde auch die bisherige ETSI TS 102 042, nach der die DFN-PKI bisher auditiert wurde, durch die ETSI EN 319 411-1 abgelöst.

Auch diesmal fanden angekündigte und vorbereitete Besuche bei Teilnehmern der DFN-PKI statt, bei der die Arbeit des Teilnehmerservice stichprobenartig untersucht wurde. Wir bedanken uns wieder bei allen Einrichtungen, die ein erfolgreiches Audit der DFN-PKI  ermöglicht haben!

Die Bescheinigung über das Audit ist auf den Webseiten von TÜViT zu finden: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/6771UD_s.pdf

 

(jbr, 08.01.2017)

Konfiguration von TLS-Servern: Aktueller Cipher-String

Bekanntermaßen ist die Konfiguration der Crypto-Parameter von TLS-Servern  eine kontinuierliche Aufgabe, siehe hierzu auch den ausführlichen Artikel Konfiguration von TLS-Servern: Ständige Herausforderung.

In unserem aktuellen Apache Cipher-String haben wir 3DES entfernt:

SSLCipherSuite 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!eNULL:!LOW:!RC4:!MD5:!EXP:!PSK:!DSS:!SEED:!ECDSA:!CAMELLIA'

Bitte beachten Sie auch die weiteren Konfigurationsempfehlungen aus dem oben genannten Artikel , insbesondere die Anleitung für individuelle Diffie-Hellman-Parameter!

(jbr, 10.12.2017)

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)