Schlagwort-Archive: DFN-PKI

Einführung der neuen Generation der DFN-PKI

Die bestehende DFN-PKI wird seit 2007 mit dem Wurzelzertifikat „Deutsche Telekom Root CA 2“ betrieben, das bis zum 9. Juli 2019 gültig ist. In dieser Zertifizierungshierarchie kann es kein Zertifikat, ob für Server oder für Nutzer, mit längerer Gültigkeit geben.

Für den Betrieb über den 9. Juli 2019 hinaus bietet die DFN-PKI ein neues Wurzelzertifikat an: „T-TeleSec GlobalRoot Class 2“ mit einer Gültigkeit, die bis 2033 reicht. Das Zertifikat können Sie auf folgender Übersichtsseite einsehen: https://www.pki.dfn.de/root/globalroot2/

Die Einführung des neuen Wurzelzertifikats geschieht schrittweise; insbesondere kann die bestehende DFN-PKI unverändert weiter genutzt werden. Allerdings verkürzen sich automatisch die Laufzeiten der ausgestellten Nutzer- und Serverzertifikate durch das feste Ablaufdatum des alten Wurzelzertifikats auf den 9. Juli 2019.

Die „T-TeleSec GlobalRoot Class 2“ ist in den aktuellen Versionen aller relevanten Betriebssysteme und Browser vorinstalliert. Leider gibt es mit Android <= 4.4 ein nicht mehr aktuelles, aber noch weit verbreitetes System, welches das neue Wurzelzertifikat nicht unterstützt. Es besteht allerdings für alle Teilnehmer der DFN-PKI die Möglichkeit, weiterhin Zertifikate in der alten Hierarchie unter der „Deutsche Telekom Root CA 2“ auszustellen. Systeme, die zwingend rückwärtskompatibel sein müssen, können also weiterhin mit Zertifikaten aus der alten Hierarchie ausgestattet werden – diese sind dann aber auch immer nur bis 2019 gültig. Zu diesem Zeitpunkt dürfte Android <= 4.4 keine Rolle mehr spielen. Dies muss also ggf. bei der Ausstellung eines neuen Zertifikats berücksichtigt werden.

Zur Nutzung des neuen Wurzelzertifikats werden von der DFN-PCA bis Herbst 2016 für jeden Teilnehmer der DFN-PKI separate, neue Zugänge bereitgestellt. Die Bereitstellung erfolgt automatisch und ohne weitere Anforderung vom Teilnehmer. Die Teilnehmer können dann selbst entscheiden, wann sie die neuen Zugänge mit der neuen Zertifizierungshierarchie nutzen wollen.

Die DFN-PCA informiert jeden Teilnehmer, wenn der neue Zugang bereitsteht.

Zertifizierungshierarchie

Server- und Nutzerzertifikate wurden in der DFN-PKI bisher mit der folgenden beispielhaften Zertifizierungskette ausgestellt:

 

 

 

 

 


Mit dem neuen Wurzelzertifikat wird sich diese Zertifizierungskette ändern. Das Wurzelzertifikat, das in den Webbrowsern und Betriebssystemen verankert ist, ist in Zukunft die „T-Telesec GlobalRoot Class 2“. Darunter gibt es dann die „DFN-Verein Certification Authority 2“.

In der Vergangenheit hatte fast jede Einrichtung in der DFN-PKI ein eigenes Sub-CA-Zertifikat. Dieses Verfahren wird umgestellt: Im Regelfall wird nun ein allgemeines Herausgeber-Zertifikat mit dem Namen „DFN-Verein Global Issuing CA“ verwendet.

Damit wird eine Zertifizierungskette in der DFN-PKI in Zukunft den folgenden Aufbau haben:



Beantragung

Zur Beantragung von Zertifikaten wählen Antragssteller bisher Adressen der Form https://pki.pca.dfn.de/<teilnehmer-ca>/pub an, um dort auf den Antragsseiten ihre Daten einzugeben.

Zur Nutzung der neuen Generation der DFN-PKI müssen in der Einführungsphase neue Adressen der Form https://pki.pca.dfn.de/<teilnehmer-ca>-g2/pub angewählt werden.

Nach der Einführungsphase wird es auf den bisherigen Antragsseiten einen Verweis auf die neuen Adressen geben (Voraussichtlich in der ersten Hälfte von 2017).

