Schlagwort-Archive: Nutzerzertifikat

Auslaufende Domain-Freischaltungen für Zertifikate rechtzeitig erneuern

Mit der Einführung der Domain-Freischaltungen für Zertifikate per Challenge-E-Mail Ende Mai 2018 kommen seit dem 24. August 2020 nun langsam FIFO-artig die ersten damals freigeschalteten Domains in die Phase, in der der Freischaltungszeitraum (824 Tage) bald ausläuft oder bereits abgelaufen ist. Ist die Freischaltung bereits abgelaufen, so muss diese entweder erneuert werden oder es können keine neuen Zertifikate mehr für die betroffenen Domains beantragt und ausgestellt werden.

Aufgabe für DFN-PKI Teilnehmerservice-MitarbeiterInnen mit TS-Operator-Zertifikat

Um die Domain-Freischaltung für Zertifikate zu erneuern, muss durch die DFN-PKI Teilnehmerservice-MitarbeiterInnen, die im Besitz eines TS-Operator-Zertifikats sind, über die Java RA-Oberfläche in den Bereichen „Konfiguration->Server/E-Mail-Domains“ für die betroffenen rot markierten Domains zunächst eine erneute Challenge-E-Mail versendet werden, auf die die Empfänger der Challenge-E-Mail dann entsprechend reagieren müssen. Alle Domains deren Freischaltung bereits abgelaufen ist oder deren Freischaltung innerhalb der nächsten 30 Tage ausläuft sind in der entsprechenden Übersichtsliste (Server-Domains, E-Mail-Domains) rot markiert.

Ein Doppelklick auf die betroffene Domain und ein Klick auf „Speichern“ im folgenden Fenster lösen den Versand einer frischen Challenge-E-Mail an die im vorherigen Freischaltungsdurchgang ausgewählte E-Mail-Adresse aus.

Falls für eine Domain eine der Standard-Adressen ausgewählt war und zwischenzeitlich kein MX DNS-Record mehr für diese Domain existiert, muss beim Erneuern der Freischaltung eine andere der angebotenen E-Mail-Adressen ausgewählt werden, ebenso falls sich die E-Mail-Adresse des Zonenkontakts aus dem SOA DNS-Record der Domain geändert hat.

Regelmäßige Überprüfung der Domain-Freischaltungen

Im laufenden Betrieb des DFN-PKI Teilnehmerservices in den Einrichtungen vor Ort kommen über die Zeit einzelne neue Domains, für die Zertifikate ausgestellt werden sollen, hinzu, und für andere Domains sollen evtl. keine Zertifikate mehr ausgestellt werden. Bei letzteren muss geprüft werden, ob die Domains aus der Domain-Verwaltung der Java RA-Oberfläche, ggf. nach Sperrung von noch gültigen Zertifikaten, gelöscht werden sollen. Damit sich die Situation der auslaufenden Freischaltungen über die Zeit nicht komplett zerfasert und beispielsweise in jedem Monat einige wenige Freischaltungen ablaufen, kann es gegebenenfalls sinnvoll sein, jährlich oder zweijährlich zu einem bestimmten Termin alle bestehenden Freischaltungen auf einen Schlag zu erneuern. Damit liegen dann die zukünftigen Ablauftermine aller in dem Durchgang erneuerten Domain-Freischaltungen innerhalb eines deutlich kleineren Zeitfensters zusammen und durch die jährliche bzw. zweijährliche Wiederholung werden zwischenzeitliche Neuzugänge auch wieder eingefangen.

(rkm, 25.09.2020)

Ab jetzt: Neue Antragsseiten für Nutzerzertifikate – ohne Verwendung von LocalStorage im Browser

Wie bereits Ende Januar im Beitrag Neue Antragsseiten für Nutzerzertifikate, die Zweite angekündigt, haben wir die Beantragung von Nutzerzertifikaten nun so umgestaltet, dass Offline-Website-Daten (LocalStorage) nicht mehr vorausgesetzt werden. Diese neue Version ist ab sofort in Betrieb. Damit entfällt für neu gestellte Nutzerzertifikatanträge die häufig fehleranfällige Abhängigkeit von LocalStorage.

Diese Umgestaltung hat zur Folge, dass sich der Zertifikatsbeantragungsfluss ändert. Die zuvor im LocalStorage des Browsers gehaltenen Antragsdaten inklusive des privaten Schlüssels müssen nun am Ende des Prozesses als passwortgeschützte Antragsdatei auf dem Gerät der/des Beantragenden abgespeichert werden.

Sobald das Nutzerzertifikat dann ausgestellt ist, kann dieses über die Antragsseiten unter Verwendung der lokal bei der/dem Beantragenden gespeicherten Antragsdatei heruntergeladen und dabei mit dem privaten Schlüssel aus der Antragsdatei verbunden werden. Das Ergebnis ist dann wie bisher eine Zertifikatsdatei mit zugehörigem privaten Schlüssel und passenden CA-Zertifikaten der Zertifizierungskette im PKCS#12-Format mit der Dateiendung „.p12“.

Für ältere Nutzerzertifikatanträge, die noch im LocalStorage des Browsers gespeichert sind, gibt es Kompatibilitätsmechanismen, so dass diese auch weiterhin verwendet werden können.

(Reimer Karlsen-Masur, 11.03.2020)

Neue Antragsseiten für Nutzerzertifikate, die Zweite

Nachdem Anfang September 2019 auf Grund von technischen Änderungen in den Browsern relativ kurzfristig neue Antragsseiten für die Beantragung von Nutzerzertifikaten in Betrieb genommen wurden, steht demnächst eine weitere Neuerung in diesem Bereich an.

Durch den Wegfall der Unterstützung des <KEYGEN>-Tags zur lokalen Erzeugung von privaten Schlüsseln direkt im Browser wurde im September letzten Jahres der Umstieg auf Antragsseiten mit JavaScript WebCrypto-Technologie unter Nutzung von (Offline-)Website-Daten (sog. LocalStorage), welche ein Teil der Browser-Chronik sind, zur Speicherung der Antragsdaten (inkl. privaten Schlüssel) während des andauernden Zertfifizierungsvorgangs vollzogen.

Die Erfahrung zeigt nun, dass der LocalStorage dabei oft nicht langlebig genug ist, da dieser viel zu häufig durch Browser-Einstellungen oder bestimmte Browser-Updates, die die Browser-Chronik (regelmäßig automatisch) löschen, verloren geht und damit auch die Antragsdaten und insbesondere die darin lokal abgelegten privaten Schüssel zu den ausstehenden Zertifikatanträgen. Das führte dann in etlichen Fällen dazu, dass ausgestellte Nutzerzertifikate nicht mehr mit deren zugehörigen privaten Schlüsseln zusammen geführt und zur weiteren Nutzung abgespeichert werden konnten.

Die zukünftige Version des neuen Antragsformulars wird nun im Laufe des Frühjahrs ohne die Verwendung des flüchtigen LocalStorage erscheinen, um diese Schwierigkeiten zu umgehen. Daher wird sich der Beantragungsfluss wieder ändern. Antragsteller von Nutzerzertifikaten müssen in der künftigen Version ihre Antragsdaten (inkl. lokal im Browser erzeugten privaten Schlüssel) als Datei-Download aus dem Browser herunterladen und zwischenspeichern und dann wieder in den Browser herein laden, um schlussendlich das fertige Zertifikat abzuholen und zusammen mit dem privaten Schlüssel als PKCS#12-Datei (.p12) abspeichern zu können.

Aber irgendetwas ist ja immer 🙂

(rkm, 27.01.2020)

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)

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)