Archiv des Autors: Reimer Karlsen-Masur

Tipps für die Domain-Freischaltung

[1. Update 13.07.2018: Ergänzung Standard-E-Mail-Adressen und Domain-Hoster]
[2. Update 19.07.2018: Geändertes TTL-Verhalten bei Änderungen des Zonen-Kontakts im SOA-Record beschrieben]

Seit einigen Wochen sind die neuen Verfahren zur Domain-Freischaltung in der DFN-PKI in Betrieb (Details siehe Anleitung). Basierend auf den dabei gesammelten Erfahrungen hier einige Tipps für Teilnehmerservice-MitarbeiterInnen der DFN-PKI:

Vor dem 1. August 2018 ist noch was zu tun!

Über 90% aller Domain-Freischaltungen in der DFN-PKI laufen am oder schon vor dem 1.8.2018 ab. Das liegt an der Übergangsphase der Domain-Freischaltungsverfahren durch die Vorgaben aus den Baseline Requirements des CA/Browser-Forum. Sofern es wichtig ist, dass für eine Domain jederzeit SSL-Zertifikate aus der DFN-PKI beantragt und ausgestellt werden können, müssen die vorhandenen Domain-Freischaltungen von den Teilnehmerservice-MitarbeiterInnen mit Hilfe der Java RA-Oberfläche geprüft werden. Wie dabei am geschicktesten vorzugehen ist, wird im Folgenden beschrieben.

Auslaufende Domain-Freischaltungen (wiederholend)

Sehr viele bestehende Domain-Freischaltungen laufen nach der Umstellung der Verfahren zum 1.8.2018 oder früher aus. Danach laufen die Freischaltungen für bereits nach den neuen Verfahren freigeschaltete Domains jeweils nach 825 Tagen aus.

Sofern es wichtig ist, dass jederzeit Zertifikate für bereits einmal freigeschaltete Domains (z.B.  für die Haupt-Domains einer Einrichtung) beantragt und ausgestellt werden können, sollte regelmäßig durch die Teilnehmerservice-MitarbeiterInnen in der Java RA-Oberfläche (Administration->Konfiguration Server-Domains) geprüft werden, ob die Freischaltung von Domains innerhalb der nächsten Wochen ausläuft. Das Tool hilft dabei, indem es die Domains, deren Freischaltung innerhalb der kommenden 30 Tage ausläuft, rot einfärbt. Sofern Sie für mehrere CAs bzw. RA-IDs verantwortlich sind, sollte diese Prüfung in allen CA-Zweigen (Baumhierarchie) und RA-IDs (über die Drop-Down-Liste), die in der Java RA-Oberfläche konfiguriert sind, durchgeführt werden.

Für „Neben-Domains“ ist es vielleicht nicht ganz so wichtig, dass jederzeit Zertifikate beantragt und ausgestellt werden können, so dass deren Freischaltung ggf. auslaufen kann und dann erst wieder bei konkretem Zertifikatsbedarf eine Auffrischung der Domain-Freischaltung erfolgt.

Auswahl der E-Mail-Adresse für den Versand der Challenge-E-Mails

Die zur Zeit von der DFN-PKI unterstützten Verfahren zur Domain-Freischaltung sehen alle den Versand einer Challenge-E-Mail an die E-Mail-Adresse eines vorgegebenen Domain-Kontakts vor. Wichtigste Voraussetzung dafür, dass dieser Prozess funktioniert, ist, dass diese Challenge-E-Mail bei jemandem ankommen kann, der/die damit etwas anfangen kann. Die E-Mail-Adresse muss also mit Bedacht ausgewählt werden. Wie geht man da am geschicktesten vor?

  1. Betroffene Domain in der Java RA-Oberfläche per Doppelklick auswählen (oder neu eintragen) und mal sehen, welche Mail-Adressen für den Versand der Challenge-E-Mail zur Auswahl angeboten werden.
  2. Sofern dabei eine E-Mail-Adresse aufgeführt ist, die direkt bei Ihnen oder bei direkten KollegInnen ankommt, sollten Sie diese E-Mail-Adresse auswählen.
  3. Können Sie keine E-Mail-Adresse identifizieren, von der Sie definitiv wissen, dass die E-Mails an diese Adresse ankommen und von jemandem gelesen werden, der/die weiß, worum es geht, dann sollten Sie sich eine gefühlt bestmögliche E-Mail-Adresse aussuchen und vor dem Start der (Re-)Validierung eine vorbereitende E-Mail an diese Adresse senden. Auf diese Weise finden Sie auch heraus, ob das ausgewählte Postfach überhaupt existiert oder eben doch nicht (Mail-Bounce).