Wichtig: Zertifikatnutzer müssen beim Import eines neu ausgestellten Zertifikats darauf achten, die neue Zertifizierungskette in die Anwendungen einzubinden. Die Kette musste zwar bisher auch schon eingebunden werden, möglicherweise sparen sich Nutzer aber fälschlicherweise diesen Schritt, wenn sie schon ein früheres DFN-PKI-Zertifikat besitzen.

Konfiguration der Client-Authentisierung auf Server-Seite

Wird auf Server-Seite eine Authentisierung mittels Client-Zertifikaten eingesetzt, so muss diese Konfiguration um die neue DFN-PKI Hierarchie erweitert werden. Außerdem ist zu beachten, dass Client-Zertifikate mehrerer Einrichtungen unterhalb derselben Zertifizierungsstelle liegen und daher die Prüfungsbedingungen in der Server-Konfiguration entsprechend angepasst werden müssen.

Wichtig: Wird die Konfiguration der Client-Authentisierung auf Server-Seite nicht korrekt angepasst, haben möglicherweise auch unberechtigte Nutzer Zugriff!

Hinweise zur sicheren Konfiguration von Servern für Client-Authentisierung finden Sie im Artikel „SSL-Authentisierung mit Nutzerzertifikaten“ in den DFN-Mitteilungen Nr. 86.

https://www.pki.dfn.de/fileadmin/PKI/Mitteilungen/DFN86_SSL_Authentisierung.pdf

Teilnehmerservice

Wie für die Antragssteller gibt es auch für den Teilnehmerservice neue Zugänge. Die bestehenden Teilnehmerservice-Mitarbeiter-Zertifikate können dabei unverändert sowohl für den alten als auch für den neuen Zugang verwendet werden. In der Java RA-Oberfläche wird der neue Zugang automatisch zur Verfügung gestellt, und erscheint als zusätzlicher Knoten („Häuschen“) im linken Teil der Oberfläche. Im Beispielbild als „HS Musterstadt (Global Issuing CA)“:

 

 

 

 

 

 

 

Bei der Bearbeitung von Zertifizierungs- und Sperrwünschen müssen Teilnehmerservice-Mitarbeiter den richtigen Knoten auswählen. Für Zertifizierungsanträge ist die CA und damit der auszuwählende Knoten auf dem Ausdruck in der Fusszeile vermerkt:

Domain-Verwaltung

Zum Zeitpunkt der Umstellung werden die dann aktuell zur Zertifizierung freigeschalteten Domains in die neue DFN-PKI übertragen. Ab diesem Zeitpunkt müssen die Domains jeweils getrennt in der alten und neuen DFN-PKI über die bekannten Mechanismen der Java RA-Oberfläche verwaltet werden.

Eigenentwicklungen zum Zugriff auf die DFN-PKI

Einige Einrichtungen verwenden für die Verwaltung von Zertifikaten in der DFN-PKI selbst entwickelte Software, die entweder direkt oder über die Java-Bibliothek „soapclient“ über ein SOAP-API mit den DFN-PKI-Servern kommunizieren.

Auch hier kommen die oben beschriebenen Änderungen zum Tragen: Die SOAP-Endpunkte ändern sich für den Zugriff auf die PKI mit dem neuen Wurzelzertifikat. Am API selbst verändert sich nichts.

Eine Software, die sowohl mit der alten und der neuen Zertifizierungshierarchie kompatibel sein soll, muss also für Antragsstellung und RA-Funktionen zwei verschiedene SOAP-Endpunkte bedienen können.

Wichtig: Auch der optionale Parameter „RaID“ muss konfigurierbar gehalten werden und für alte und neue Hierarchie auf unterschiedliche Werte gesetzt werden können.

Die bestehendenen Teilnehmerservice-Zertifikate aus der alten Zertifizierungshierarchie können, wie beim manuellen Zugriff auch, für die neue Hierarchie weiterverwendet werden. Eigenentwicklungen müssen also nicht zwei verschiedene Teilnehmerservice-Zertifikate verwalten können.

Und auch hier gilt: Der Zugang zur alten PKI wird nicht vorzeitig abgeschaltet. Nach der Bereitstellung des neuen Zugangs durch die DFN-PCA kann der Umstiegszeitpunkt von den Teilnehmern selbst gesteuert werden und ist lediglich durch das End-Datum der alten PKI am 9. Juli 2019 bestimmt.

(jbr, 13.07.2016)

