Schlagwort-Archive: DFN-PKI neue Generation

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)

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)

Einführung der neuen Generation der DFN-PKI

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

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

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

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

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

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

Zertifizierungshierarchie

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

 

 

 

 

 


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

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

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



Beantragung

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

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

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

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

Konfiguration der Client-Authentisierung auf Server-Seite

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

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

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

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

Teilnehmerservice

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

 

 

 

 

 

 

 

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

Domain-Verwaltung

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

Eigenentwicklungen zum Zugriff auf die DFN-PKI

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

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

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

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

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

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

(jbr, 13.07.2016)