Änderung des Zonen-Kontakts (SOA-Record) im DNS und die TTL

Die Änderung der E-Mail-Adresse im DNS-SOA-Record einer Domain benötigt im Normalfall ca. 10 Minuten (im Ausnahmefall maximal die eingestellte Time-To-Live (TTL) Zeit der DNS-Records der Domain), bis sie über den DNS-Resolver der DFN-PKI auch auf den DFN-PKI-Systemen angekommen und sichtbar ist und damit für die Domain-Freischaltung bei einem (erneuten) Freischaltungsvorgang zur Verfügung steht.

Keine E-Mail-Adresse aus dem Zonen-Kontakt (SOA-Record) im DNS

Es kann sein, dass für eine Domain keine E-Mail-Adresse aus dem Zonen-Kontakt (SOA-Record) zur Auswahl steht. Dann gibt es für diese Domain im DNS keine eigene Zone, also auch keinen SOA-Record, oder die E-Mail-Adresse wurde im SOA-Record fehlerhaft konfiguriert und wird daher nicht zur Auswahl angeboten.

Unten findet sich ein Kommandozeilenaufruf zur Abfrage des SOA. Die Syntax der E-Mail-Adresse ist etwas DNS-like. In diesem Beispiel ist noc.dns.icann.org. die gesuchte E-Mail-Adresse, die dann als noc@dns.icann.org interpretiert wird. Punkte im Lokalteil der Mail-Adresse werden im SOA-Record mittels Backslash geschützt, so wird beispielsweise vorname\.nachname.dns.icann.org. aus dem SOA-Record zu vorname.nachname@dns.icann.org. Der erste nicht geschützte Punkt von links wird zum @-Zeichen der Mail-Adresse.

dig SOA example.org

; <<>> DiG 9.11.0-P1 <<>> SOA example.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48535
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.org. IN SOA

;; ANSWER SECTION:
example.org. 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2018050817 7200 3600 1209600 3600
...

Google stellt ein Web-basiertes DNS-Werkzeug zur Abfrage des SOA-Records zur Verfügung https://toolbox.googleapps.com/apps/dig/

Keine konstruierten Standard-E-Mail-Adressen

Es kann sein, dass für eine Domain keine konstruierten Standard-E-Mail-Adressen der Form (webmaster|hostmaster|postmaster|administrator|admin)@DOMAIN zur Auswahl stehen. Dann ist für diese Domain im DNS kein Mail-Server (MX-Record) eingetragen.

Unten findet sich ein Kommandozeilenaufruf zur Abfrage der Mail-Server (MX-Records) aus dem DNS.

> dig MX example.org

; <<>> DiG 9.11.0-P1 <<>> SOA example.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48535
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.org. IN MX

;; ANSWER SECTION:
example.org. 86400 IN MX 50 mail1.example.org.
example.org. 86400 IN MX 50 mail2.example.org.
...

Google stellt ein Web-basiertes DNS-Werkzeug zur Abfrage der MX-Records zur Verfügung https://toolbox.googleapps.com/apps/dig/

Standard-E-Mail-Adressen und Domain-Hosting

Prüfen Sie für betroffene Domains, ob das Domain-Paket bei Ihrem Domain-Provider die Möglichkeit einer simplen E-Mail-Weiterleitung einer Standard-E-Mail-Adresse wie etwa webmaster@DOMAIN über die Domain-Konfiguration an eine beliebige von Ihnen festgelegte E-Mail-Adresse in Ihrer eigenen Einrichtung (bevorzugt die Funktions-E-Mail-Adresse des eigenen PKI-Teams vor Ort) erlaubt.