Schlüsselgenerierung mit Google Chrome [Update 25.07.]

[Update 25.07.2016:

Mit den letzten Updates von Chrome funktioniert die Schlüsselerzeugung zwar wie unten beschrieben, der anschließende Import des Zertifikats wird aber nicht mehr korrekt durchgeführt. Dadurch kann das Zertifikat nicht verwendet werden.

Ein Update der Software der DFN-PKI, das diesen Hinweis auch direkt in der Antragsseite gibt, ist in Vorbereitung.

Wir müssen Ihnen leider von der Verwendung von Chrome in den aktuellen Versionen zur Beantragung von Nutzerzertifikaten abraten. Microsoft Internet Explorer und Mozilla Firefox funktionieren uneingeschränkt.

]

 

Seit Version 49 funktioniert die Beantragung von Nutzerzertifikaten in der DFN-PKI mit Google Chrome nicht mehr uneingeschränkt, da Google die dafür notwendige Funktionalität (das „<KEYGEN>“-Tag) in den Default-Einstellung von Chrome deaktiviert hat.

Die Ankündigung von Google (Überschrift „Keygen and application/x-x509-user-cert“): https://blog.chromium.org/2016/02/chrome-49-beta-css-custom-properties.html

Auch: https://bugs.chromium.org/p/chromium/issues/detail?id=588182

Zur Zeit kann in Google Chrome die Schlüsselerzeugung individuell freigeschaltet werden, indem der Nutzer auf das Schloss links neben der URL klickt und die Berechtigung für „Schlüsselgenerierung“ umsetzt. Achtung: Diese Einstellung steht ausschließlich auf der Seite „Nutzerzertifikat beantragen – Bestätigen“ zur Verfügung.

google_chrome_keygen

Alternativ kann der Mechanismus auch in chrome://settings/content freigeschaltet werden:

google_chrome_keygen_settings

Bis zu welcher Version diese Eingriffsmöglichkeit des Nutzers noch bestehen wird, ist nicht bekannt.

Es ist geplant, in der DFN-PKI alternative Beantragungsverfahren mit W3C WebCrypto umzusetzen, um wieder eine problemlose Beantragung von Nutzerzertifikaten anbieten zu können.

(jbr, 10.05.2016)

Alternative Import-Möglichkeit für eigene Nutzerzertifikate in Firefox und Internet Explorer

[Update 13.05.2020, Jürgen Brauckmann: Ab Firefox Release 76 steht diese alternative Möglichkeit nicht mehr zur Verfügung, da der Import von Zertifikaten per MIME-Typ entfernt wurde.]

tl;dr Falls der direkte Import des eigenen Nutzerzertifikats über den speziellen Link von den DFN-PKI-Web-Servern in den Zertifikatspeicher des Firefox‘ oder Internet Explorers nicht möglich ist, gibt es für den Import eine weitere Alternative mittels Web-Formular mit lokalem JavaScript bzw. ActiveX, Zertifikatsdatei im PEM-Format und Copy&Paste.

Bei der Beantragung von Nutzerzertifikaten aus der DFN-PKI wird der Browser in der Regel dazu benutzt, sowohl das kryptografische Schlüsselpaar auf dem eigenen Rechner als auch den eigentlichen Zertifikatantrag in den DFN-PKI-Systemen zu erzeugen. Hierbei wird das Schlüsselpaar bestehend aus privatem und öffentlichem Schlüssel durch den Browser auf dem Rechner der Beantragenden erzeugt. Der private Schlüssel verbleibt auf dem Rechner der Beantragenden. Der öffentliche Schlüssel wird zusammen mit den übrigen Antragsdaten auf das DFN-PKI-System hochgeladen, um schließlich das Nutzerzertifikat zu beantragen.

Bevor das Nutzerzertifikat nun im Browser zur Client-Authentisierung genutzt oder aus dem Browser, z. B. für eine weitere Nutzung in einem E-Mail-Programm, heraus exportiert werden kann, müssen auf dem Rechner der Beantragenden der private Schlüssel und das fertig ausgestellte Nutzerzertifikat wieder zusammengeführt werden. Der Weg des Zertifikats zum zugehörigen privaten Schlüssel im Zertifikatspeicher des Browsers ist technisch entweder an den speziellen MIME-Typ application/x-x509-user-cert (Firefox) oder den Einsatz bestimmter ActiveX-Funktionen für das Zertifikat-Enrollment (Internet Explorer) gebunden. Und es kann mitnichten einfach eine vorhandene Datei mit dem Zertifikat in den Browser importiert werden, da hierbei entweder die nötige spezielle MIME-Typ-Information oder die ActiveX-Funktionen fehlen, die im Browser die technischen Mechanismen zur Zusammenführung von privatem Schlüssel und Zertifikat anstoßen.

