Radius Zertifikat, wie, was woher?

[SoniX]

Hallo,

für WPA2 Enterprise WLAN auf dem RT2600AC, nutze ich den RADIUS Server auf meiner DS920+.

Wie und wo bekomme ich da welches Zertifikat installiert, damit die WLAN Clients auch vernünftig verbinden können?
Ich bin da neu in der Sache und habe da auch noch irgendwo logische Probleme mit.

Zertifikate kann man natürlich nicht auf WLAN Netzwerke ausstellen. Diese sind auf den Server ausgestellt.
Ich habe eine Domain und nutze diese auch mit meiner DS920+, das funktioniert mit Wildcardzertifikaten astrein.

Meine Clienten verbinden mit dem Router und dieser mit dem Radius Server auf dem NAS.
Ich kann bei WPA2 Enterprise Clients aber keine Domain angeben womit er sich verbinden soll, nur eine SSID. Auf die gibt es aber kein Zertifikat.
Im Router kann ich auch keine Domain des Radiusserver angeben, nur eine IP Adresse. Auf IP Adressen gibts natürlich auch kein Zertifikat.
Am Radius Server, meinem NAS, habe ich eine Domain mit Zertifikat, aber entweder wird das nicht übertragen oder der Client weiß nicht wie er es gegenprüfen soll.

Also meine Frage: Wie und wo kann ich welches Zertifikat hinterlegen, damit meine Clients auch fehlerfrei verbinden?

Bislang klappt die Verbindung in Windows 10 ausschließlich, wenn ich die Zertifikatsprüfung komplett deaktivieren.
Aber das ist ja nicht Sinn an Zertifikaten, dass man die Prüfung derer komplett deaktiviert.

Ich versuche schon seit Monaten das vernünftig hinzubekommen, aber es will einfach nicht.
Ist WPA2 Enterprise mit Synology überhaupt nutzbar?

Danke und liebe Grüße
SoniX

 

[JudgeDredd]

Ich kann bei WPA2 Enterprise Clients aber keine Domain angeben womit er sich verbinden soll, nur eine SSID. Auf die gibt es aber kein Zertifikat.

von welchen Clients ist hier die Rede ?
Selbstverständlich kann man bei der Anmeldung über 802.1x eine Domain angeben.

Wenn ich z.B. bei meinem Android-OS die WPA2-Enterprise Auth auswähle, gibt es u.a. ein Feld "Domain" zum befüllen.
die muss zum Cert vom RADIUS passen.
Ich habe hier eine eigene PKI, daher muss das root-CA ebensfalls auf dem Client vorhanden sein.

Wenn Dein RADIUS z.B. ein Let’s Encrypt Cert ausliefert, sollte der Client das root-CA ja schon haben. (es wird aber empfohlen mit eigenen CAs zu arbeiten)

 

[SoniX]

Hallo,

also bei Windows 10 kann ich nirgendwo eine Domain hinterlegen. Das sind alle Einstellungsdialoge die Windows hergibt:


Die Verbindung funktioniert ausschließlich dann, wenn ich im letzten Bild "Eigenschaften für geschütztes EAP den ersten Haken rausmache, also die Prüfung damit komplett deaktiviere. Ansonsten meldet Windows schlicht nur "Kann keine Verbindung mit diesem Netzwerk aufbauen.", ohne weitere Hinweise wieso weshalb warum.

 

[JudgeDredd]

Ist der W10 Client denn in einer Domäne ?
Was für ein Zertifikat liefert der RADIUS denn aus (selbst erstellt oder öffnetlich) und wird die root-CA inkl. Chain denn in den EAP Einstellungen angezeigt ?
Gibt es Details in der Ereignisanzeige ?

 

[SoniX]

Nein, keine Domäne.

Was genau ausliefert wird, weiß ich nicht, das bekomme ich nicht zu sehen. Die Diskstation sollte das letsencrypt Zertifikat meiner Domain ausliefern.

