WLC-30 (10.94 RU2): HTTPS-Zertifikat auch für PEAP/EAP-RADIUS verwendbar?

[schaefere]

Hallo zusammen,

wir richten aktuell eine neue RADIUS-Umgebung auf einem LANCOM WLC-30 mit LCOS LX 10.94.0217 RU2 ein. Es soll eine SSID mit 802.1X-Authentifizierung bereitgestellt werden, bei der mehrere EAP-Methoden (PEAP-MSCHAPv2 und EAP-TLS) unterstützt werden sollen. Je nach Benutzer bzw. Benutzergruppe erfolgt eine dynamische VLAN-Zuweisung.

Die WLAN-Authentifizierung läuft über den internen EAP-/RADIUS-Server des WLC und funktioniert grundsätzlich problemlos. Die Clients (iOS, Android und Windows) können sich erfolgreich per PEAP-MSCHAPv2 anmelden.

Für das Webinterface nutzen wir bereits ein öffentlich vertrauenswürdiges Let's-Encrypt-Zertifikat, das per ACME automatisch erneuert wird. Das funktioniert einwandfrei.

Bei der Analyse des EAP-Servers ist uns jedoch aufgefallen, dass der WLC für EAP/PEAP weiterhin ein eigenes Zertifikat mit folgenden Eigenschaften verwendet:

CN=RADIUS SERVER
Issuer=LANCOM CA

Soweit ich es teilweise verstanden habe, waren ältere LCOS-/LCOS-LX-Versionen beim internen EAP-Server fest an die integrierte LANCOM-CA gekoppelt, sodass für PEAP bzw. EAP-TLS kein frei wählbares Serverzertifikat verwendet werden konnte.

Daher meine Frage:

Ist es bei einem WLC-30 mit aktueller LCOS-LX-Version möglich, das vorhandene HTTPS-Zertifikat (z. B. Let's Encrypt per ACME) auch für den internen EAP-/RADIUS-Server zu verwenden?

Oder ist der interne EAP-Server weiterhin fest an die LANCOM-CA bzw. das automatisch erzeugte „RADIUS SERVER“-Zertifikat gebunden?

Unser Ziel ist es, die Zertifikatswarnungen auf privaten Endgeräten zu vermeiden, sodass diese dem RADIUS-Server ohne zusätzliche Installation einer CA vertrauen können. Ein MDM steht in diesem Umfeld nicht zur Verfügung.

Vielen Dank für eure Erfahrungen und Hinweise.

Viele Grüße
E.S.

[rotwang]

Eine "feste Kopplung" an die interne LANCOM-CA gibt es eigentlich nicht. Es ist nur so, dass der SCEP-Client im Default ein Zertifikat für den RADIUS/1X-Server von der LANCOM-CA holt. Das kann man aber abschalten. Wenn ich es richtig im Kopf habe, ist die Tabelle unter "Zertifikate->SCEP-Client->Zertifikatstabelle". Dort den Eintrag mit EAP/TLS als Verwendung entfernen. Danach kann man ein eigenes Zertifikat hochladen, das dann auch nicht mehr vom SCEP-Client überschrieben wird.

Das vom dem im LCOS eingebauten Let's-Encrypt-Client geholte Zertifikat kann man nicht für den RADIUS-Server mit verwenden. Der LE-Client legt es fest an der Stelle ab, von der der HTTPS-Server im LCOS sich es abholt. Der RADIUS-Server greift für sein Zertifikat auf eine andere Datei zu, und man kann ihn auch nicht umkonfigurieren, dass er stattdessen auf das HTTPS-Zertifikat zugreift. Umkopieren geht auch nicht, weil das LCOS das Herunterladen von Dateien mit Schlüsselmaterial verhindert. Zu einem Zertifikat gehört ja auch immer der passende private Schlüssel, bzw. beides zusammen in einem PKCS#12-Container.

Ob Clients für 1X überhaupt ein von Let's Encrypt ausgestelltes Zertifikat akzeptieren würden, habe ich keine Erfahrung. Letzten Endes ist das RADIUS-Server-Zertifikat ja auch Teil der gegenseitigen Authentisierung bei 802.1X. Will heißen, mit einem von einer für 802.1X akzeptierten CA ausgestelltem Zertifikat "beweist" der RADIUS-Server gegenüber dem Client, dass die Verbindung zur "richtigen Infrastruktur" besteht. Würde ein 1X-Client beliebige von Let's Encrypt ausgestellte Zertifikate einfach ohne Rückfrage akzeptieren, dann könnte ein Angreifer sich ja auch ein solches besorgen und APs aufstellen, die die gleiche SSID ausstrahlen. Deswegen ist es bei 1X immer noch gängig, eine eigene CA hochzuziehen. Bei PEAP beschränkt sich das ja auf das CA- und das RADIUS-Server-Zertifikat. Letzeres muss man den Clients bekannt machen, entweder indem man es in deren Zertifikatsspeicher kopiert oder per "Trust on first use", falls die Clients so etwas erlauben.

[schaefere]

Vielen Dank für die Info.

Wenn ich das richtig verstehe, wäre die Verwendung eines eigenen Zertifikats für den EAP-/RADIUS-Server grundsätzlich möglich. Bedeutet das in der Praxis, dass die Clients trotzdem weiterhin Zertifikatswarnungen anzeigen können, oder lässt sich das damit vermeiden?

Was mich dabei besonders interessiert, ist die praktische Umsetzung in einem BYOD-Umfeld:

Unser Ziel ist es, private Geräte (iOS, Android und Windows) per PEAP-MSCHAPv2 anzumelden. Die eigentliche Authentifizierung erfolgt über Benutzername und Passwort. Oder gibt es heute andere, empfehlenswertere Lösungsansätze für solche Szenarien?

Wie würde man ein solches Setup heutzutage „sauber“ umsetzen, ohne dass Benutzer Zertifikatswarnungen erhalten oder zunächst eine eigene CA auf ihren Geräten installieren müssen – also ohne MDM oder eine andere Form der zentralen Geräteverwaltung?

Wäre hier ein öffentlich vertrauenswürdiges Zertifikat (z. B. für radius.example.de) überhaupt ein sinnvoller Ansatz, oder verlangen die meisten 802.1X-Clients trotzdem eine explizite Zuordnung von CA und Servernamen?

Verstehen iOS, Android und Windows bei PEAP automatisch, dass sie einem öffentlichen Zertifikat für radius.example.de vertrauen sollen, oder muss der erwartete Servername trotzdem explizit im WLAN-Profil hinterlegt werden?

Wie wird das in der Praxis üblicherweise gelöst? Setzt man typischerweise auf Onboarding-Portale bzw. Provisioning-Profile, eine eigene CA oder gibt es mittlerweile einen etablierten Weg, PEAP-MSCHAPv2 mit möglichst wenig Benutzerinteraktion bereitzustellen?

Vielen Dank für eure Erfahrungen und Empfehlungen.