Stattdessen enthalten die Zertifikatauslieferungs-E-Mails der DFN-PKI für Nutzerzertifikate einen speziellen Link zum direkten Import des Nutzerzertifikats vom DFN-PKI-Web-Server in den Browser bei dem der Web-Server eben diese nötige MIME-Typ-Information im HTTP-Header zusammen mit dem Nutzerzertifikat mitliefert bzw. die ausgelieferte Web-Seite die ActiveX-Funktionen für das Zertifikat-Enrollment nutzt und der Importvorgang dadurch erfolgreich angestoßen und durchgeführt werden kann.

Manchmal ist es allerdings keine Option, das eigene Nutzerzertifikat direkt vom DFN-PKI-Web-Server herunterzuladen. Falls dieses Nutzerzertifikat in Form einer PEM-formatierten Datei vorliegt, kann es in diesen Fällen hilfreich sein, das Zertifikat per Copy&Paste über ein Web-Formular in den Browser zu importieren. Hierbei setzt das Web-Formular die benötigte MIME-Typ-Information bzw. nutzt die ActiveX-Funktionen für das Zertifikat-Enrollment. Diese Alternative funktioniert nur, sofern der zum Nutzerzertifikat zugehörige private Schlüssel schon im Zertifikatspeicher des Browsers vorhanden ist und auch nur mit dem Firefox und dem Internet Explorer. Unter Chrome funktioniert dieses Web-Formular nicht.

Ein Hinweis zur eingesetzten Technik im Web-Formular: Das in das Formularfeld kopierte Zertifikat wird ausschließlich durch den Einsatz von lokalem JavaScript bzw. ActiveX-Funktionen für das Zertifikat-Enrollment auf der Web-Seite in den lokalen Zertifikatspeicher des Browsers importiert. Zertifikate oder gar private Schlüssel werden bei diesem Vorgang nicht an DFN-PKI-Server oder gar Dritte übertragen.

(rkm, 26.11.2015)

Version 3.4 der Zertifizierungsrichtlinie DFN-PKI Global

Anlässlich des diesjährigen Audits der DFN-PKI haben wir wieder einige kleinere Änderungen an der Zertifizierungsrichtlinie (CP) der DFN-PKI im Sicherheitsniveau „Global“ vorgenommen. Die neue Version 3.4 tritt zum 15.10.2015 in Kraft.

Die größte Neuerung: In Zukunft können nach gesonderter Prüfung durch die DFN-PCA für spezielle Anwendungen Wildcard-Zertifikate ausgestellt werden. Anfragen hierzu bitte per E-Mail (dfnpca@dfn-cert.de).

Die weiteren Änderungen, die keine Auswirkung auf den praktischen Einsatz haben, umfassen eine explizite Auflistung der erlaubten Zertifikatnutzungen, ein Hinweis zu CAA-Records, Umstellungen bei den OIDs in Zertifikaten, und eine Klarstellung zu abgelaufenen Zertifikaten.

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

Mit Änderungsmarkierungen: <https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.4_diff.pdf>

(jbr, 01.10.2015)

Java-Sicherheit und die RA-Oberfläche der DFN-PKI

Die RA-Oberfläche der DFN-PKI ist als Java WebStart Anwendung programmiert. Dadurch steht ein plattformübergreifendes Werkzeug zum Bearbeiten und Genehmigen von Zertifikatanträgen zur Verfügung.

Die ebenfalls noch existierende Web-Schnittstelle für den Teilnehmerservice kann inzwischen nicht mehr ohne weitere Add-ons zum Genehmigen von Anträgen verwendet werden, da Mozilla bestimmte JavaScript-Funktionalität (crypto.signText) aus dem Firefox entfernt hat. (Siehe auch Update: Firefox und die Web-RA-Oberfläche der DFN-PKI)

Java ist bekanntermaßen nicht unproblematisch. In den letzten Jahren wurden viele Schwachstellen entdeckt, die ein Aufbrechen des Java Sicherheitsmodells erlauben. Leider werden bei einer Java-Installation automatisch auch immer Browser-Plugins mit installiert. Über diese Browser-Plugins werden immer wieder Systeme beim bloßen Surfen im Web durch die automatische Ausführung von Java-Code mit Schadsoftware infiziert.