Nein, in der Ereignisanzeige ist nichts zu finden. Windows ist da absolut verschlossen.
(Ich hatte Monate gebraucht herauszufinden, dass meine Verbindungsprobleme an der Zertifikatsprüfung lagen; weil es nirgendwo Infos gibt)

 

[JudgeDredd]

Also mit den spärlichen Infos, wird es schwierig was rauszufiden

• Zeig doch bitte mal die Konfig des EAP Moduls des Radius, da müssen ja die Zertifikate drin stehen.
• Erzeuge in der WIN Adminshell mal ein Bericht nach erfolgloser Anmeldung mit:
  

  netsh wlan show wlanreport

Mit diesen beiden Infos sollte man dem Problem zumindest mal auf die Spur kkommen

 

[SoniX]

Ich habe die Verbindung auf meinem Androiden gelöscht und neu eingerichtet. Da wird vor dem ersten Verbinden direkt gefragt was mit dem Zertifikat passieren soll.
Da wähle ich "Bei der ersten Verbindung als vertrauenswürdig einstufen". Dann wird mir das Zertifikat meiner Domain angezeigt, welches ich akzeptiere und damit läuft die Verbindung.

Unter Windows hat sich das Verhalten irgendwann im letzten Jahr geändert.
Zuvor wurde beim ersten Verbindungsaufbau, nach der Authentifizierung gefragt "Ist das Netzwerk WLANSSID das Netzwerk zu welchem sie sich verbinden wollen?" Da gabs kein Zertifikat zu sehen, nur die SSID. Man hat es akzeptiert und es lief.
Aber dann gabs wohl ein Update und seitdem kommt diese Abfrage nicht mehr. Man wird nach Name und Passwort gefragt und dann direkt Fehler "Kann mit diesem Netzwerk nicht verbinden".

Also scheint Radius schon das Zertifikat meiner Domain auszuliefern, aber....
...und da drehe ich mich im Kreis, eine SSID ist halt keine Domain.
Wie soll der Client wissen dass dieses Domainzertifikat für diese WLAN SSID passt, wenn nicht gefragt wird?

Dein Befehl ist ja Wahnsinn. Wenn jemand mit solchen Sachen ankommt, fühle ich mich direkt ganz doof. Was Windows nicht alles kann, wenn man weiß wie. Brauchst du da alles oder reicht dir das meiner Meinung nach wichtige:


Folgend die EAP config des RADIUS Servers:

Spoiler: eap config

    eap {
        default_eap_type = mschapv2
        timer_expire     = 60
        ignore_unknown_eap_types = no
        cisco_accounting_username_bug = no
        max_sessions = ${max_requests}

#        md5 {
#        }

        leap {
        }

        gtc {
            auth_type = PAP
        }

        tls-config tls-common {
            private_key_password = whatever
            private_key_file = ${cadir}/privkey.pem
            certificate_file = ${cadir}/fullchain.pem
            $INCLUDE /usr/local/synoradius/rad_ca_cert
            dh_file = ${certdir}/dh
            random_file = ${certdir}/random
            ca_path = ${cadir}
            $INCLUDE /usr/local/synoradius/rad_tls_min
            $INCLUDE /usr/local/synoradius/rad_tls_max
            $INCLUDE /var/packages/RadiusServer/target/etc/cipher_list
            verify {
            }
        }

        tls {
            tls = tls-common
        }

        ttls {
            tls = tls-common
            default_eap_type = mschapv2
            copy_request_to_tunnel = no
            use_tunneled_reply = no
            virtual_server = "inner-tunnel"
        }

        peap {
            tls = tls-common
            default_eap_type = mschapv2
            copy_request_to_tunnel = no
            use_tunneled_reply = no
            virtual_server = "inner-tunnel"
        }

        mschapv2 {
        }
    }

 

[JudgeDredd]

Also der Teil der EAP-Konfig wirft schon ein paar fragen auf:

