Schlagwort-Archive: DFN-PKI G2

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)

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)

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)