Oft gefragte Fragen (Admin-Edition)

Das ist hier beschrieben.

Dies passiert, wenn Ihre Server-IP noch nicht beim DFN hinterlegt ist. Erst dann zeigen die DFN-Server auch ein Zertifikat der DFN-PKI (mit Wurzel bei der Telekom). Kontaktieren Sie einfach den DFN und halten Sie IP des Servers sowie den CN-Eintrag seines Zertifikats bereit.

Hintergrund:

Die Kommunikation der TLD/Backbone-eduroam-Server erfolgt ebenfalls via RADSEC-Protokoll. Der Vertrauens-Anker hierbei ist ein Ast der sogenannten eduPKI. Das ist der Ursprung dieses Zertifikats. Nun bleibt die Frage, warum wir dies als Default tragen und nicht das der DFN PKI: Für die Länder-Domains wie .se, .de, .fr etc. ist das Routing im Backbone sehr einfach und strikt hierarchisch lösbar – alles geht zum jeweiligen NREN. Wohin aber mit .eu? Und warum überhaupt so unflexibel statisch? Als Lösung gibt es die so-genannten NAPRT-Einträge im DNS für eduroam, die besagen, wie der Heimat-eduroam-Server dieses Realms heißt. Damit kann nun aber plötzlich jeder eduroam Backbone-Server die DFN-Server mit berechtigtem Interesse kontaktieren und es muss immer zuerst das eduPKI-Zertifikat gezeigt werden. Und leider sieht TLS keinen Blumenstrauß für eine Zertifikatsauswahl vor, weshalb nur der harte Weg einer händischen Konfiguration der DFN-PKI-sprechenden Server bleibt.

Heimateinrichtungen sind nicht berechtigt, eduroam-Backbone-fähige Zertifikate der eduPKI zu bekommen. Dies ist auch nicht notwendig.

• tld1.eduroam.de: 193.174.75.134, Regulärer Ausdruck für den CN: /^(radius1\.dfn|tld1\.eduroam)\.de$/
• tld2.eduroam.de: 193.174.75.138, Regulärer Ausdruck für den CN: /^(radius2\.dfn|tld2\.eduroam)\.de$/
• Die Zertifikate beider Server wurden signiert durch die neue ODER alte DFN PKI. Momentan (Feb 2018) müssen Teilnehmer der .de eduroam Föderation beide PKIs unterstützen. Die Signatur ist von /C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Certification Authority 2 ODER /C=DE/O=DFN-Verein/OU=Geschaeftsstelle/CN=DFN-Verein-GS-CA - G02 .

Für openssl-basierte Programme (radsecproxy, freeradius, …) hat sich unten stehende Aufteilung sowohl im PEAP/TTLS, als auch radsec-Fall bewährt. Die Zertifikate / Schlüssel müssen im .pem-Format vorliegen. Es ist problemlos möglich, den Inhalt verschiedener .pem-Dateien mittels Text-Editor hintereinander zu kopieren. Möglichkeiten der Konvertierung aus anderen Formaten finden sich auf https://www.sslshopper.com/article-most-common-openssl-commands.html .

• Server Certificate
  • enthält (in dieser Reihenfolge!)
    • Serverzertifikat
    • Erstes Intermediate (meist /C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Global Issuing CA)
    • Zweites Intermediate (meist /C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Certification Authority 2)
  • Für radsec muss das Server-Zertifikat außerdem die Client-Eigenschaft haben. Das erreicht man in der DFN-PKI zB dadurch, dass beim Antrag bei Typ Radius-Server statts des voreingestellten 'Webserver' ausgewählt wird.
  • Enthält nicht das root-Zertifikat! Das war immer ein Implementierungsfehler auf Clientseite, ist aber im Jahr 2018 auch überall behoben. Sparen Sie Ihren Clients 2 EAP-Round-Trips!.
• Certificate Key
  • enthält den Server-Key
• CA Certificate
  • Nur für radsec zum DFN (und EAP-TLS, nicht PEAP/TTLS) relevant
  • Enthaelt beide(!) Telekom-Zertifikate:
    • /C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust Center/CN=T-TeleSec GlobalRoot Class 2
    • und C=DE, O=Deutsche Telekom AG, OU=T-TeleSec Trust Center, CN=Deutsche Telekom Root CA 2