[gelöst] Eduroam: Certificate verification failed, keine Verbindung

[borish]

Ich habe neu Debian 9.4 installiert und in Gnome-NetworkManager meine Zugangsdaten für Eduroam eingegeben. Jedoch wird keine Verbindung hergestellt, im syslog ist zu lesen

Code: Alles auswählen

wpa_supplicant[612]: TLS: Certificate verification failed, error 2 (unable to get issuer certificate) 

Unter Ubuntu 16.04 hat Eduroam funktioniert. Meine Einstellungen:

Code: Alles auswählen

root@iti27:/etc# cat NetworkManager/system-connections/eduroam 
[connection]
id=eduroam
uuid=53070e49-2690-4caa-890f-ddfcdaa2f897
type=wifi
permissions=

[wifi]
mac-address=94:65:9C:91:36:AB
mac-address-blacklist=
mode=infrastructure
ssid=eduroam

[wifi-security]
key-mgmt=wpa-eap

[802-1x]
anonymous-identity=anonymous@<Meine Uni>
ca-cert=/home/boris/.certs/g_cacert.pem
eap=ttls;
identity=<Mein Nutzername>
password=<Mein Passwort>
phase2-autheap=mschapv2

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

Code: Alles auswählen

root@iti27:/etc# cat /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service
[D-BUS Service]
Name=fi.epitest.hostap.WPASupplicant
Exec=/sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
User=root
SystemdService=wpa_supplicant.service

Code: Alles auswählen

ii  wpasupplicant                         2:2.4-1+deb9u1                              amd64        client support for WPA and WPA2 (IEEE 802.11i)
ii  network-manager                       1.6.2-3                                     amd64        network management framework (daemon and userspace tools)
ii  network-manager-gnome                 1.4.4-1                                     amd64        network management framework (GNOME frontend)

[rendegast]

Wie ist es hiermit?
--------------------------------------------
system-ca-certs=true

change it to

system-ca-certs=false

If the line does not exist, add it below the [802-1x] section.
--------------------------------------------



Auch noch
--------------------------------------------
I had a similar problem, using Protected EAP (PEAP), not LEAP or FAST or Tunneled TLS in my case,
and got it working by leaving
"Anonymous identity" (huh?) empty,
PEAP version: Automatic, Inner authentication: MSCHAPv2.
--------------------------------------------
wobei bei Dir ja
eap=ttls;

[wanne]

Es wäre sehr hilfreich, wenn du die wirklich interessante Info nicht rausgeschmissen hättest:

Code: Alles auswählen

<Meine Uni>

Ansonsten würde mich ganz arg das hier interessieren.

Code: Alles auswählen

openssl x509 -in /home/boris/.certs/g_cacert.pem -noout -text -fingerprint -sha256

Der Fingerprint (letzte Zeile) sollte derda sein.
SHA256 Fingerprint=91:E2:F5:78:8D:58:10:EB:A7:BA:58:73:7D:E1:54:8A:8E:CA:CD:01:45:98:BC:0B:14:3E:04:1B:17:05:25:52
Ein aktuelles Debian bringt das (zumindest für deutsche UNIs) mit: Du kannst da einfach direkt /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem eintragen.

Sicher, dass der korrekt ist:
identity=<Mein Nutzername>
Bei der sollte bei den meisten UNIs ein @ enthalten.

Daneben nutzen die meisten UNIs PEAP und nicht TTLS wegen Windows XP Kompatibilität.

[wanne]

Hilfreich möglicherweise auch:
https://cat.eduroam.org/

[borish]

Ich habe die Einstellungen verwendet, die unser RZ hier beschrieben hat https://www.htw-dresden.de/rz/dienste/a ... uroam.html

Ich habe nun, wie in dieser Anleitung beschrieben, TTLS mit Phase2-Authentifizierung PAP eingestellt, kann mich aber immer noch nicht verbinden. Auch wenn ich /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem als Zertifikat eintrage, bleibt das Problem bestehen. Mein Nutzername ist meine E-Mail mit @. Das Setzen von system-ca-certs=false hat nichts bewirkt.

Jedoch liefert

Code: Alles auswählen

