Archiv des Autors: Reimer Karlsen-Masur

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)

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/#SOA/

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/#MX/

Das anlegen eines neuen DNS-MX-Records für eine Domain benötigt im Normalfall ca. 10 Minuten (im Ausnahmefall maximal die eingestellte Time-To-Live (TTL) Zeit der DNS-Records der Domain), bis dieser über den DNS-Resolver der DFN-PKI auch auf den DFN-PKI-Systemen angekommen und sichtbar ist und damit die Standard-E-Mail-Adressen für die Domain-Freischaltung bei einem (erneuten) Freischaltungsvorgang zur Verfügung stehen.

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.

Wird für eine Domain zum ersten Mal überhaupt eine E-Mail-Adresse beim Domain-Provider angelegt, so wird dabei implizit vom Domain-Hoster auch ein DNS-MX-Record angelegt. Bis dieser über den DNS-Resolver der DFN-PKI auch auf den DFN-PKI-Systemen angekommen und sichtbar ist und damit die Standard-E-Mail-Adressen für die Domain-Freischaltung bei einem (erneuten) Freischaltungsvorgang zur Verfügung stehen, können im Normalfall ca. 10 Minuten (im Ausnahmefall maximal die eingestellte Time-To-Live (TTL) Zeit der DNS-Records der Domain) vergehen.

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. Beenden Sie die ggf. 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 2, erkennbar an der Property namens caName mit dem Wert dfn-ca-global-g2, 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“>Anzeigename – etwa Uni Musterstadt CA G2 o.ä.</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 neu 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. Zusammen ergeben sich also die zwei Abschnitte wie folgt:

    <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“>Anzeigename – etwa Uni Musterstadt CA G2 o.ä.</property>
    <property name=“raType“>PKCS12</property>
    </node>

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

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

(rkm, 13.04.2018, 03.05.2019)

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

Nun noch die Sicherung durchführen

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

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

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

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

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)