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.

Bitte kontaktieren Sie die DFN eduroam-Admins.

vgl. Basis-Daten.

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

Die beschrieben Zertifikate der beteiligten CAs erhalten sie hier und hier.

So lange sich weder IP-Adresse noch CN im Zertifikat des mit dem DFN sprechenden Servers ändern, brauchen Sie nichts zu beachten und müssen dies auch nirgendwo melden. Beachten Sie, dass nur Zertifikate der alten oder neuen DFN PKI zugelassen sind.

So lange sich weder IP-Adresse noch CN im Zertifikat des mit dem DFN sprechenden Servers ändern, brauchen Sie nichts zu beachten und müssen dies auch nirgendwo melden. In allen anderen Fällen kontaktieren Sie bitte den DFN.

Beachten Sie, dass die DFN eduroam-Server keinerlei DNS-Informationen auswerten; weder eine Vorwärtsauflösung beim IP-Verbindungsaufbau noch eine Rückwärtsauflösung beim Zertifikats-Check.

In der Vergangenheit gab es zu oft Probleme mit nicht auflösenden DNS-Namen, die aus technischen Gründen die Server-Software und damit den eduroam-Dienst in Deutschland als ganzes beeinträchtigt haben.

Ja, definitiv!

• RADSEC-Server von SP müssen einzig ausgehend Verbindungen zu den DFN-Servern TCP-Ziel-Port 2083 aufbauen. Wenn es sich nicht vermeiden lässt, funktioniert es technisch sogar durch ein n:m NAT hindurch.
• RADSEC-Server von IdP müssen zusätzlich eingehende Verbindungen von den DFN-Servern auf TCP-Ziel-Port 2083 erlauben.
• Die IPs der DFN-Server sind auf der allgemeinen Info-Seite dokumentiert.

Die DFN eduroam-Server unterstützen im Moment keine RADSEC-Verbindungen via IPv6. Es ist aber geplant.

Nein.