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)

eduroam- und RADIUS-Serverzertifikate aus der neuen DFN-PKI Generation 2

Für eduroam (DFNRoaming) werden an unterschiedlichen Stellen SSL-Zertifikate genutzt. Bevor nun in einer eduroam-Installation einer Organisation SSL-Zertifikate der neuen Generation 2 der DFN-PKI eingesetzt werden sollen, sind ein paar Dinge zu beachten, Vorkehrungen zu treffen und möglicherweise die eigenen NutzerInnen zu informieren, speziell bei einer Migration der genutzten SSL-Zertifikate von der alten auf die neue DFN-PKI Generation 2.

Der naive Austausch bestehender SSL-Zertifikate für die eduroam-RADIUS-Server der DFN-PKI Generation 1 durch neue SSL-Zertifikate der neuen DFN-PKI Generation 2 führt für die eigene Nutzerschaft fast zwangsläufig zum Verlust der eduroam-Konnektivität. Noch ist Zeit, den Übergang sorgfältig vorzubereiten und diese sollte jetzt genutzt werden.

Erstmalige Einrichtung einer eduroam-Infrastruktur mit der neuen DFN-PKI Generation 2

Sofern die eduroam-Infrastruktur in einer Einrichtung zum ersten Mal aufgebaut wird, und dabei von Anfang an ausschließlich SSL-Zertifikate aus der neuen DFN-PKI Generation 2 zum Einsatz kommen, ist nichts Besonderes zu beachten. Falls für die eigenen NutzerInnen eduroam Installationsprogramme des eduroam Configuration Assistant Tools (CAT, https://cat.eduroam.de) zur Verfügung gestellt werden, so sind – wie erwartet – bei den entsprechenden Konfigurationsoptionen in der CAT-Verwaltung jeweils die CA-Zertifikate aus der neuen DFN-PKI Generation 2 anzugeben. Genauso sind die CA-Zertifikatsketten der Server-Konfigurationen (RADIUS-, RadSec- bzw. radsecproxy-Server) mit den CA-Zertifikaten aus der neuen DFN-PKI Generation 2 zu versehen.

Migration einer bestehenden eduroam-Infrastruktur von der alten auf die neue DFN-PKI Generation 2

Interessanter wird es, wenn eine bestehende eduroam-Infrastruktur von SSL-Zertifikaten der alten DFN-PKI Generation auf Zertifikate der neuen DFN-PKI Generation 2 umgestellt werden soll:

1. RadSec für die Verbindung vom RADIUS-Server zum übergeordneten RADIUS-Server beim DFN

Die SSL-Zertifikate von RadSec- bzw. radsecproxy-Servern können ohne weiteres sofort durch SSL-Zertifikate der neuen DFN-PKI Generation 2 ausgetauscht werden. Hierbei muss natürlich darauf geachtet werden, dass dabei auch die CA-Zertifikatskette passend zum neuen Serverzertifikat ausgetauscht wird und die vertrauenswürdigen CA-Zertifikate zur Authentisierung von eingehenden Verbindungen sowohl die CA-Zertifikatskette der alten als auch die der neuen DFN-PKI Generation 2 enthält. Ändern sich FQDN und/oder IP-Adresse des RadSec- bzw. radsecproxy-Servers, oder wird dabei gleichzeitig von einer radsecproxy Version < 1.6 auf eine höhere Version der radsecproxy Server-Software aktualisiert, so sollte das vorher unbedingt mit dem eduroam-Team vom DFN (eduroam@dfn.de) abgestimmt werden.

Gibt es in der eigenen Einrichtung eine verschachtelte lokale RadSec-Infrastruktur, so muss darauf geachtet werden, dass auch die weiteren lokalen RadSec-Server client-authentisierte Verbindungen von Zertifikaten der neuen DFN-PKI Generation 2 akzeptieren. Es muss also auch dort die CA-Zertifikatskette der neuen DFN-PKI Generation 2 zu den vertrauenswürdigen CA-Zertifikaten hinzugefügt werden.

2. RADIUS-Server für die Authentisierung der NutzerInnen

Die Umstellung des RADIUS-Servers (EAP-Server) zur eigentlichen Authentisierung der bei den EndnutzerInnen installierten 802.1X-Supplikanten ist sehr sorgfältig zu planen, da hier das Potential besteht, die gesamte eigene eduroam-Nutzerschaft abzuhängen und zur erneuten Konfiguration der WLAN-Einstellungen für das eduroam zu zwingen.

Pinning

Das sogenannte Zertifikat-Pinning in den 802.1X-Supplikanten auf den mobilen Endsystemen (z.B. Laptops oder Smartphones) der NutzerInnen stellt hierbei die größte Hürde dar. Beim Zertifikat-Pinning werden automatisch durch das Betriebssystem oder durch WLAN-Konfigurations-Assistenten oder explizit manuell durch den/die EndnutzerIn im 802.1X-Supplikant die zur RADIUS-Server-Authentisierung genutzten CA-Zertifikate und/oder das RADIUS-Serverzertifikat selbst festgeschrieben. Dieser Mechanismus soll die EndnutzerInnen vor schurkischen WLAN-Accesspoints und RADIUS-Servern schützen und verhindern, dass die EndnutzerInnen ihre eduroam-Zugangsdaten einem Angreifer in die Hände spielen.

Eine weitere weit verbreitete Form ist das FQDN- oder Domain-Pinning in den 802.1X-Supplikanten der EndnutzerInnen, wobei der FQDN oder ein Domain-Anteil des FQDNs des RADIUS-Servers hart in der eduroam WLAN-Konfiguration festgeschrieben wird und sich dieser dann auch im CommonName (CN) Attribut des neuen Zertifikats widerspiegeln muss.

Plattformabhängige Unterschiede der Supplikanten

Die plattformabhängigen Unterschiede der einzelnen 802.1X-Supplikanten (Android v4, v5, v6, v7, iOS, MacOS, Windows, Linux) erschweren es zusätzlich, eine für alle Systeme passende Lösung zu finden.

Vorgehen

Die eduroam-Gemeinschaft im DFN erarbeitet im DFN-Forum Mobile-IT Möglichkeiten und diskutiert diese auf der DFNroaming-Mailing-Liste (Listenarchiv). Weitere Informationen gibt es auch in einem konservierten Etherpad.

Diese Vorschläge zum weiteren Vorgehen bei der Migration sind nicht abschließend vollständig.

Welches Vorgehen eine Einrichtung letztlich wählt, um die SSL-Zertifikate der lokalen eduroam-Infrastruktur auf die neue DFN-PKI Generation 2 umzustellen, bleibt der Einrichtung überlassen und ist hoch individuell von den lokalen Gegebenheiten in der Einrichtung und deren Nutzerschaft abhängig. Auf jeden Fall sollte die Umstellung sehr sorgfältig geplant werden, denn die SSL-Zertifikate aus der alten DFN-PKI Generation 1 laufen spätestens Anfang Juli 2019 ab und neue Zertifikate gibt es dann nur noch aus der neuen DFN-PKI Generation 2.

Kommunikation

Da realistischer Weise und auch aus technischen Gründen (z.B. Android <= 6.x) nicht davon auszugehen ist, dass alle 802.1X-Supplikanten der gesamten Endnutzerbasis bis zum eigentlichen Umstellungszeitpunkt mit den CA-Zertifikaten von alter und neuer DFN-PKI-Hierarchie ausgestattet werden können, wird den Einrichtungen empfohlen, rechtzeitig einrichtungsspezifische Anleitungen und Kommunikationsstrategien  für die EndnutzerInnen vorzubereiten und zu veröffentlichen. Falls es zum Umstellungszeitpunkt zu eduroam Verbindungsproblemen kommt, muss das bestehende eduroam WLAN-Profil gelöscht und neu angelegt werden, manuell oder z.B. mit Hilfe der eduroam CAT Installationsprogramme.

(rkm, 26.10.2017, aktualisiert am 01.11.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)

Version 3.6 der Zertifizierungsrichtlinie DFN-PKI Global

Zum 04.09.2017 tritt die Version 3.6 der Zertifizierungsrichtlinie  (CP) der DFN-PKI für das Sicherheitsniveau Global in Kraft. Das Dokument finden Sie unter: https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.6.pdf

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

Die Version 3.6 beinhaltet einige nähere Erläuterungen zu den Prozessen der DFN-PCA, die durch das Mozilla-Root-Programm von allen PKIs angefordert wurden.

Des Weiteren gibt es die folgenden Änderungen:

Klarstellung über die Verwendung von digitalen Signaturen bei Zertifikaterneuerung

In Kapitel 3.3.1 ist geregelt, dass die Authentifizierung eines Zertifikatantrags auch über eine digitale Signatur eines gültigen digitalen Zertifikats möglich ist.

Es wird nun klargestellt, dass auch dieses Verfahren nur zulässig ist, wenn die zugrundeliegende Identifizierung innerhalb des Wiederverwendungszeitraums stattfand.

Unterstützung von RFC 6844 Certification Authority Authorization (CAA)

In Kapitel 4.2.2 wird nun die Unterstützung von CAA beschrieben. Nähere Erläuterungen finden Sie hierzu in dem folgenden Blog-Artikel:

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

Gültigkeitsdauer Serverzertifikate

Das CA/Browserforum hat mit Ballot 193 beschlossen, dass ab März 2018 die Laufzeit von ab dann neu ausgestellten Serverzertifikaten 825 Tage nicht überschreiten darf.

Diese Regelung wurde bereits jetzt mit Wirkung zum 01.03.2018 in das Kapitel 6.3.2 aufgenommen.

Erklärung zum Zertifizierungsbetrieb

Die Erklärung zum Zertifizierungsbetrieb (CPS) der DFN-PKI wurde ebenfalls neu veröffentlicht und trägt nun auch die Version 3.6. Das Dokument ist inhaltlich gegenüber der Vorgängerversion 3.1 unverändert.

Durch die Aktualisierung der Versionsnummer wird nun deutlich gemacht, dass das Dokument jährlich überprüft wird. Das Dokument finden Sie unter: https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CPS_V3.6.pdf

(jbr, 21.08.2017)

Sicherung von eigenen Nutzerzertifikaten aus Mozilla/Firefox

Die Zertifikateverwaltung von Mozilla/Firefox erlaubt die einfache Sicherung (Export) der eigenen Benutzerzertifikate, für die ein privater Schlüssel im Browser vorliegt, im PKCS#12-Format in eine .p12-Datei. Hierbei werden sowohl das eigentliche Nutzerzertifikat, der zugehörige private Schlüssel und ggf. in der Zertifikateverwaltung bekannte CA-Zertifikate der ausstellenden Zertifizierungsstellen bis einschließlich zum Wurzel-CA-Zertifikat gesichert.

PKCS#12-Sicherungsdateien von Teilnehmerservice-Operator-Zertifikaten der DFN-PKI werden im weiteren Verlauf für die Einrichtung der Java RA-Oberfläche benötigt und sind nebenbei auch als Backup der eigenen Benutzerzertifikate in Dateiform ganz nützlich.

Sicherung des eigenen Nutzerzertifikats in eine PKCS#12-Datei

Die Zertifikateverwaltung findet sich im Firefox-Browser unter dem Menüpunkt Bearbeiten->Einstellungen->Erweitert->Zertifikate->Zertifikate anzeigen.

Unter dem Karteireiter „Ihre Zertifikate“ werden die eigenen Nutzerzertifikate aufgelistet, für die auch die jeweiligen privaten Schlüssel im Browser vorhanden sind.

Zum Sichern des eigenen Nutzerzertifikats wird das betreffende Zertifikat markiert und dann mit Hilfe eines Assistenten, der durch einen Klick auf „Sichern …“ gestartet wird, in eine PKCS#12-Datei geschrieben. Hierbei wird vom Assistenten ein Passwort abgefragt, mit dem der private Schlüssel in der PKCS#12-Datei gesichert wird. Dieses Passwort sollte also den üblichen Qualitätsstandards für Passwörter von privaten Schlüsseln genügen und auch nicht vergessen, verloren, weitergegeben oder offen gelegt werden.

Aber Obacht, es gibt dabei zwei kleine aber wichtige Details zu beachten:

Für Nutzerzertifikate der neuen DFN-PKI Generation 2 die Sicherung des Cross-CA-Zertifikats ausschließen [Update]

Zunächst ist festzustellen, dass hierfür bei der Sicherung von Zertifikaten der alten DFN-PKI Generation 1 nichts zu tun ist.

Bei der Sicherung von Zertifikaten der neuen DFN-PKI Generation 2 ist folgendes zu beachten:

Die Existenz des Cross-CA-Zertifikats, das die DFN-PKI Generation 2 mit der DFN-PKI Generation 1 verbindet und damit einen alternativen bis zum 09.07.2019 gültigen Zertifizierungspfad für Zertifikate der neuen DFN-PKI Generation 2 CAs zum Wurzel-CA-Zertifikat der alten DFN-PKI Generation 1 herstellt, kann in einer PKCS#12-Datei zu unerwarteten Effekten führen. Daher sollte nach Möglichkeit das Cross-CA-Zertifikat nicht mit in die PKCS#12-Datei gesichert werden.

Dafür muss das Cross-CA-Zertifikat, sofern dieses im Firefox-Browser überhaupt schon bekannt ist, vor der Sicherung des eigenen Zertifikats aus der Zertifikateverwaltung des Firefox-Browsers gelöscht werden:

Die Detailansicht des eigenen Nutzerzertifikats verrät leider nicht zuverlässig, ob der Firefox-Browser das Cross-CA-Zertifikat kennt und dieses möglicherweise bei der Sicherung mit in die PKCS#12-Datei speichert. Aus der Praxis sind Fälle bekannt, bei denen in der Detailansicht des eigenen Nutzerzertifikats die vollständige CA-Zertifikatkette mit dem Wurzelzertifikat der neuen DFN-PKI Generation 2 „T-TeleSec GlobalRoot Class 2“ endete, wo aber die gespeicherte PKCS#12-Datei letztlich den alternativen Zertifizierungspfad über das Cross-CA-Zertifikat enthielt.

Es wird also in der Zertifikateverwaltung vom Firefox-Browser unter dem Karteireiter „Zertifizierungsstellen“ unterhalb von „Deutsche Telekom AG“ das Zertifikat „T-TeleSec GlobalRoot Class 2“ mit der Seriennummer 11:9C:14:8C:C1:AC:0E:95 ausgestellt am 25.04.2016 gesucht, und falls vorhanden, markiert und durch einen Klick auf „Löschen oder Vertrauen entziehen …“ sowie im weiteren Verlauf mit einem Klick auf „OK“ gelöscht. Aufgepasst: Es gibt auch unterhalb von „T-Systems Enterprise Services GmbH“ ein Zertifikat mit dem Namen „T-TeleSec GlobalRoot Class 2“ ausgestellt am 01.10.2008. Dieses Zertifikat mit der Seriennummer 01 muss bleiben, denn es ist das Wurzel-CA-Zertifikat der neuen DFN-PKI Generation 2.

Vollständige CA-Zertifikatkette vs. unvollständige CA-Zertifikatkette

Ältere Firefox-Versionen haben bei der Sicherung von eigenen Nutzerzertifikaten bisher immer die vollständige CA-Zertifikatkette bis einschließlich des Wurzel-CA-Zertifikats mit in die PKCS#12-Datei geschrieben, sofern die betreffenden CA-Zertifikate in der Zertifikateverwaltung bekannt waren.

Dieses Verhalten hat sich in neueren Firefox-Versionen geändert!

In neueren Firefox-Versionen werden ausgehend vom eigenen Nutzerzertifikat nur die CA-Zertifikate der CA-Zertifikatkette mit in die PKCS#12-Datei gesichert, für die im Browser kein explizit gesetztes Vertrauen eingestellt ist, sowie zusätzlich nur noch das erste CA-Zertifikat für welches im Browser dann wieder explizites Vertrauen gesetzt ist.

Das kann im Einzelfall dazu führen, dass in der gesicherten PKCS#12-Datei eine unvollständige CA-Zertifikatkette vorliegt, d.h. dass ein Zwischen-CA-Zertifikat oder das Wurzel-CA-Zertifikat in der Datei fehlen. Das ist für die spätere Verwendung der PKCS#12-Datei in der Java RA-Oberfläche der DFN-PKI ungünstig, die eben die vollständige CA-Zertifikatkette in der PKCS#12-Datei voraussetzt.

Werden in den Firefox-Browser manuell CA-Zertifikate importiert, z.B. über spezielle Links oder die „Importieren…“-Funktion für Zertifizierungsstellen in der Zertifikateverwaltung, so bietet der entsprechende Import-Assistent an, dem gerade importierten CA-Zertifikat explizite Vertrauenseigenschaften („Website“, „Mail-Benutzer“ und/oder „Software-Hersteller“) zuzuweisen. Das explizite Setzen dieser Eigenschaften kann manchmal nützlich oder nötig sein, allerdings führt das im Falle der bereits öffentlich vertrauten DFN-PKI Global Hierarchie (neue und alte Generation) in neueren Firefox-Versionen dazu, dass bei der Sicherung von eben deren Nutzerzertifikaten keine vollständige CA-Zertifikatkette mehr mit in die PKCS#12-Datei geschrieben wird.

Wird z.B. durch eine Fehlermeldung der Java RA-Oberfläche festgestellt, dass in der konfigurierten PKCS#12-Datei, die durch eine Sicherung aus dem Firefox erstellt worden ist, keine vollständige CA-Zertifikatkette vorhanden ist, so kann das an diesem neuen Verhalten vom Firefox liegen.

Explizit gesetztes Vertrauen zurücknehmen, implizites Vertrauen aktivieren

Abhilfe schafft das Wegnehmen von explizit in die Zwischen-CA-Zertifikate der CA-Zertifikatkette gesetztem Vertrauen im Firefox und die erneute Sicherung des eigenen Nutzerzertifikats in eine PKCS#12-Datei, die dann die vollständige CA-Zertifikatkette enthält. Das nötige Vertrauen wird dann automatisch implizit vom vertrauten Wurzel-CA-Zertifikat in die gesamte CA-Zertifikatkette hinein vererbt:

Hierzu werden in der Zertifikateverwaltung vom Firefox-Browser unter dem Karteireiter „Zertifizierungsstellen“ die Vertrauenseinstellungen der beiden relevanten Zwischen-CA-Zertifikate kontrolliert (CA markieren und dann auf „Vertrauen bearbeiten…“ klicken) und ggf. geändert (alle evtl. gesetzten Häkchen vor „Website“, „Mail-Benutzer“ und „Software-Hersteller“ wegnehmen, mit Klick auf „OK“ speichern).

Für Nutzerzertifikate aus der neuen DFN-PKI Generation 2 sind in der Regel die beiden Zwischen-CA-Zertifikate

  • „DFN-Verein Certification Authority 2“, zu finden unterhalb von „T-Systems Enterprise Services GmbH“, und
  • „DFN-Verein Global Issuing CA“, zu finden unterhalb von „Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.“

relevant.

Sollte das zu Nutzerzertifikat aus der DFN-PKI Generation 2 nicht von der „DFN-Verein Global Issuing CA“ ausgestellt worden sein, so kann in der Zertifikatansicht des Nutzerzertifikats unter dem Karteireiter „Details“ nachgeschaut werden, von welcher Zertifizierungsstelle das Nutzerzertifikat ausgestellt wurde. Zu finden ist das entsprechende Zwischen-CA-Zertifikat dann wiederum unter dem Karteireiter „Zertifizierungsstellen“ unterhalb von „Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.“.

Für Nutzerzertifikate aus der alten DFN-PKI Generation 1 sind das Zwischen-CA-Zertifikat

  • „DFN-Verein PCA Global – G01“ mit der Seriennummer 50:4E:C6:F5:3D:11:B4:64 ausgestellt am 22.07.2014, zu finden unterhalb von „Deutsche Telekom AG“,

sowie das jeweilige Zwischen-CA-Zertifikat der teilnehmenden Einrichtung (zu finden unterhalb von „DFN-Verein“) relevant.

In der Zertifikatansicht des Nutzerzertifikats kann unter dem Karteireiter „Details“ nachgeschaut werden, von welcher Zwischen-CA das Nutzerzertifikat ausgestellt wurde. Zu finden ist das entsprechende Zwischen-CA-Zertifikat dann wiederum unter dem Karteireiter „Zertifizierungsstellen“ unterhalb von „DFN-Verein“.

Nun noch die Sicherung durchführen

Sind die Vertrauenseinstellungen für die Zwischen-CA-Zertifikate der CA-Zertifikatkette kontrolliert und ggf. entsprechend dieser Anleitung angepasst worden, so muss das eigene Nutzerzertifikat wie oben beschrieben erneut in eine PKCS#12-Datei gesichert werden, dieses Mal dann mit der vollständigen CA-Zertifikatkette (und ohne das Cross-CA-Zertifikat).

Oder doch lieber ein bisschen PKCS#12-Akrobatik mit openssl?

Steht das Kommandozeilenwerkzeug openssl zur Verfügung und liegt bereits eine „unpassende” PKCS#12-Datei mit dem gesicherten Nutzerzertifikat vor, so kann auch einfach nach PKCS#12-Akrobatik vorgegangen werden. Das erspart eine Menge Klickarbeit.

(rkm, 25.07.2017, aktualisiert (Info zum Cross-CA-Zertifikat) am 28.09.2017, aktualisiert am 09.02.2018)