mcjoey
Goto Top

EAP-PEAP über Radius: cert "wird nicht vertraut"

Hallo!

Ich habe ein Setup mit pfSense, Cisco WLC 2504, mehrere APs 3702I, freeRadius und acmeCertificates (beides unter pfSense). Ich nutze EAP-PEAP mit MSCHAPv2 und LetsEncrypt als CA. Aktuell läuft fast alles. Allerdings: Verbinde ich mich mit meinem iPhone 11 ins WLAN, kommt nach der Abfrage von Benutzername und Kennwort eine Anzeige, dass dem Zertifikat nicht vertraut wird. Ich kann dann auf "vertrauen" klicken und alles funktioniert. (Beim Laptop kommt diese Meldung jedoch nicht!)

Ist so eine Meldung bei Mobiles und EAP üblich, d.h. muss man immer beim ersten Verbindungsaufbau das Zertifikat "bestätigen", oder hab ich erwartungsgemäß noch einen Fehler im Setup?

Das cert ist auf *.lan.example.com (als Beispiel) ausgestellt, radius über radius.lan.example.com erreichbar. Mich irritiert jedoch ziemlich, dass ich in WLC den radius-Server per IP statt Hostname angeben muss. Für "private" IPs erhalte ich natürlich niemals ein trusted cert, und die Clients müssten dieses cert doch eigentlich immer zurückweisen!?

Viele Grüße,
McJoey

Content-Key: 83458668078

Url: https://administrator.de/contentid/83458668078

Printed on: June 20, 2024 at 20:06 o'clock

Member: LordGurke
LordGurke Feb 28, 2024 at 08:17:16 (UTC)
Goto Top
Die Clients sehen die Adresse des RADIUS nie, denen ist es daher egal ob der per IP oder Hostname von deiner Technik angefragt wird.
Was die Clients sehen ist die SSID vom WLAN und ob dieser Name im Zertifikat steht.
Bei Mobilgeräten (ich habe jetzt allerdings nur Android getestet) gibt es sogar eine explizite Einstellung für den zu validierenden Domainnamen, damit das Zertifikat geprüft werden kann.

Wir nutzen für unser WLAN deshalb ein Zertifikat für unsere Hauptdomain und haben das WLAN entsprechend so benannt. Nahezu alle Clients haben aufgehört zu meckern.
Member: Mr-Gustav
Mr-Gustav Feb 28, 2024 updated at 08:38:29 (UTC)
Goto Top
oder wenn es möglich ist ein Zertifikat besorgen was zusätzlich den WLAN Namen beinhaltet

Oder das ganze über ein MDM bereistellen. So kommt auch keine Fehlermeldung face-smile
Member: aqui
aqui Feb 28, 2024 at 09:42:29 (UTC)
Goto Top
Beim Laptop kommt diese Meldung jedoch nicht!
Da hast du die Zert. Prüfung vermutlich abgeschaltet, oder?
Member: Mr-Gustav
Mr-Gustav Feb 28, 2024 at 10:38:55 (UTC)
Goto Top
Also ich meine das ich Zuhause auch keine Meldung bekommen habe bei einem Windows 10 und 11 Client ( frische Installation ) Ich habe einfach Benutzername und Passwort eingegeben und gut war´s.
Prüfung habe ich eigentlich nicht abgeschaltet und das Deployment von Client Cert. erfolgt auch nicht da ich nur Benutzername und Password mache.
Bei Windows 7 wurde ich hingegen gefragt. Habe gerade noch mal eine alte Firmeninterne Anleitung rausgeholt.

War allerdings auch ein NPS und eine Windows PKI und der Controller ein CT5508 aber das sollte je eigentlich egal sein der Controller kommuniziert ja in diesem Fall erstmal nur mit dem Radius bzw. ja auch mit dem Client aber bei der Anmeldung erstmal nur Radius und der NPS sagt dann ja oder nein und der Controller bzw. wenns nur ein AP handelt dann entsprechend
Member: aqui
aqui Feb 28, 2024 at 18:28:58 (UTC)
Goto Top
auch keine Meldung bekommen habe bei einem Windows 10 und 11 Client ( frische Installation )
Weil wohl im .1x Clieht die Zertifikats Prüfung abgeschaltet ist! Siehe oben!
eigentlich nicht abgeschaltet
Eigentlich oder hast du mal wirklich nachgesehen?! 🤔
Member: aqui
aqui Mar 05, 2024 at 16:52:48 (UTC)
Goto Top
Wenn es das denn nun war bitte den Thread dann auch als erledigt markieren!
How can I mark a post as solved?
Member: NordicMike
NordicMike Apr 22, 2024 at 05:43:33 (UTC)
Goto Top
Zitat von @LordGurke:


