19
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: May 4, 2024 at 01:05 o'clock
19 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.
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?
How can I mark a post as solved?
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.
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.
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".
