===== Warum sehe 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-Bacbbone-fähige Zertifikate der eduPKI zu bekommen. Dies ist auch nicht notwendig.