openssl x509 -in /home/boris/.certs/g_cacert.pem -noout -text -fingerprint -sha256

dieses: SHA256 Fingerprint=43:24:47:98:2B:35:54:FD:91:31:71:4D:27:A4:20:91:2C:7E:6C:91:44:79:4F:1A:FF:01:17:46:44:D3:77:4C

[BenutzerGa4gooPh]

Code: Alles auswählen

wpa_supplicant[612]: TLS: Certificate verification failed, error 2 (unable to get issuer certificate) 

Die Einstellungen "Zertifikat" und "Verbindungsserver" dienen der Nutzersicherheit, sind allerdings für den Zugang zu eduroam nicht zwingend. Sollte es am WLAN Anmeldeprobleme geben, so können bei der Fehlersuche diese Einstellungen vorübergehend ausgelassen werden.

https://www.htw-dresden.de/rz/dienste/a ... uroam.html
Allgemein: Mit PAP/Chap/EAP-MSCHAPv2 ist bei 802.1X/RADIUS/WPA2-Enterprise kein Zertifikat, nur User/Password notwendig. Zertifikat eventuell (wahlfrei) für Validierung des gewollten Servers.

PEAPv0:
EAP-GTC
EAP-MSCHAPv2

EAP-TTLS:
PAP
CHAP
MS-CHAP
EAP-MD5
EAP-MSCHAPv2

http://deployingradius.com/documents/co ... n/eap.html

[wanne]

Code: Alles auswählen

 Jedoch liefert 

Hätte ganz gerne die ganze Ausgabe gehabt, dann hätte ich mir das googeln sparen können.

Aber jetzt der reihe nach:
43:24:47:98… ist nicht das Wurzelzertifikat. Das gibt es auf der Verlinkten Seite ganz unten.
Das wäre das mit dem Fingerprint:
B6:19:1A:50:D0:C3:97:7F:7D:A9:9B:CD:AA:C8:6A:22:7D:AE:B9:67:9E:C7:0B:A3:B0:C9:D9:22:71:C1:70:D3
http://cdp.pca.dfn.de/telekom-root-ca-2 ... cacert.pem
Das nutzt aber noch SHA1. Das will der DFN (zurecht) nicht mehr sehen.
Würde tippen, dass die Anleitung alt ist. Nachdem /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem nicht tut vielleicht aber gar nicht so falsch.
Lustigerweise gibt es danach einen Button mit "SHA-1 Zertifikate anziegen" obwohl schon die darüber SHA-1 sind.

Ansonsten cat (konfigurator) für htw-dresden:
https://cat.eduroam.de/user/API.php?act ... profile=98
Der generiert dasda:

Code: Alles auswählen

network={
  ssid="eduroam"
  key_mgmt=WPA-EAP
  pairwise=CCMP
  group=CCMP TKIP
  eap=PEAP
  ca_cert="${HOME}/.cat_installer/ca.pem"
  identity="${USER_NAME}"
  domain_suffix_match="radius.htw-dresden.de"
  phase2="auth=MSCHAPV2"
  password="${PASSWORD}"
  anonymous_identity="anonymous@htw-dresden.de"
}

[wanne]

Die Einstellungen "Zertifikat" und "Verbindungsserver" dienen der Nutzersicherheit, sind allerdings für den Zugang zu eduroam nicht zwingend. Sollte es am WLAN Anmeldeprobleme geben, so können bei der Fehlersuche diese Einstellungen vorübergehend ausgelassen werden.

Schmerz!
Dir sollte klar sein das WPA-Enterprise nur das Passwort schützt. Alles andere ist Vertrauensbasis. (Rein theoretisch könnte man bei eduroam absichtlich falsche logins machen um zu testen ob der AP echt ist, da nur der wirklich zum "echten" Radius darf. Aber das macht keiner.) Das Zertifikat stellt sicher, dass das Passwort nicht in falsche Hände fällt.
Hat der Angreifer das ein mal braucht er es kein weiteres mal. Ob du die Validierung jetzt vorübergehend oder dauerhaft abschaltest ist völlig Wurst.
Passt aber wunderbar zur Kompetenz mit den SHA-1 Zertifikaten und NTLM-Authentifizierungen. Die sind ja auch erst seit 13 bzw. 20 Jahren gebrochen.