Was die Clients sehen ist die SSID vom WLAN und ob dieser Name im Zertifikat steht.
Bei Mobilgeräten (ich habe jetzt allerdings nur Android getestet) gibt es sogar eine explizite Einstellung für den zu validierenden Domainnamen, damit das Zertifikat geprüft werden kann.

Wir nutzen für unser WLAN deshalb ein Zertifikat für unsere Hauptdomain und haben das WLAN entsprechend so benannt. Nahezu alle Clients haben aufgehört zu meckern.

Ich habe das mal ausprobiert und die SSID nach meiner Domain benannt. dc.meinedomain.de
Das Zertifikat ist das vom Radius Server radius.dc.meinedomain.de
Das funktioniert schon mal nicht, dem Zertifikat wird trotzdem nicht vertraut.
Member: aqui
aqui Apr 22, 2024, updated at Jun 07, 2024 at 14:59:12 (UTC)
Goto Top
Mit der SSID hat das nichts zu tun.
Wenn du selbstsignierte Zertifikate verwendest musst du natürlich das CA Zertifikat auf das iPhone importieren mit dem das Radius Server Zertifikat erstellt wurde. Diese Zertifikate muss man dann einmal als vertrauenswürdig abnicken.
Ist das Radius Server Zertifikat eins das mit der CA einer offiziellen Zertifizierungsstelle erstellt ist, ist das natürlich nicht erforderlich, da deren CA Zertifikate ja schon per se alle in den "vertrauenswürdigen Stammzertifizierungsstellen" auf dem jeweiligen Endgerät enthalten.
Gleich verhält sich das bei einem Controller. Diese kann man im Setup so einstellen das die Controller als Radius Proxy agieren oder nicht. Bei Letzterem fragen die APs den Radius direkt. Beispiel Ruckus vSZ:
radpro

Bei der Radius Server Zertifikats Prüfung durch den Dot1x Client muss man das Radius Server Zertifikat nicht abnicken. Der Client scheitert dann nur wenn eine Prüfung erzwungen wird aber kein Zertifikat vorhanden ist wie z.B. unter Windows wo diese Prüfung auch abschlatbar ist. (Siehe hier)

Hier einmal im Schnellverfahren eine Anleitung mit Freeradius und OpenSSL mit der es problemlos klappt.

back-to-topExtended Key Usage

⚠️ Windows Clients erfordern zwingend ein EKU Attribut "client- und serverAuth" ohne das die Zertifikats Authentisierung bei Windows Clients sonst scheitert. (Siehe hier)
Es macht also Sinn Zertifikate damit gleich anzulegen um zu allen Endgeräten inkl. Windows kompatibel zu sein.

Man legt dazu für die Erstellung von Server- und Clientzertifikat 2 kleine Textdateien z.B. server-eku.txt und client-eku.txt (nano etc.) vorab an mit folgendem Inhalt:
Serverdatei:
extendedKeyUsage=serverAuth
subjectAltName=DNS:radius.meine.domain 
(Der Eintrag "subjectAltName" ist für eine reine 802.1x Authentisierung nicht unbedingt erforderlich)

Clientdatei:
extendedKeyUsage=clientAuth 


back-to-topCA Zertifikat und Key erstellen


openssl ecparam -name prime256v1 -genkey -noout -out MeineCA.key
openssl req -new -x509 -sha256 -days 3650 -key MeineCA.key -out MeineCA.crt 
(Gültigkeitsdauer hier ggf. anpassen. ⚠️ Hinweise von @colinardo unten beachten!)

👉🏽 Wenn die CA schon vorhanden ist kann dieser Schritt natürlich entfallen und man verwendet in dem Falle das vorhandene CA Zertifikat und Key!


back-to-topRadius Server Key erstellen


openssl ecparam -name prime256v1 -genkey -noout -out Server.key
openssl req -new -sha256 -key Server.key -out Server.csr
openssl x509 -req -in Server.csr -CA MeineCA.crt -CAkey MeineCA.key -CAcreateserial -out Server.crt -days 1825 -sha256 -extfile server-eku.txt 
(Gültigkeitsdauer hier ggf. anpassen. Darf NICHT länger sein als die der obigen CA!!)

Bei Freeradius leert man komplett das Verzeichnis /etc/freeradius/3.0/certs und kopiert dort das Radius Server Zertifikat und Key sowie das CA Zertifikat hinein.