Für die Domain-Validierung nutzbare Standard-E-Mail-Adressen, die für solch eine E-Mail-Weiterleitung konfiguriert werden können,  sind (webmaster|hostmaster|postmaster|administrator|admin)@DOMAIN.

E-Mail-Kontakt aus dem WHOIS

Das Inkrafttreten der Datenschutzgrundverordnung hat den Einsatz dieser Validierungsmethode grundsätzlich deutlich erschwert. Ursprünglich als manuelle und damit langsamere und nicht bevorzugte Validierungsmethode vorgesehen, ist sie leider seit dem 25.5.2018 so gut wie gar nicht mehr nutzbar, weil die meisten Domain-Registries keine E-Mail-Adressen von Domain-Inhaber, Admin-C oder Tech-C mehr über ein einfach für Dritte einsehbares WHOIS (Kommandozeile oder Web) herausgeben.

Falls Sie mittels dieser Methode eine Domain validieren wollen, prüfen Sie bitte vorab selbst, ob im einfach für Dritte einsehbaren WHOIS (Kommandozeile oder Web-WHOIS) des Registrars bzw. der entsprechenden TLD-Domain-Verwaltung E-Mail-Adressen von Domain-Inhaber, Admin-C oder Tech-C sichtbar sind. Nach unserer Erfahrung kann das für bestimmte .eu und .de Domains und ggf. mit einen sehr umständlichen Prozess im Einzelfall noch funktionieren.

Prüfen Sie bitte auf jeden Fall zunächst, ob die Domain nicht doch für eines der anderen Verfahren fit gemacht werden kann.

(rkm, 25.06.2018)

RA-Zugang zur alten DFN-PKI Generation bei Neueinrichtung mit TS-Operator-Zertifikat aus der neuen DFN-PKI Generation 2

Wo ist mein bestehender RA-Zugang zur alten DFN-PKI Generation 1 in der Java RA-Oberfläche geblieben?

Nach einer kompletten Neuinstallation Ihres Betriebssystems oder der Neukonfiguration der Java RA-Oberfläche (z.B. unter einem anderen Nutzerkonto) mit einem TS-Operator-Zertifikat der neuen DFN-PKI Generation 2 steht der RA-Zugang zur alten DFN-PKI Generation 1 zunächst nicht mehr in der Java RA-Oberfläche zur Verfügung.

