| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| de:eduroam:admins:faq [2018/02/19 14:58] – [Welches Zertifikat kommt in welche Datei?] Steffen Klemer | de:eduroam:admins:faq [2018/04/20 12:01] (aktuell) – gelöscht Ralf Paffrath |
|---|
| ====== Oft gefragte Fragen (Admin-Edition) ====== | |
| |
| ===== Wie kann meine Einrichtung an eduroam teilnehmen? ===== | |
| |
| Das ist [[de:eduroam:join|hier beschrieben]]. | |
| |
| |
| ===== Warum sehe ich Zertifikatsmeldungen zu eduPKI? ===== | |
| |
| 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). [[https://www.dfn.de/kontakt/|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 [[https://www.edupki.org/|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 [[https://wiki.geant.org/display/H2eduroam/DNS-NAPTR|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. | |
| |
| |
| |
| ===== Wie heißen die DFN radsec Server und was für ein Zertifikat haben sie? ===== | |
| |
| * 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'' . | |
| |
| |
| ===== Welches Zertifikat kommt in welche Datei? ===== | |
| |
| 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 [[https://www.pki.dfn.de/wurzelzertifikate/globalroot2/|hier]] und [[https://www.pki.dfn.de/wurzelzertifikate/globalroot/|hier]]. | |