Danach editiert man die EAP Konfig Datei unter /etc/freeradius/3.0/mods-available/eap und passt im Abschnitt tls-config tls-common {...} folgende Parameter an um das Zertifikat einzubinden.
private_key_password = <password_server_key>
private_key_file = <radius_server>.key
certificate_file = <radius_server_zert>.crt
ca_file = <ca_zertifikat>.crt 
Sinnvoll aber nicht zwingend ist es, das eigene CA Zertifikat auf dem Freeradius in die dortigen "vertrauenswürdigen Stammzertifizierungsstellen" zu kopieren.
Ein cp MeineCA.crt /usr/local/share/ca-certificates/ mit einem anschliessenden update-ca-certificates erledigt das.


back-to-topUser Key erstellen


openssl ecparam -name prime256v1 -genkey -noout -out Client1.key
openssl req -new -sha256 -key Client1.key -out Client1.csr
openssl x509 -req -in Client1.csr -CA MeineCA.crt -CAkey MeineCA.key -CAcreateserial -out Client1.crt -days 1825 -sha256 -extfile client-eku.txt

openssl pkcs12 -export -out Client1.p12 -inkey Client1.key -in Client1.crt 
⚠️ Für Apple Endgeräte iPhone / iPad etc. ist das letzte Kommando (5) in
openssl pkcs12 -export -legacy -out Client1.p12 -inkey Client1.key -in Client1.crt
abzuändern! Auch hier unbedingt die Hinweise von @colinardo unten beachten!

Das letzte Kommando packt das User Zertifikat und Key in die zu importierende PKCS12 Datei für das jeweilige Endgerät.
Die User Key Erstellung wiederholt man für jeden User.
Hier sollte der CN, Common Name und die Email Angabe immer individuell, pro User gewählt werden um diese später identifizieren zu können.
⚠️❗️Der User CN (Common Name) darf keine Leerzeichen enthalten!!


back-to-topZertifikats Inhalte anzeigen


openssl x509 -in <zertifikat.crt> -text -noout
Member: colinardo
colinardo Apr 22, 2024 updated at 18:37:27 (UTC)
Goto Top
Servus,
für Apple gilt es zu beachten das Server-Zertifikate nicht länger als 825 Tage gültig sein sollten.
Anforderungen an vertrauenswürdige Zertifikate in iOS 13 und macOS 10.15
Die 1825 Tage oben sind also etwas viel 😉.

Für bereits von vorinstallierte Root-CAs signierten Zertifikaten in iOS gilt sogar eine noch strengere Limitierung auf 398 Tage
About upcoming limits on trusted certificates

Für iPhone: openssl pkcs12 -export -legacy -out Client1.p12 -inkey Client1.key -in Client1.crt

Beim PKCS12 Export würde ich bei selbstsignierten CAs immer die gesamte Chain also inkl. CA/Intermediates mit in den Container packen.
openssl pkcs12 -export -legacy -out Client1.p12 -inkey Client1.key -in Client1.crt -CAfile ca.pem
Das erleichtert insbesondere auch unter Android das Handling weil man die CA gleich mitliefert.

Grüße Uwe
Member: aqui
aqui Apr 22, 2024 at 07:32:25 (UTC)
Goto Top
Danke für diese wichtige Ergänzung! 👍
Member: Dani
Dani Apr 22, 2024 at 17:55:01 (UTC)
Goto Top
Moin @colindaro
Für bereits vorinstallierte Root-CAs in iOS gilt sogar eine noch strengere Limitierung auf 398 Tage
Sicher, dass du dich nicht in der Übersetzung vertan hast? face-wink Weil ich lese das etwas anders...


Gruß,
Dani
Member: colinardo
colinardo Apr 22, 2024 updated at 18:47:09 (UTC)
Goto Top
Zitat von @Dani:

Moin @colindaro
Für bereits vorinstallierte Root-CAs in iOS gilt sogar eine noch strengere Limitierung auf 398 Tage
Sicher, dass du dich nicht in der Übersetzung vertan hast? face-wink Weil ich lese das etwas anders...
Habe ich vielleicht etwas schlecht ausformuliert, das gilt natürlich nicht für die CAs selbst sondern für die von diesen signierten Zertifikaten 😀.

Schönen Abend.
Grüße Uwe
Member: aqui
aqui Apr 22, 2024 at 18:58:36 (UTC)
Goto Top
"We recommend that certificates be issued with a maximum validity of 397 days."
Könnte man aber auch so verstehen das es ggf. eine Empfehlung (recommendation) ist als ein Zwang. 🤔
Member: Dani
Dani Apr 22, 2024 at 19:00:15 (UTC)
Goto Top
Moin,
Könnte man aber auch so verstehen das es eher eine Empfehlung (recommendation) ist als ein Zwang. 🤔
wird nicht gehen. Unsere PKI Team hat sich da vor 2-3 Jahren schon die Zähne ausgebissen. Zumal die Fehlermeldung erst einmal nicht darauf schließen lässt.


