20
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 83458668078
Url: https://administrator.de/forum/eap-peap-ueber-radius-cert-wird-nicht-vertraut-83458668078.html
Ausgedruckt am: 21.12.2024 um 14:12 Uhr
20 Kommentare
Neuester Kommentar
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!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
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 gleich mit diesem Attribut 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:
(Der Eintrag "subjectAltName" ist für eine reine 802.1x Authentisierung nicht unbedingt erforderlich und kann ggf. weggelassen werden oder mit einer lokalen Domain wie radius.fritz.box oder radius.meinnetz.internal etc.)
Clientdatei:
(Gültigkeitsdauer hier ggf. anpassen. ⚠️ Hinweise von @colinardo unten beachten!
Dateinamen wie MeineCA sind frei wählbar.)
👉🏽 Wenn die CA schon vorhanden ist kann dieser Schritt natürlich entfallen und man verwendet in dem Falle das vorhandene CA Zertifikat und Key!
(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 oben generierte 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 manuell an um das korrekte 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.
Danach startet man den Freeradius mit systemctl restart freeradius neu.
⚠️ Für Apple Endgeräte iPhone / iPad etc. ist das letzte Kommando (Zeile 5) unbedingt 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 im jeweiligen Endgerät zu importierende PKCS12 Datei.
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. Z.B. Namenskürzel etc.
⚠️❗️Dieser 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.
Inhaltsverzeichnis
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 gleich mit diesem Attribut 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 Clientdatei:
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 Dateinamen wie MeineCA sind frei wählbar.)
👉🏽 Wenn die CA schon vorhanden ist kann dieser Schritt natürlich entfallen und man verwendet in dem Falle das vorhandene CA Zertifikat und Key!
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 oben generierte 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 manuell an um das korrekte 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.
Danach startet man den Freeradius mit systemctl restart freeradius neu.
User Zertifikat und 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 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 im jeweiligen Endgerät zu importierende PKCS12 Datei.
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. Z.B. Namenskürzel etc.
⚠️❗️Dieser 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.
Wenn es das denn nun war bitte nicht vergessen deinen Thread dann auch als erledigt zu markieren!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
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
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!!!
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!!!
Ist nicht nachzuvollziehen was du da schreibst. 
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.
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 ...
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.
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 ...
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".
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 ...
Gruß,
Dani
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