[BenutzerGa4gooPh]

Schmerz!
Dir sollte klar sein das WPA-Enterprise nur das Passwort schützt.

Man kann doch auch ausschließlich mit Nutzerzertifikaten auf allen Hosts für Logins der eigenen Mitarbeiter arbeiten. PAP, CHAP nur für faule/praxisnahe Admins (mit RADIUS-Configs, LDAP, AD/DC, BringYourOwnScheiß-Dervices). Ich meine rein firmenintern, "WPA2-Enterprise-feature-mäßig". Muss wieder mal am Ausdruck Teutscher Sprache arbeiten.

[wanne]

Es gibt vor allem mit WPA-PWD eine Variante die nicht nur sicher für beide Seiten ist, sondern sogar Idiotensicher ist. Aber bring das mal einem Netzadmin bei.
Trotzdem ist WPA2-Enterprise IMHO prinzipbedingt kaputt für diesen Zweck. Radius prüft den Clienten. Schon dass der Client den Radius prüft wurde nur (extrem schlecht) draufgepfopft um MitM-Angriffe zu beseitigen. Am ende müsste der Radius dafür sorgen, dass der AP nicht unsicher ist. Und im Standard selbst ist das nicht vorgesehen. Kann man schon so implementieren. Aber war offensichtlich nie so gedacht. Und in eduroam extrem schwer umsetzbar. Wie soll der Radius denn sicherstellen dass die tausende APs aus hunderten von Organisationen alle sicher sind. Der Client sollte annehmen, dass da drausen halt das Internet beginnt und er da selbst für Sicherheit sorgen muss.

[BenutzerGa4gooPh]

Am Ende müsste der Radius dafür sorgen, dass der AP nicht unsicher ist. Und im Standard selbst ist das nicht vorgesehen.

So tief kenne ich mich nicht aus, habe vor mehr als 1 Jahr mal freeradius mit 1 Accesspoint "durchgespielt" (Konfigs ohne Datenbank-Anbindung, aber mit Dummy-Zertifikaten (CA= freeradius). Da ich das nicht beruflich mache, genügt mir Anfangserfolg, Überblick. Feinheiten würde ich eh schnell vergessen.

Jedenfalls authentifizieren sich APs (und entsprechende Profi-Switches mit 802.1X) am Server per shared secret.
http://www.tldp.org/HOWTO/html_single/8 ... henticator (5.1).
(Leicht austricksbare Authentifizierung per MAC-Adressen für alte Switches gibt es nach meiner gelesenen Erinnerung auch.)

Für neugierige Mitleser: freeradius-Doku ist dünn, die Konfigs sind mittels Kommentaren ganz gut dokumentiert. Einfach freeradius anfangen mittels dünner Doku, gut kommentierte Konfigs bearbeiten, mit AP und WLAN-Client verschiedene Authentifizierungen testen: PAP-> MS-ChapV2 -> Zertifikate.
https://freeradius.org
(Vorher schauen, ob euer WLAN-AP WPA2-Enterprise/RADIUS/802.1X unterstützt. Erhöht WLAN-Sicherheit und tut nicht weh, wenn eh ein Homeserver/NAS läuft.)

Gestern habe ich einen Kommentar gelesen: pfSense hätte das einzig vernünftige GUI für freeradius. Ansonsten gibt es noch Windows Server mit Klicki-Bunti-RADIUS und Datenbank des Domain Controllers.

[wanne]

Jedenfalls authentifizieren sich APs (und entsprechende Profi-Switches mit 802.1X) am Server per shared secret.

Ja. Der Trick für den Angreifer ist erst gar nicht beim Radius nachzufragen sondern einfach den Zugang zu gewähren.
Deswegen auch mein Kommentar mit dem Test von falschen logins. Denn feststellen ob ein Passwort fasch oder richtig ist, sollte ein Fake AP nicht können.

[borish]

Ich habe das Problem nur mit Hilfe des Rechenzentrums gelöst. Es lag daran, dass etwas an den Passwörtern umgestellt wurde.