Um auch diesen RA-Zugang zur alten DFN-PKI Generation 1 in der Java RA-Oberfläche wieder herzustellen, ist etwas Handarbeit nötig: Die Konfigurationsdatei der Java RA-Oberfläche muss manuell von Ihnen angepasst werden:

  1. Ggf. beenden Sie die noch laufende Java RA-Oberfläche.
  2. Suchen Sie unterhalb Ihres Home-Verzeichnisses nach der Datei configuration.xml im Verzeichnis .dfn-pki.
  3. Machen Sie ggf. eine Sicherheitskopie dieser Datei.
  4. Öffnen Sie die Datei configuration.xml in einem ASCII-Text-Editor.
  5. Suchen Sie darin den aktuellen Abschnitt für den RA-Zugang zur neuen DFN-PKI Generation, z.B.

    <node type=“de.dfncert.guira.pki.DFNPKICATreeNode“>
    <property name=“caName“>dfn-ca-global-g2</property>
    <property name=“raAlias“>Alias-Name des TS-Operator-Zertifikats</property>
    <property name=“raSource“>/Pfad/zum/TS-Operator-Zertifikat-G2.p12</property>
    <property name=“displayName“>Uni Musterstadt CA G2</property>
    <property name=“raType“>PKCS12</property>
    </node>

  6. Kopieren Sie diesen Abschnitt einschließlich der den Abschnitt einfassenden <node type=…> und </node> Tags und fügen Sie ihn gleich dahinter nochmals ein.
  7. Im eingefügten Abschnitt ändern Sie jetzt die Properties für caName und displayName wie folgt ab:
    1. Als neuen CA-Namen setzen Sie den bekannten CA-Namen aus der alten DFN-PKI Generation 1. Diesen können Sie z.B. aus den alten Web-URLs zur Zertifikatsbeantragung in der alten DFN-PKI Generation 1 ableiten. Für eine beispielhafte Web-URL der Form https://pki.pca.dfn.de/uni-musterstadt-ca/cgi-bin/pub/… aus der alten DFN-PKI Generation 1 ist uni-musterstadt-ca der gesuchte CA-Name für diesen neuen Konfigurationsabschnitt.
    2. Ändern Sie auch den Display-Namen auf z.B. Uni Musterstadt CA G1 ab, so dass Sie diesen neuen Eintrag im Anzeigebaum der Java RA-Oberfläche wiedererkennen können.
    3. Der neue Abschnitt für den RA-Zugang zur alten DFN-PKI Generation 1 sieht dann nach unserem Beispiel wie folgt aus:

      <node type=“de.dfncert.guira.pki.DFNPKICATreeNode“>
      <property name=“caName“>uni-musterstadt-ca</property>
      <property name=“raAlias“>Alias-Name des TS-Operator-Zertifikats</property>
      <property name=“raSource“>/Pfad/zum/TS-Operator-Zertifikat-G2.p12</property>
      <property name=“displayName“>Uni Musterstadt CA G1</property>
      <property name=“raType“>PKCS12</property>
      </node>

      Die anderen Properties wurden hierbei unverändert übernommen.

  8. Speichern Sie die Datei ab.
  9. Starten Sie die Java RA-Oberfläche.

(rkm, 13.04.2018)

PKCS#12-Akrobatik

Manchmal enthalten aus Anwendungen oder Appliances exportierte PKCS#12-Dateien (Dateiendung .p12 oder .pfx) leider doch nicht die gewünschten CA-Zertifikate der CA-Zertifikatskette oder sogar gar keine CA-Zertifikate, siehe auch Sicherung von eigenen Nutzerzertifikaten aus Mozilla/Firefox. Dann kann man hingehen und versuchen, die Anwendung oder Appliance zu überzeugen, doch das Gewünschte zu exportieren, oder man nimmt gleich das Kommandozeilenwerkzeug openssl her und formt sich die vorliegende unpassende PKCS#12-Datei selbst um.

Um etwa die CA-Zertifikatskette eines in einer PKCS#12-Datei vorliegenden Client-Zertifikats der DFN-Verein Global Issuing CA aus der neuen Generation der DFN-PKI auszutauschen, genügt folgende Akrobatik:

1. Privaten Schlüssel und Client-Zertifikat mittels

openssl pkcs12 -clcerts -in client-cert-with-privkey.p12 -out client-cert-with-privkey.pem

aus der vorliegenden PKCS#12-Datei in eine PEM-Datei exportieren. Hierbei wird das Passwort der PKCS#12-Datei abgefragt und ein neues Passwort auf dem exportierten privaten Schlüssel in der PEM-Datei gesetzt.

2. Vollständige CA-Kette der DFN-Verein Global Issuing CA im PEM-Format herunterladen:

wget https://pki.pca.dfn.de/dfn-ca-global-g2/pub/cacert/chain.txt

3. Neue PKCS#12-Datei mit der gerade heruntergeladenen CA-Zertifikatskette zusammenbauen:

openssl pkcs12 -export -in client-cert-with-privkey.pem -certfile chain.txt -out client-cert-with-privkey-and-chain.p12

Hierbei wird das eben gesetzte Passwort des privaten Schlüssels aus der PEM-Datei abgefragt und ein neues Passwort auf der zu erzeugenden PKCS#12-Datei gesetzt.

4. Abschließende Aufräumarbeiten durchführen, also die zwischenzeitlich erzeugten Dateien mit privatem Schlüssel, d.h. client-cert-with-privkey.pem und ggf. die alte unpassende PKCS#12-Datei client-cert-with-privkey.p12 nachhaltig löschen.