Gruß,
Dani
Member: colinardo
colinardo Apr 22, 2024 updated at 19:10:35 (UTC)
Goto Top
Weiter oben steht ja auch
TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days.
... This change will not affect certificates issued from user-added or administrator-added Root CAs.
Member: aqui
aqui May 02, 2024 at 11:51:31 (UTC)
Goto Top
Wenn es das denn nun war bitte nicht vergessen deinen Thread dann auch als erledigt zu markieren!
How can I mark a post as solved?
Member: McJoey
Solution McJoey May 03, 2024 at 15:33:48 (UTC)
Goto Top
Ich habe das alles nochmal ausprobiert, neulich schon mit eigenen CAs und Zertifikaten, jetzt nochmals mit kürzerer Gültigkeit, aber es ändert nix. Ich glaube, das ganze ist "By Design". Am Ende funktioniert es ja, wenn der User das Cert einfach blind akzeptiert. Ich wundere mich nur, das ich der offenbar einzige bin, den das wundert face-wink

Andererseits ist mir tatsächlich noch unklar, wie der ganze Auth-Prozess abläuft, vor allem, was das Zertifikat denn zertifizieren soll, und welche "Partei".

Was mir bisher klar zu sein scheint: Es soll eine TLS-verschlüsselte Verbindung generiert werden, das Zertifikat dient wohl zum Aufbau der Verschlüsselung, nicht jedoch zur Authentifikation der Peers. Denn aufgrund der fehlenden Kenntnis über die jeweiligen Endpunkte kann keine Prüfung stattfinden. Demzufolge müsste es eigentlich sogar egal sein, welchen CN oder welche SANs das Cert enthält.

Vielmehr scheint der Client dieses Cert als Client-Cert zu speichern um darüber die Encryption aufzubauen. Ändere ich das Cert Radius-seitig, funktioniert die Anmeldung trotz korrekter Daten nicht mehr. Ich muss erst das WLAN auf dem Handy "Löschen", um danach das neue Cert lokal zu bestätigen.

Zurzeit nutze ich ein Cert von LetsEncrypt, basierend auf einem DNS-Eintrag für mein LAN. Das kann der Client nicht prüfen. Wenn ich nun alle paar Wochen dieses Cert erneuern muss, stellt sich mir natürlich die Frage nach dem Verhalten der Clients. Werde wohl doch auf ein selbstsigniertes CA umschwenken, und jedem bekannten Client sein eigenes Cert erteilen. Allerdings sollen sich alles Client unmittelbar verbinden können, auch ohne dediziertes Cert.

Mal sehen wie das in Zukunft ablaufen könnte.

Auch wenn das Thema für mich nicht wirklich gelöst ist, ich schließe es mal trotzdem. Ich kann nur keine andere Antwort als Lösung markieren, da die Frage weiterhin offen ist.

Vielen lieben Dank aber für alle Beiträge!!!
Member: aqui
aqui May 03, 2024, updated at Jun 07, 2024 at 15:08:55 (UTC)
Goto Top
Ist nicht nachzuvollziehen was du da schreibst. face-sad
Gerade gestern noch Zertifikate wie HIER beschrieben erstellt und die laufen in Freeradius mit allen möglichen Endgeräten absolut fehlerfrei und unauffällig.

Nur nochmal: Selbsterstellte CA und User Zertifikate muss ein User immer abnicken oder willentlich selbst installieren ("Vertrauenswürdige Stammzertifikate"). Ist ja auch logisch, denn ER muss bestimmen ob er diesen vertrauen will oder nicht. Bei Zertifikaten von registrierten CAs ist das nicht der Fall denn denen wird natürlich schon vom Betriebssystem vertraut.
Ein Zertifikat gilt immer zum Vertrauen eines Endgerätes oder eines Nutzers. Mit Verschlüsselung an sich hat es nur beiläufig zu tun.

Man kann also nur vermuten das du vergessen hast auf den jeweiligen Rechnern und Endgeräten die selbstgenerierte CA in den jeweiligen Store der "vertrauenswürdigen Stammzertifikate" zu kopieren bzw. zu importieren. Ein Umstand der leider oft vergessen wird. face-sad
In der Falle ist der Server nicht in der Lage das Zertifikat zu prüfen und antwortet mit der o.a. Message.
Die gilt natürlich nicht für Zertifikate die von offiziellen CAs erstellt wurden die im Default im o.a. Store schon enthalten sind!

