15
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
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 83458668078
Url: https://administrator.de/contentid/83458668078
Printed on: April 28, 2024 at 20:04 o'clock
15 Comments
Latest comment
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.
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.
1
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
Oder das ganze über ein MDM bereistellen. So kommt auch keine Fehlermeldung
Beim Laptop kommt diese Meldung jedoch nicht!
Da hast du die Zert. Prüfung vermutlich abgeschaltet, oder?
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
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
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?! 🤔
Wenn es das denn nun war bitte den Thread dann auch als erledigt markieren!
How can I mark a post as solved?
How can I mark a post as solved?
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.
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.
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:
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.
⚠️ 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 kompatibel zu sein.
Man legt also für den Server und Client 2 kleine Textdateien z.B. "server-eku.txt" und "user-eku.txt" (nano etc.) vorab an mit folgendem Inhalt:
Server:
(Der Eintrag "subjectAltName" ist für eine reine 802.1x Authentisierung nicht unbedingt erforderlich)
Client:
(Gültigkeitsdauer hier ggf. anpassen. ⚠️ Hinweise von @colinardo unten beachten!)
Wenn die CA schon vorhanden ist kann dieser Schritt natürlich entfallen und man kann das vorhandene CA Zertifikat und Key verwenden!
(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.
Dann editiert man die EAP Datei unter /etc/freeradius/3.0/mods-available/eap und passt im Abschnitt tls-config tls-common {...} folgende Parameter an um das Zertifikat einzubinden.
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.
⚠️ Für iPhone: openssl pkcs12 -export -legacy -out Client1.p12 -inkey Client1.key -in Client1.crt 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 Endgerät.
Die User Key Erstellung wiederholt man für jeden User. Hier sollte der CN, Common Name und die Email Angabe individuell pro User gewählt werden um die später identifizierne zu können.
❗️Der User CN (Common Name) darf keine Leerzeichen enthalten!!
openssl x509 -in <zertifikat.crt> -text -noout
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:
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.
Table of contents
Extended 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 kompatibel zu sein.
Man legt also für den Server und Client 2 kleine Textdateien z.B. "server-eku.txt" und "user-eku.txt" (nano etc.) vorab an mit folgendem Inhalt:
Server:
extendedKeyUsage=serverAuth
subjectAltName=DNS:radius.meine.domain Client:
extendedKeyUsage=clientAuth CA 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 Wenn die CA schon vorhanden ist kann dieser Schritt natürlich entfallen und man kann das vorhandene CA Zertifikat und Key verwenden!
Radius 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 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.
Dann editiert man die EAP 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 Ein cp MeineCA.crt /usr/local/share/ca-certificates/ mit einem anschliessenden update-ca-certificates erledigt das.
User 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 user-eku.txt
openssl pkcs12 -export -out Client1.p12 -inkey Client1.key -in Client1.crt Das letzte Kommando packt das User Zertifikat und Key in die zu importierende PKCS12 Datei für das Endgerät.
Die User Key Erstellung wiederholt man für jeden User. Hier sollte der CN, Common Name und die Email Angabe individuell pro User gewählt werden um die später identifizierne zu können.
❗️Der User CN (Common Name) darf keine Leerzeichen enthalten!!
Zertifikats Inhalte anzeigen
openssl x509 -in <zertifikat.crt> -text -noout
1
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
Beim PKCS12 Export würde ich bei selbstsignierten CAs immer die gesamte Chain also inkl. CA/Intermediates mit in den Container packen.
Das erleichtert insbesondere auch unter Android das Handling weil man die CA gleich mitliefert.
Grüße Uwe
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.pemGrüße Uwe
1
Danke für diese wichtige Ergänzung! 👍
Moin @colindaro
Weil ich lese das etwas anders...
Gruß,
Dani
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? Weil ich lese das etwas anders...Gruß,
Dani
Zitat von @Dani:
Moin @colindaro
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 😀.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? Weil ich lese das etwas anders...Schönen Abend.
Grüße Uwe
"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. 🤔
Könnte man aber auch so verstehen das es ggf. eine Empfehlung (recommendation) ist als ein Zwang. 🤔
Moin,
Gruß,
Dani
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
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.
... This change will not affect certificates issued from user-added or administrator-added Root CAs.