Dieses „Kunststück” kann natürlich für Client-Zertifikate, die in Form einer PKCS#12-Datei vorliegen und von beliebigen Zertifizierungsstellen ausgestellt sind, durchgeführt werden, sofern man die korrekte CA-Zertifikatskette im PEM-Format in einer Datei vorliegen hat.

(rkm, 09.02.2018)

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 (Vortrag auf der Herbstbetriebstagung 2017) 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)

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“.

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.

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)

Alte SHA-1-Serverzertifikate in der Java RA-Oberfläche identifizieren

Da die nächste Phase der SHA-1-Abschaltung durch die Web-Browser ab Anfang 2017 ins Haus steht, ist es an der Zeit, die alten SHA-1-Serverzertifikate endgültig auszutauschen. Ein Blick in die Java RA-Oberfläche kann bei der Identifizierung der betroffenen Serverzertifikate helfen:

  1. Öffnen Sie in der Java RA-Oberfläche die Übersichtsliste der gültigen Zertifikate.
  2. Geben Sie in den Suchfilter „SHA“ ein und schränken Sie die Suche über die Häkchen der Suchoptionen auf das Zertifikatsprofil ein. Hierdurch finden Sie alle gültigen SHA-1-Zertifikate die nach der generischen SHA-1-auf-SHA-2-Umstellung im Sommer 2014 über ein spezielles SHA-1-Zertifikatprofil ausgestellt worden sein könnten. (Einige DFN-PKI Nutzer haben sich diese speziellen SHA-1-Zertifikatsprofile für Spezialanwendungen zu einer Zeit konfigurieren lassen, als dieses durch die DFN-PKI Global Policy und die Baseline Requirements des CA/Browser-Forums noch erlaubt war.)
  3. Setzen Sie die Suchoptionen zurück, so dass wieder alle gültigen Zertifikate angezeigt werden.
  4. Sortieren Sie diese nun nach absteigender „Seriennummer“ bzw. „Gültig ab“ Spalte.
  5. Suchen Sie dann das jüngste Zertifikat in der Liste (dieses müsste so zwischen Mai 2014 und Juli 2014 oder früher ausgestellt worden sein), das mit dem SHA-1-Signaturalgorithmus signiert worden ist aber kein spezielles SHA-1-Zertifikatprofil besitzt. Dazu öffnen Sie kurz die Zertifikatdetails eines ausgewählten Kanditatenzertifikats und schauen darin nach einem Eintrag „Signatur Algorithmus RSA (PKCS #1 v1.5) with SHA-1 signature„. Hierdurch finden Sie alle gültigen SHA-1-Zertifikate die vor der generischen SHA-1-auf-SHA-2-Umstellung im Sommer 2014 ausgestellt worden sein könnten.
  6. Alle älteren Zertifikate sind ebenfalls mit dem SHA-1-Signaturalgorithmus signiert worden.

Spätestens jetzt zahlt es sich aus, wenn bereits ausgetauschte und außer Betrieb genommene Zertifikate gesperrt wurden, da diese von vornherein nicht mehr in der Liste der gültigen Zertifikate aufgeführt sind.

Die Java RA-Oberfläche kann nicht erkennen, ist, ob die neuen SHA-2-Serverzertifikate auf den Servern zusammen mit der SHA-2-CA-Zertifikat-Kette installiert und konfiguriert wurden. Im Blog-Artikel „Wie lässt sich feststellen, ob auf einem Server ein SHA-1-Zertifikat installiert ist?“ wird beschrieben, wie dieses überprüft werden kann.

(rkm, 02.12.2016)

Nächste Phase der SHA-1-Abschaltung durch die Web-Browser ab Anfang 2017

Die nächste Phase der SHA-1-Abschaltung durch die Web-Browser steht ab Anfang 2017 ins Haus:

Konkret bedeutet das, dass nach dem jeweiligen Stichtag Microsoft-Systeme bzw. Mozilla/Firefox und Google/Chrome Web-Browser (jeweils aktuelle Software vorausgesetzt) mit einer Zertifikatsfehlermeldung vor TLS/SSL-Verbindungen zu Servern warnen, falls diese immer noch ein altes SHA-1-Server-Zertifikat oder SHA-1-Zwischen-CA-Zertifikat der öffentlich vertrauten DFN-PKI „Global“ präsentieren.

Das mit einer SHA-1-Selbstsignatur versehene Wurzel-CA-Zertifikat „Deutsche Telekom Root CA 2“ der ersten DFN-PKI Global Generation muss auch weiterhin nicht ausgetauscht werden (siehe Erläuterung in der FAQ). Das Wurzel-CA-Zertifikat „T-TeleSec GlobalRoot Class 2“ der neuen DFN-PKI Global Generation trägt bereits eine SHA-256-Selbstsignatur.

Weiteres zum Thema:

(rkm, 02.12.2016)

Ausweis-Scan bei „POSTIDENT durch Postfiliale“

In der DFN-PKI müssen Personen mit bestimmten Funktionsrollen regelmäßig persönlich identifiziert werden.

Die DFN-PKI nutzt seit einigen Jahren zusätzlich zur persönlichen Identifizierung in den DFN-Geschäftsstellen oder bei der DFN-CERT Services GmbH auch das „POSTIDENT Basic“-Verfahren der Deutschen Post AG. Das POSTIDENT-Verfahren ermöglicht eine Identifizierung am Ort und hilft dabei, aufwendige Dienstreisen zu vermeiden.

Ende 2015 hat die Post ihre POSTIDENT-Produkte umbenannt und den Umfang ergänzt. Das altbekannte „POSTIDENT Basic“ ist jetzt im „POSTIDENT durch Postfiliale“ aufgegangen. Zusätzlich zur bewährten Identifizierung scannt die Post nun bei einer Identifizierung in der Filiale auch noch den vorgelegten Ausweis. Dies ist der Post, die mit den POSTIDENT-Verfahren hauptsächlich eine Geldwäsche- und Signaturgesetz-konforme Methode zur Identifizierung von Personen anbietet, nach dem deutschen Geldwäschegesetz erlaubt.

Für die zu identifizierenden Personen und den DFN-Verein gibt es leider keine Möglichkeit mehr, POSTIDENT ohne diesen Ausweis-Scan durchführen zu lassen.

Der Ausweis-Scan liegt der Post nur in digitaler Form vor und wird dem Auftraggeber der Identifizierung erst auf gesonderte Vereinbarung zugänglich gemacht. Der DFN-Verein hat mit der Post keine Vereinbarung hierüber geschlossen und dementsprechend auch keinen Zugriff auf die Ausweis-Scans. Der DFN-Verein erhält wie gehabt ausschließlich das von der/dem Identifizierten in der Filiale unterschriebene Papierformular.

Nach Aussage der Post werden die Daten ausschließlich auf deutschen Servern gespeichert. Die Daten werden im Fall des DFN-Vereins von der Post nach der kürzest möglichen Speicherdauer von zwei Tagen gelöscht, ohne dass dieser Zugriff auf die digitalen Daten erhält.

Leider gibt es keine in der DFN-PKI nutzbare POSTIDENT-Variante in der Postfiliale/-Agentur ohne Ausweis-Scan. Wenn Sie nicht wünschen, dass Ihr Ausweis von der Post eingescannt wird, können wir Sie auf die selbstverständlich immer mögliche persönliche Identifizierung direkt in den Geschäftsstellen des DFN-Vereins (Berlin oder Stuttgart) bzw. in den Räumlichkeiten der DFN-CERT Services GmbH (Hamburg) verweisen. Alternativ bietet sich auch ein Treffen bei einer Veranstaltung mit DFN-Beteiligung (z.B. Betriebstagungen, Konferenzen etc.) an.

[POSTIDENT AGBs]

(rkm, 17.03.2016)

openssl: CSR für ein SSL-Server-Zertifikat mit mehreren Host-Namen erzeugen

Um ein SSL-Server-Zertifikat auf einem Server unter mehreren Host-Namen einsetzen zu können, muss das Zertifikat alle diese Host-Namen als sogenannte alternative Namen (SubjectAlternativeName, SAN) enthalten. Häufig davon betroffen sind Zertifikate für die Haupt-Web-Präsenz einer Einrichtung, die sowohl unter dem Host-Namen mit dem traditionellen www im Host-Namen als auch einfach unter der „blanken“ Haupt-Domain zu erreichen ist, z. B. unter www.example.org und example.org. Entsprechende Zertifikatanträge benötigen daher am besten einen Certificate Signing Request (CSR), der schon alle benötigten alternativen Namen enthält. Wird zum Erzeugen des CSRs das Kommandozeilenwerkzeug openssl genutzt, so sind diese Art von CSRs nur mit einer speziellen openssl-Konfigurationsdatei zu erzeugen.

Unten eine Beispielkonfigurationsdatei für openssl, deren Aufruf mit dem angegebenen Kommando sowohl das Schlüsselmaterial als auch den CSR mit dem angegebenen SubjectDN und den alternativen Namen erzeugt:

#
# Filename: openssl-www.example.org.conf
#
# Sample openssl configuration file to generate a key pair and a PKCS#10 CSR
# with included requested SubjectAlternativeNames (SANs)
#
# Sample openssl commandline command:
#
# openssl req -config ./openssl-www.example.org.conf -new -keyout www.example.org-key.pem -out www.example.org-csr.pem
#
# To remove the passphrase from the private key file use
#
# openssl rsa -in www.example.org-key.pem -out www.example.org-key.pem
#
# This eases automatic startup of the SSL/TLS-server when restarted or
# rebooted. Check for secure file access permissions on the private key file.
# Do not transfer the private key unencrypted over network connections.
#
# If generated directly on a secure filesystem with proper secure file access
# permissions on the server system add option -nodes to omit setting the
# secret key's passphrase protection - this eases automatic startup of the
# SSL/TLS-server when restarted or rebooted.
#
# To set an AES256 passphrase on the private key file use
#
# openssl rsa -aes256 -in www.example.org-key.pem -out www.example.org-key.pem
#

RANDFILE=/dev/urandom

[ req ]
default_bits       = 4096 # key length 4096 bits RSA
distinguished_name = req_distinguished_name
req_extensions     = req_cert_extensions
default_md         = sha256
dirstring_type     = nombstr
prompt             = no

[ req_distinguished_name ]

# requested SubjectDN
#
C   = DE
ST  = Bundesland
L   = Stadt
O   = Einrichtung
1.OU= Abteilung
2.OU= Team
CN  = www.example.org

[req_cert_extensions]

subjectAltName=@subject_alt_name

[ subject_alt_name ]

# requested SubjectAlternativeNames (SANs)
#
# SANs of type DNS
# change those FQDNs to real FQDNs in domains registered to your organisation
#
DNS.1=www.example.org
DNS.2=example.org
DNS.3=www.example.net
DNS.4=example.net

# SANs of type IP
# IP#s are normally not needed in certificates
# change those RFC 1918 IP#s to real IP#s assigned to your organisation
#
#IP.1=10.11.12.13
#IP.2=192.168.2.42

Ein äquivalenter Einzeiler für die Linux-Kommandozeile ist:

#> openssl req -newkey rsa:4096 -sha256 -keyout www.example.org-key.pem -out www.example.org-csr.pem -batch -subj "/C=DE/ST=Bundesland/L=Stadt/O=Einrichtung/OU=Abteilung/OU=Team/CN=www.example.org" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:www.example.org,DNS:example.org,DNS:www.example.net,DNS:example.net"))

Beispielangaben für den SubjectDN, die Host-Namen und ggf. IP-Adressen sind natürlich an die lokalen Gegebenheiten anzupassen.

(rkm, 01.12.2015)

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

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)