tls-config tls-common {
            private_key_password = whatever
            private_key_file = ${cadir}/privkey.pem
            certificate_file = ${cadir}/fullchain.pem
            $INCLUDE /usr/local/synoradius/rad_ca_cert

Die Einträge oberhalb der Include Zeile sind die default des Freeradius Paketes, das kann niemals Dein richtiges Cert sein.
Jetzt wäre es schön zu wissen, was Synology da so included. Schau das mal nach

Meine Windows-Clients sind alles Domänenmitglieder, da kann ich das Verhalten bei Dir leider nicht nachstellen, aber seltsam, das Du keinen Eintrag in der Ereignisanzeige für ID 2086 findest

Dein Android scheint dann aber auch schon etwas betagt zu sein. Ich glaube ab Version 14 kann man keine unbekannten Zertifikate einfach akzeptieren. Es muss zwingen eine gültige CA vorhanden sein

Wie soll der Client wissen dass dieses Domainzertifikat für diese WLAN SSID passt, wenn nicht gefragt wird?

Es wird nicht die SSID zertifiziert !! Das Zertifikat muss zum RADIUS passen und stellt sicher, das Deine Credentials beim richtigen RADIUS landen. Was hast Du denn im Router als RADIUS Server angegeben, IP oder DNS ?

 

[SoniX]

Also der Teil der EAP-Konfig wirft schon ein paar fragen auf:

tls-config tls-common {
            private_key_password = whatever
            private_key_file = ${cadir}/privkey.pem
            certificate_file = ${cadir}/fullchain.pem
            $INCLUDE /usr/local/synoradius/rad_ca_cert

Die Einträge oberhalb der Include Zeile sind die default des Freeradius Paketes, das kann niemals Dein richtiges Cert sein.
Jetzt wäre es schön zu wissen, was Synology da so included. Schau das mal nach

Das ist das was ich in /volume1/@appstore/RadiusServer/etc/raddb/mods-enabled/ gefunden habe.
Ich habe die config files nie angefasst, nur über die Syno GUI eingestellt.
Ist leider nicht so einfach mit Syno, da liegen die Sachen gerne woanders.

Meine Windows-Clients sind alles Domänenmitglieder, da kann ich das Verhalten bei Dir leider nicht nachstellen, aber seltsam, das Du keinen Eintrag in der Ereignisanzeige für ID 2086 findest

Kein Ereignis dazu gefunden :-/

Dein Android scheint dann aber auch schon etwas betagt zu sein. Ich glaube ab Version 14 kann man keine unbekannten Zertifikate einfach akzeptieren. Es muss zwingen eine gültige CA vorhanden sein

Google Pixel mit Android 15.

Es wird nicht die SSID zertifiziert !! Das Zertifikat muss zum RADIUS passen und stellt sicher, das Deine Credentials beim richtigen RADIUS landen. Was hast Du denn im Router als RADIUS Server angegeben, IP oder DNS ?

Eine IP. Man kann da nur eine IP eintragen.
Okay, also vollkommen unabhängig von WLAN und SSID, verbindet der Client mit dem Radius Server und der gibt sein Zertifikat aus. Aber da fehlt dann noch der Zusammenschluß, weil der Client ja nicht weiß welches Zertifikat kommen soll. Da müsste dann eine Abfrage wie bei Android her. Sonst könnte ja jeder mit einem gültigen Zertifikat die Userdaten abgreifen.

 

[JudgeDredd]

also vollkommen unabhängig von WLAN und SSID, verbindet der Client mit dem Radius Server

Wie eine Zertifikatskette funktioniert, ist Dir aber schon bewusst, oder ?
Der RADIUS sagt dem Client eben ich heiße radius.somain.tld und mein Chef SoniX hat mich so genannt.
Jetzt muß der Client natürlich dem Chef SoniX vertrauen und das macht er, indem er sich einen Bekannten sucht der Euch beide kennt (CA Authority), der ihm dann bestätigt, das Du eben Du bist.
Danach weiß der Client, das er sein User/Passwort an Jemand vertrauenswürden sendet.

Ich habe die config files nie angefasst, nur über die Syno GUI eingestellt.
Ist leider nicht so einfach mit Syno, da liegen die Sachen gerne woanders.

Ja, das Problem habe ich hier öfters, vorallem sind die Pakete von Synology immer sehr beschnitten, damit man es eben über klicki-bunti konfigurieren kann.

schau mal was da "included" wird => /usr/local/synoradius/rad_ca_cert
und ggf. weiteren $INCLUDES folgen.

 

[SoniX]

Mit fehlendem zusammenschluss meine ich: Ich gebe ja nicht ein dass sich der Client zu Server xyz verbinden soll sondern ich sage dem Client er soll sich mit WLAN SSID abc verbinden. Der Client hat aber Null Ahnung welcher Server sich hinter WLAN SSID abc melden sollte. Da kann Server xyz mit einem gültigen Zertifikat von xyz stehen oder auch Server jkl mit einem gültigen Zertifikat zu jkl (Zertifikatskette hin oder her). Da ich dem Client vorab nicht sagen kann was kommen soll, muss der natürlich nachfragen ob der Server der sich da gemeldet hat, auch der richtige Server ist. Das macht Windows aber nicht (mehr)... die Verbindung wird einfach abgelehnt.

In früheren Patchlevels wurde wenigstens noch gefragt und wenn man bestätigt hatte, lief es. Aber auch da bekam man nicht das Zertifikat zu sehen, sondern nur die SSID. Das ist nicht sinnvoll, aber immerhin konnte man eine Verbindung aufbauen.

Das ganze ist natürlich ein heikles Thema. Ein falsches WLAN ist schnell aufgespannt, ein Zertifikat schnell eingespielt. Da kommt nun irgendein Windowsclient daher, will sich mit dem falschen WLAN Verbinden, Windows zeigt nicht das Zertifikat an sondern nur die gefälschte SSID und schon schickt der Client die Userdaten an den falschen Server. Und da es sich um Radius handelt, kann man davon ausgehen, dass dies auch die Zugangsdaten für den richtigen Server sind. Das hat MS nun behoben indem es WPA Enterprise komplett kaputt gepatcht hat?!

Das Zertifikat wird schon mitgeschickt. Linux bestätigt dies. Unter Linux wird auch, wie es sich gehört, sinnvolle Info angezeigt und abgefragt ob das nun korrekt so ist. Bei Android wird beim ersten Verbinden der Fingerprint angezeigt und gefragt ob man dem Zertifikat vertrauen möchte. Auch da klappt es.

Ich habe das inzwischen mit mehreren, auch frisch installierten, Rechnern nachgestellt. Das Problem existiert übergreifend.

 

[JudgeDredd]

Also das Dir der "Zusammenschluss" fehlt, kann ich bestätigen
Es ist doch eigentlich ganz einfach, der RADIUS "sagt", ich heiße z.B. wlan.domain.tld und schickt zur Überprüfung sein Zertifikat. Dieses Zertifikat musst Du eben überprüfen. Bisher ging das eben indem Du einfach den Fingerprint bestätigen konntest, was natürlich völlig unsicher ist, da kein Mensch wirklich bestätigen kann, ob das der auch der richtige ist.
Um wasserdicht zu prüfen ob es der richtige Fingerprint ist, nimmt man eben ein Zertifikat (RootCA), welches auf dem Client vorhanden sein muss.
Mit der SSID hat das rein gar nichts zu tun. Du hast ja in Deinem Router konfiguriert, bei welcher SSID er den RADIUS fragen soll und bei welcher nicht.
Auf meine letzte Frage gehst Du leider übehaupt nicht ein. Die Kardinalsfrage ist und bleibt vorerst einmal: Welches Zertifikat liefert der RADIUS aus.
Ich bin eigentlich weiterhin der Meinung, das Android diese manuelle Akzeptanz auch ausgebaut hat, aber wenn es bei Dir noch funktioniert und es Dich nicht stört, dann soll es so sein.

 

[chle]

Mit fehlendem zusammenschluss meine ich: Ich gebe ja nicht ein dass sich der Client zu Server xyz verbinden soll sondern ich sage dem Client er soll sich mit WLAN SSID abc verbinden. Der Client hat aber Null Ahnung welcher Server sich hinter WLAN SSID abc melden sollte.
...
Das Zertifikat wird schon mitgeschickt. Linux bestätigt dies. Unter Linux wird auch, wie es sich gehört, sinnvolle Info angezeigt und abgefragt ob das nun korrekt so ist. Bei Android wird beim ersten Verbinden der Fingerprint angezeigt und gefragt ob man dem Zertifikat vertrauen möchte. Auch da klappt es.

Ich habe das inzwischen mit mehreren, auch frisch installierten, Rechnern nachgestellt. Das Problem existiert übergreifend.

Stell' bei Androiden auf "Systemzertifikate verwenden", dann wird nach einer Domain gefragt:

 

[SoniX]

Uh, das war hilfreich. Ja, tatsächlich. Wenn ich auf Systemzertifikate umstelle, dann kann ich die Domain eingeben und wenn die Domain korrekt ist, dann fragt Android auch nicht nach und akzeptiert das gelieferte Zertifikat.

Kleines seltsames Phänomen: ich muss beim anonymen User auch meinen Usernamen eingeben, wenn ich anonymous drin lasse, klappts nicht. Warum auch immer.

Die Info war auch hilfreich in dem Sinne, weil ich auf folgenden Thread gestossen bin:
https://help.univention.com/t/radius-zertifikate-unifi/13132/8

Darin wird gesagt Windows kann nicht mit Wildcard Zertifikaten umgehen. Tja, ich nutze ein Wildcard Zertifikat. Das erklärt dann einiges. Und wie auch bei mir der Fall, wird bemängelt, dass Windows da keine Infos ausgibt.

Ich werde mir also mal ein eigenes Zertifikat erstellen nur für Windows und weiter testen.

Bezüglich der Zertifikatsfrage: es wird das Zertifikat meiner Domain geliefert. War der Meinung das hätte ich schon erwähnt. Aber halt Wildcard, ich nutze auch fleissig Subdomains.

Edit Nachtrag: seit Vorgestern verweigert mein Notebook komplett die Verbindung, auch wenn ich die Zertifikatsprüfung deaktiviere, was bislang immer funktioniert hatte. Wie es halt so ist, umgestellt hatte ich gerade da, nichts.

 

[JudgeDredd]

es wird das Zertifikat meiner Domain geliefert. War der Meinung das hätte ich schon erwähnt

nein, hattest Du nicht

Kleines seltsames Phänomen: ich muss beim anonymen User auch meinen Usernamen eingeben, wenn ich anonymous drin lasse, klappts nicht. Warum auch immer.

Der anonyme Benutzer ist zur Initialisierung der äußeren TLS Phase. Dieser wird im Klartext übetragen und das sollte man ja nicht machen. Um dem ganzen auf die Spur zu kommen, müsstest du mal in der default-site schauen, was dort unter authorize konfiguriert ist. Wenn Du aber kein Unternehmen mit potentiell bösen Mitarbeitern bist, kannst Du auch den Usernamen drin lassen.

Tja, ich nutze ein Wildcard Zertifikat

Vermutlich nutzt Du auch ein öffentliches Zertifikat einer öffentlichen Domain. Wie ich zuvor schon geschrieben habe, ist das nicht empfohlen, hilft aber dabei, das ganze schneller zum fliegen zu bekommen. Wenn Du Dir eine eigene RootCA erstellst, dann kannst Du mit ein paar Mausklicks im Cert-Manager ruckzuck auch passende erstellen. Interne Wildcard-Zertifikate sind eher unüblich.

 

[chle]

Kleines seltsames Phänomen: ich muss beim anonymen User auch meinen Usernamen eingeben, wenn ich anonymous drin lasse, klappts nicht. Warum auch immer.

Ich habe den anonymen User leer gelassen, funktioniert seit mehreren Jahren.

 

[chle]

Bislang klappt die Verbindung in Windows 10 ausschließlich, wenn ich die Zertifikatsprüfung komplett deaktivieren.
Aber das ist ja nicht Sinn an Zertifikaten, dass man die Prüfung derer komplett deaktiviert.

Das ist eine Frage der Anforderungen. Wenn dir aus örtlichen Gegebenheiten niemand einen falschen Accespoint oder Hotspot unterjubeln kann, dann kannst du drauf verzichten.
Ich habe es mit Windows, nach einer halben Stunde herumprobieren, aufgegeben und die Überprüfung weggelassen. Das ist aber schon ein paar Jahre her.
Auf Android hätte ich sie auch nicht drinnen, wenn nicht mit A13 oder 14 (?) die Deaktiverung der Überprüfung abgeschafft worden wäre. War damals ein ziemliches Gefrickel, weil Let's Encrypt die Verifizierung geändert hat und Android die neue Verifizierung nicht kannte. Ich musste damals sogar auf ein anderes Zertifikat ausweichen.

 

[SoniX]

So, jetzt habe ich (nur) für Radius ein neues Zertifikat erstellt. Kein Wildcardzertifikat. Ein Zertifikat meiner Domain, welches nun nur für Radius genutzt wird.

Android verbindet damit problemlos. Beim anonymen User kann ich weder anonymous drin lassen, noch das Feld leer lassen. Ich muss den Username eintragen, sonst klappts nicht. Aber das sehe ich im Moment eher als Schönheitsfehler.

Was mich im Moment tierisch wurmt ist die Tatsache, dass mir das WLAN vom Windows Notebook vor paar Tagen ausgestiegen ist und mir wieder nur "Kann nicht mit dem Netzwerk verbinden" schreibt obwohl ich da nichts geändert hatte. Es ging und dann nicht mehr. Und es funktioniert auch nicht wenn ich die Zertifikatsprüfung deaktiviere. Und es funktioniert auch nicht mit dem neuen Zertifikat. Im Moment komme ich damit überhaupt nicht ins WLAN, egal was ich einstelle. Auch ein hinterlegen des Zertifikats in den Windows Zertifikatsspeicher hilft nichts. Auch ein Ändern des Windows reg Werts zur Änderung der TLS Version hilft nichts.

Irgendwo kann ich es nicht verstehen. In Firmen sehe ich ein WPA Personal als nicht tragbar an; dort muss eigentlich zwingend WPA Enterprise her. Aber wie handeln die das? Wenn sich die Benutzung derart schwierig verhält und sich laufend mit Windows Updates ändert, kann man das ja nicht ernsthaft nutzen.

 

[JudgeDredd]

In Firmen sehe ich ein WPA Personal als nicht tragbar an; dort muss eigentlich zwingend WPA Enterprise her. Aber wie handeln die das?

Normalerweise sind in einem Unternnehmen alle Devices Mitglied im Domänennetzwerk und Zertifikate werden mittels GPO ausgerollt.
Mal davon ausgehend, das Microsoft tatsächlich etwas bei der EAP Anmeldung geändert hätte (was ich nicht glaube), dann würde in einem Unternehmen so etwas ja schon bei Clients in der Integrationsumgebung auffallen. Updates werden hier über WSUS ausgeliefert, nachdem sie geprüft wurden.

und mir wieder nur "Kann nicht mit dem Netzwerk verbinden" schreibt

Das ist nur die Meldung für den Anwender. Als Admin kann man über die Ereignisanzeige sehr viel mehr sehen. Ich kann Dir aber die korrekte Event-ID lleider nicht auswendig sagen, da musst Du mal googeln.

 

[SoniX]

Ich habe mir einen externen USB WLAN Stick besorgt um einen Hardwarefehler auszuschließen. Ich kann unter Linux auch nichtmehr verbinden.

Vor paar Tagen hatte ich gerade einen Scan am laufen als die Verbindung ausfiel und seitdem geht nichtsmehr. Einen Hardwaredefekt mag ich da nicht ausschließen.

Es nervt mich zwar total bei solch "einfachen" Dingen anzustehen, aber mir gefällt es dass ich dadurch lerne. Neue Windowsbefehle, Ereignisanzeige, Zertifikatshandling, etc.

Insofern ein Danke an alle, egal ob die Lösung gefunden wird oder nicht. Gelernt habe ich jedenfalls was.