Ggf. hilft etwas Literatur um deinem Verständnis etwas auf die Sprünge zu helfen?!
https://www.heise.de/hintergrund/Was-Sie-ueber-Kryptografie-wissen-muess ...
https://www.heise.de/hintergrund/Grundwissen-Asymmetrische-Kryptografie- ...
https://www.amazon.de/-/en/Alexei-Khlebnikov/dp/1800560346/ref=sr_1_1?cr ...
Member: McJoey
McJoey May 03, 2024 at 16:39:51 (UTC)
Goto Top
Ist nicht nachzuvollziehen was du da schreibst.

tut mir Leid, gerne nochmal dargestellt: Egal, welche Zertifikate ich bisher in der Radius-Konfig "bemüht" habe: Die Clients zeigen diese Zertifikate immer an als "wird nicht vertraut", diese kann ich dann aber bestätigen mit Klick auf "vertrauen". Danach läuft alles. Auch mit selbstsignierten Certs, die NICHT vorher installiert wurden. Was mich auch wundert!

Mich stört das "wird nicht vertraut". Als sicherheitsbewusster User würde ich solch ein Zertifikat normalerweise nicht akzeptieren, aber aktuell muss ich meinen wlan-Nutzern sagen, sie sollen das trotzdem "abnicken". Dann läuft auch alles. Nur wenn das Cert validierbar wäre, dürfte diese Meldung doch gar nicht erst kommen? Oder doch?

Danke für die links, aber ich arbeite schon seit zwei Jahrzehnten mit Zertifikaten, oft selbstsignierten, public key shiffre, usw.. Ich werfe natürlich mal einen Blick rein, aber was mir eher helfen würde wäre eine gute Doku, wie genau die Radius-Auth abläuft. Da fehlt's mir leider an Wissen, da ich hiermit noch keine Erfahrungen habe.

Ein Zertifikat gilt immer zum Vertrauen eines Endgerätes oder eines Nutzers. Mit Verschlüsselung an sich hat es nichts zu tun.

Genau die liegt eines meiner "Probleme". Natürlich ist der primäre Zweck eines Certs die Authentifizierung, also Überprüfung, ob mein Gegenüber auch der ist, der er angibt, zu sein. Das bestätigt eben die jeweils zertifizierende Stelle. Sie bestätigt die Urheberschaft des im CN oder in den SANs eingetragenen Daten.

Wenn der WLAN-Client aber weder die IP des Radius-Servers kennt, noch dessen Hostnamen, noch die IP und Hostname vom WLC, das den Tunnel aufbaut,. und ich im Radius-Server nur ein Zertifikat angeben kann obwohl ich mehrere WLAN SSIDs verwalte, was soll der Client denn Überprüfen? Er kann doch nur prüfen, ob das Cert von einer vertrauenswürdigen CA signiert wurde (*), er kann damit NICHT den Radius-Server selbst authentifizieren.

*) genau das habe ich mit den Zertifikaten von LetsEncrypt und eigenen CAs sichergestellt (die eigenen CAs habe ich natürlich auf dem Client installiert und auch aktiviert (aktivieren ist beim iPhone leider nötig!). Dass den eigenen Certs auch vertraut wird habe ich mitttels Safari auch getestet. Nur beim WLAN-Aufbau kam wieder die Meldung "wird nicht vertraut".
Member: Dani
Dani May 09, 2024 at 08:11:14 (UTC)
Goto Top
Moin,
ich habe bei uns nachgefragt, wie das läuft.

Die Rahmenbedingungen sind bei uns ein wenig anders. Wir nutzen einen Ruckus WLAN Controller + APs. Als Radius kommt Microsoft NPS zum Einsatz. Die Zertifikate unserer PKI werden auf den iPhones, iPads via MDM (Mobile Iron) ausgespielt.

Im Zertifikat für den NPS stehen als CN der FQDN des NPS Cluster drin. Im SAN ist neben den FQDN des Clusters auch alle FQDN der Nodes zu sehen.

Was das Template auf der Issue CA angeht, haben wir uns an den Artikel gehalten:
https://learn.microsoft.com/en-us/windows-server/networking/technologies ...

genau das habe ich mit den Zertifikaten von LetsEncrypt und eigenen CAs sichergestellt (die eigenen CAs habe ich natürlich auf dem Client installiert und auch aktiviert (aktivieren ist beim iPhone leider nötig!).
Hast du eine zweistufige PKI? Hast du beide Zertifikate auf dem iPhone installiert?


Gruß,
Dani