Aber: Zum Ausführen der RA-Oberfläche der DFN-PKI wird kein Browser-Plugin benötigt, so dass diese Sicherheitslücke nicht offen stehen muss.

Die RA-Oberfläche wird direkt ohne Plugin über einen Aufruf von https://pki.pca.dfn.de/guira/guira.jnlp durch Java WebStart gestartet. Entweder über die Adresszeile des Browsers mit einer Dateinamen-Verknüpfung .jnlp->Java WebStart, oder über die Kommandozeile:

javaws https://pki.pca.dfn.de/guira/guira.jnlp

Sie können daher, wenn Sie Java allein für die DFN-PKI verwenden, ohne Bedenken die Java-Plugins in Ihren Browsern deaktivieren oder so konfigurieren, dass Sie vor der Ausführung von Java Applets eine Bestätigung geben müssen.

Unter Firefox rufen Sie zur Konfiguration about:addons auf, und setzen das Java Plugin auf „Nachfragen, ob aktiviert werden soll“ oder „Nie aktivieren“.

firefoxaddons

Im Internet Explorer wählen Sie „Add-ons verwalten“ aus dem Extras-Menü:

internetexploreraddons

Unter Google Chrome finden Sie ähnliche Einstellungsmöglichkeiten unter chrome://plugins/.

(jbr, 13.07.2015)

Interne Domainnamen

In einigen Einsatzszenarien ist es nützlich oder sogar erforderlich, Web- oder sonstige Server mit Zertifikaten für interne Domainnamen wie „mail.local“ oder reservierte IP-Adressen wie 192.168.6.1 auszustatten.

Da diese Daten aber nicht eindeutig einem einzigen Server zugeordnet sind, ist die Existenz und die Nutzung solcher Zertifikate unter einer öffentlich vertrauten im Browser vorinstallierten CA wie der DFN-PKI (Sicherheitsniveau „Global“) ein potentielles Sicherheitsrisiko.

Daher schreiben die Baseline Requirements des CA/Browser-Forums schon seit einiger Zeit vor, dass solche Zertifikate nur noch mit einer maximalen Laufzeit bis 30.10.2015 ausgestellt werden.  Am 1.10.2016 müssen alle noch gültigen betroffenen Zertifikate, die eventuell früher mit einer längeren Laufzeit ausgestellt wurden, gesperrt werden.

Lässt sich die Verwendung von internen Domainnamen oder reservierten IP-Adressen in Zertifikaten nicht vermeiden (z.B. durch Umbenennungen), so müssen diese in Zukunft von nicht im Browser vorinstallierten CAs ausgestellt werden.

Eine ausführliche Beschreibung und weitere Hinweise zu dieser Problematik finden Sie in folgendem Dokument: https://www.pki.dfn.de/fileadmin/PKI/anleitungen/Interne-Namen.pdf

Vom CA/Browser-Forum steht ebenfalls ein Dokument mit Hinweisen zur Verfügung: https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf

(jbr, 05.02.2015)

Firefox 33 und die Web-RA-Oberfläche der DFN-PKI

Mit dem Erscheinen der neuesten Version 33 von Mozilla Firefox ergeben sich leider deutliche Veränderungen bei der Benutzung der Web-RA-Oberfläche der DFN-PKI durch Teilnehmerservice Mitarbeiter:

Mit der Web-RA-Oberfläche konnten in der Vergangenheit Zertifikat- und Sperranträge genehmigt werden.

Leider hat Mozilla die zugrunde liegende Funktionalität aus Firefox 33 entfernt, so dass in der Web-RA-Oberfläche keine Zertifikat- und Sperranträge mehr genehmigt werden können. Seamonkey 2.30 ist ebenfalls betroffen.

Wichtig:

  • Die Beantragung von Zertifikaten und Sperrungen durch Nutzer und alle weiteren Features der Web-Oberfläche funktionieren nach wie vor ohne Einschränkungen.
  • Es ist ausschließlich das Genehmigen von Zertifikat- und Sperranträgen in der Web-Oberfläche betroffen.

Sie haben jetzt die folgenden Alternativen, um Zertifikat- und Sperranträge zu genehmigen:

(jbr, 16.10.2014)