Schlagwort-Archive: DFN-PKI

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)

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)

Funktionseinschränkungen bei der Web RA-Oberfläche

Seit vielen Jahren gibt es in der DFN-PKI zwei Schnittstellen für den Teilnehmerservice: Die Web RA-Oberfläche unter https://ra.pca.dfn.de/<CA-Kürzel>/ra und die neuere Java RA-Oberfläche unter https://pki.pca.dfn.de/guira/guira.jnlp.

Aktuell ist die Web RA-Oberfläche nur noch im Firefox-Browser voll funktionsfähig, und dieses mit den neueren Firefox-Versionen auch nur mit dem Add-On SigntextJS+ zur Genehmigung von Anträgen. Im Gegensatz zur Java RA-Oberfläche unterstützt die Web RA-Oberfläche weit weniger Funktionen, es fehlen z.B. die Verwaltung von Domainnamen und Teilnehmerservice-Mitarbeitern.

Zur Unterstützung von Certification Authority Authorization Records (https://blog.pki.dfn.de/2017/03/rfc-6844-certification-authority-authorization-caa/) wird das Backend der Java RA-Oberfläche mit entsprechenden Funktionen ausgerüstet.

Leider ist es nicht mehr sinnvoll, den hierfür notwendigen Aufwand auch für die in die Jahre gekommene Web RA-Oberfläche zu leisten. Daher müssen wir in der Web RA-Oberfläche das Genehmigen von Zertifikatanträgen für das Sicherheitsniveau Global voraussichtlich im Juli/August 2017 deaktivieren. Die weiteren Funktionen der Web RA-Oberfläche bleiben vorerst erhalten.

Zertifikatanträge im Sicherheitsniveau Global können also in Zukunft ausschließlich mit der Java RA-Oberfläche genehmigt werden. Hinweise zur Nutzung der Java RA-Oberfläche finden Sie unter https://www.pki.dfn.de/faqpki/faqpki-tsbetrieb/#c16300.

In den anderen Sicherheitsniveaus (Basic, Grid) und bei den internen CAs steht das Genehmigen von Zertifikatanträgen auch in der Web RA-Oberfläche weiter zur Verfügung.

Sperranträge können weiterhin uneingeschränkt in allen Sicherheitsniveaus über die Web- und die Java RA-Oberfläche genehmigt werden.

Für Fragen melden Sie sich bitte bei dfnpca@dfn-cert.de

(jbr, 29.05.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)

SHA-1 Kollisionen und deren Bedeutung für die DFN-PKI

Wissenschaftler vom CWI Amsterdam und von Google haben eine Forschungsarbeit veröffentlicht, in der praktisch vorgeführt wird, wie Kollisionen für den Hashalgorithmus SHA-1 berechnet werden können. Dabei ist es gelungen, zwei PDF-Dokumente so zu konstruieren, dass sie denselben Hashwert besitzen.

http://shattered.io/

Artikel auf Heise: https://www.heise.de/newsticker/meldung/Todesstoss-Forscher-zerschmettern-SHA-1-3633589.html

Artikel Golem: https://www.golem.de/news/kollissionsangriff-hashfunktion-sha-1-gebrochen-1702-126355.html

Die Auswirkungen für die DFN-PKI sind nach unserer Einschätzung gering, denn noch ist niemand in der Lage, sogenannte Pre-Image-Angriffe durchzuführen. Dies bedeutet, dass es noch nicht möglich ist, zu einem bestehenden alten Zertifikat ein zweites, „gefälschtes“ mit identischer Signatur, aber anderen Daten zu berechnen.

Der jetzt veröffentlichte Angriff setzt nach unserem Kenntnisstand voraus, dass beide Datenobjekte, das „Original“ und die „Fälschung“, hochvariable Daten unter Angreiferkontrolle beinhalten. Ein erfolgreicher Angriff wäre damit nur möglich, wenn die DFN-PKI weiterhin Zertifikate oder andere Daten mit SHA-1 signieren würde. Dies ist nicht der Fall, die DFN-PKI ist komplett auf SHA-2 umgestiegen.

Daraus folgt: Der neue Angriff ändert noch nichts an der Sicherheit von bestehenden Zertifikaten der DFN-PKI, selbst wenn sie mit SHA-1 signiert sein sollten.

Es gilt aber natürlich nach wie vor: Die Verwendung von SHA-1-signierten Zertifikaten (sei es als Sub-CA-Zertifikat, als Server- oder als Nutzerzertifikat) sollte sehr zügig beendet werden, da die weitere Entwicklung nicht absehbar ist. Insbesondere sollten Sie darauf achten, dass Sie bei der Inbetriebnahme eines neuen SHA-2-Zertifikats auch die neue SHA-2-Zwischenzertifizierungskette einbinden.

Hinweis: Aktuelle Versionen von z.B. Google Chrome oder Internet Explorer/Edge lehnen SHA-1-signierte Server- oder Sub-CA-Zertifikate ab. Ob Sie Ihren Server korrekt konfiguriert haben, können Sie z.B. mit https://www.ssllabs.com/ssltest/ überprüfen.

Spezialfall Wurzelzertifikat

Die Tatsache, dass die erste Generation der DFN-PKI mit der „Deutsche Telekom Root CA 2“ aufgebaut ist, führt ebenfalls mit dem jetzt vorgestellten Angriff nicht zu Problemen. Dieses Wurzelzertifikat trägt zwar eine SHA-1-Selbstsignatur. Diese hat aber keine Sicherheitsfunktion. Dem Wurzelzertifikat wird vertraut, weil es in der Software (z.B. Betriebssystem, Webbrowser) fest vorinstalliert ist, die Signatur spielt keine Rolle. Siehe hierzu auch den Artikel in unserer FAQ: https://www.pki.dfn.de/faqpki/faq-umstellung-sha-2/#c18430

(jbr, 24.02.2017)

SHA-2-Migration der DFN-PKI abgeschlossen

Die DFN-PKI hat seit 2013 eine Migration des Hash-Algorithmus, mit dem Signaturen unter Zertifikaten, Sperrlisten und OCSP-Antworten erstellt werden, vorgenommen.

Da bei der Migration berücksichtigt werden musste, dass Alt-Anwendungen und -Geräte unter Umständen nicht sofort mit dem neuen Algorithmus SHA-2 umgehen können, konnte der Prozess erst jetzt abgeschlossen werden.

Die Umstellungsdaten in der DFN-PKI:

  • Herbst 2013: Umstellung der ersten CAs auf SHA-2 (Grid, SLCS, DFN-eigene CAs)
  • Februar 2014: Neu signiertes PCA-Zertifikat mit SHA-2
  • Mai-Auguts 2014: Neu-Signatur der Sub-CA-Zertifikate mit SHA-2
  • Bis August 2014: Umstellung der Standard-Profile für Nutzer- und Server-Zertifikate auf SHA-2
  • Mitte 2015: Begrenzung der Laufzeit von SHA-1-Zertifikate für Alt-Geräte auf Dezember 2016
  • Dezember 2015: Abschaltung der Möglichkeit, für Alt-Geräte SHA-1-Zertifikate zu beziehen
  • März 2016: Umstellung der Signatur von OCSP-Antworten auf SHA-2
  • April 2016: Umstellung der Signatur von Zeitstempeln auf SHA-2
  • August 2016: Umstellung der Signatur von Sperrlisten (CRLs) auf SHA-2

Damit wird jetzt für die Erstellung von Signaturen in der DFN-PKI ausschließlich SHA-2 verwendet.

Weitere Informationen zur Umstellung finden Sie unter https://www.pki.dfn.de/faqpki/faq-umstellung-sha-2/

Alle Artikel in diesem Blog zu diesem Thema: https://blog.pki.dfn.de/tag/sha-2/

(jbr, 23.09.2016)

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)