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.

Das hängt davon ab. Zunächst müssen die beiden Anwendungsfälle für Zertifikate im eduroam-Umfeld unterschieden werden:

PEAP/EAP-TTLS/EAP-TLS Diese Zertifikate werden verwendet bei der Client-zu-Heimat-Einrichtung Kommunikation; also den möglichst sicheren Tunnel zwischen WLAN-Endgerät und RADIUS-Server durch den die User-Credentials laufen. Da keine IP-Kommunikation vorliegt, kann der Client das Zertifikat nicht anhand der IP/DNS-Namen überprüfen und ist auf einen fest konfigurierten Check eines der Attribute des Server-Zertifikats angewiesen. Zumeist wird dies der CN oder altName sein. Nicht alle Betriebssystem sehen hier eine Wild-Card oder regulären Ausdruck vor, weshalb die Zertifikate auf ggf. mehreren redundanten Server den selben Eintrag im entsprechenden Feld aufweisen sollten. Einige Betriebssysteme sehen zudem eine Art Zertifikats-Pinning vor, das aus dem Tritt kommt, wenn aufgrund einer Redundanzumschaltung nun vom anderen Server eine anderes Zertifikat gezeigt wird. Ob dies der Fall ist oder nicht, hängt vom Betriebssystem, der Versionsnummer und einigen Konfigurationsparametern ab. Einige Systeme haben in der Vergangenheit auch (mehrfach) ihr Verhalten diesbezüglich geändert. Daher ist die Empfehlung bei mehreren RADIUS-Server, für die PEAP/TTLS/TLS-Verbindung die selben Zertifikate auf allen Servern einzusetzen.

RADSEC Diese Zertifikate werden verwendet bei der Einrichtung-zu-DFN Server-Kommunikation im Backbone. Da im Server-Umfeld davon ausgegangen werden kann, dass die Zertifikats-Checks korrekt implementiert sind, ist der Tausch von Zertifikaten ('Zertifikats-Roll-Over') relativ einfach (vgl. die Frage zuvor). Die geschützten Informationen sind von mittlerer Wichtigkeit (pseudonyme Bewegungsdaten aber keine Passwörter und zumeist keine Identitäten). Es gibt keine zwingenden Gründe für verschiedene Zertifikate pro Server, aber auch wenig operative Gründe, die dagegen sprechen. Verschiedene Zertifikate bieten natürlich etwas mehr Sicherheit, sollte eines 'verlorengehen'.

Man könnte für die EAP-Tunnel und die RADSEC-Verbindung auch die selben Zertifikate einsetzen. Wenn beide Dienste auf dem selben Server laufen, vereinfacht es ggf. auch die operativen Prozesse. Wenn man von Lücken in TLS-Implementierungen absieht, ist das größte potentielle Problem sicher ein gehackter Server. Wer hier nicht sehr gewissenhaft mit den Dateisystemrechten war oder die Einbrecherin schon root-Rechte hat, hat eh beide Zertifikate „verloren“. Im Sinne des KISS-Prinzips ist es in diesem Fall vermutlich zu rechtfertigen, sogar für diese beiden grundverschiedenen Anwendungsfälle das selbe Zertifikat zu verwenden. Die sicherere Variante ist es, 2 verschiedene einzusetzen.

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.