Rob
2021-06-08 13:57:46 UTC
Ik stel de vraag maar hier omdat er hier nog wel eens een freeradius
deskundige rondloopt :-)
Ik heb WPA2-EAP op een netwerk opgezet met freeradius 3.0.17 en daarbij
een eigen CA en server certificaat aangemaakt met de bij Debian Buster
geleverde scripts daarvoor. In de README wordt je op het hart gedrukt om
vooral niet zelf met die certificaten te gaan knutselen want de attributen
die die scripts er inzetten zijn essentieel staat er. En ook om niet
een "officieel" server certificaat te gebruiken (van letsencrypt ofzo)
maar nee je moet gaan kloten met die eigen CA.
Maar nu loop ik met die certificaten toch tegen een probleem aan omdat
de almachtige Google wat dingen aan het veranderen is en het in een recent
geupdate Android telefoon niet meer goed werkt...
Tot nu toe kon ik het CA certificaat van een server downloaden met Chrome
en dan zegt ie "openen" bij dat bestand en als je dat deed dan kon je
een certificaat naam opgeven en doel (voor gebruik met WiFi) en dan werd
het geinstalleerd, kennelijk als CA cert. Als je dan een WiFi verbinding
maakt vraagt ie om identity en password en geeft aan dat je het CA
certificaat moet selecteren, daar kies je dan dat zojuist geinstalleerde
CA certificaat en dan werkte het.
Maar als je dit nu doet zegt ie "nee dat kan niet meer je moet het
via de certificaat settings doen" en als je dat doet kun je wel dat
gedownloade certificaat installeren maar dan is het meteen al onduidelijk
hoe je hem moet installeren, hij geeft dan de keuze (naast anderen) voor
WiFi certificaat of CA certificaat. Ik denk nu dat ie met WiFi certificaat
een client certificaat bedoelt maar dat gebruiken we dus niet. Maar een
CA certificaat toevoegen wat voor ALLES werkt, dat zou dom zijn.
Beiden geprobeerd maar het gaat niet zoals het moet.
Als je daarna naar de WiFi verbinding gaat en dat certificaat selecteert
vraagt ie om "domein". De door die scripts aangemaakte certificaten
hebben helemaal geen domein! Afijn wat je ook invult het werkt niet,
zonder foutmelding verder.
Nu is de vraag wat moeten we nu doen? Een server certificaat aanmaken
met andere attributen, bijv met ook een domein erin als alt.subject?
Voor nu is het (met Samsung toestellen) nog mogelijk om er om heen te
werken door "certificaat niet valideren" te kiezen maar toen ik ging
googlen om te zien of anderen ook het bovenstaande probleem hadden zag
ik dat er inmiddels een nieuwe update onderweg is die DIE optie ook
nog weg ging halen en dat nu de mensen die nooit de moeite namen om een
CA cert voor WiFi te installeren op hun devices in de problemen zaten.
Maar zover kom ik dus niet eens, dit is alleen probleem dat in de toekomst
nog lastiger kan gaan maken...
Het interessante is dat een toestel wat al voorzien is van de juiste
CA cert en verbinding het gewoon blijft doen als de update geinstalleerd
wordt die het onmogelijk maakt om die verbinding nog aan te maken
(door die vraag naar "domein").
Heeft hier al iemand mee lopen tobben?
Het grappige is dat Windows precies de andere kant op roeit. Daar kun
je tegenwoordig als je een WiFi verbinding met WPA2-EAP maakt alleen
nog een usernaam en password invullen, knopjes om CA cert of client
cert te specificeren die zijn allemaal weggehaald en een advanced
knopje is er ook niet. Dus de Windows clients draaien allemaal zonder
cert validatie, wat in principe onveilig is maar wat doe je eraan?
deskundige rondloopt :-)
Ik heb WPA2-EAP op een netwerk opgezet met freeradius 3.0.17 en daarbij
een eigen CA en server certificaat aangemaakt met de bij Debian Buster
geleverde scripts daarvoor. In de README wordt je op het hart gedrukt om
vooral niet zelf met die certificaten te gaan knutselen want de attributen
die die scripts er inzetten zijn essentieel staat er. En ook om niet
een "officieel" server certificaat te gebruiken (van letsencrypt ofzo)
maar nee je moet gaan kloten met die eigen CA.
Maar nu loop ik met die certificaten toch tegen een probleem aan omdat
de almachtige Google wat dingen aan het veranderen is en het in een recent
geupdate Android telefoon niet meer goed werkt...
Tot nu toe kon ik het CA certificaat van een server downloaden met Chrome
en dan zegt ie "openen" bij dat bestand en als je dat deed dan kon je
een certificaat naam opgeven en doel (voor gebruik met WiFi) en dan werd
het geinstalleerd, kennelijk als CA cert. Als je dan een WiFi verbinding
maakt vraagt ie om identity en password en geeft aan dat je het CA
certificaat moet selecteren, daar kies je dan dat zojuist geinstalleerde
CA certificaat en dan werkte het.
Maar als je dit nu doet zegt ie "nee dat kan niet meer je moet het
via de certificaat settings doen" en als je dat doet kun je wel dat
gedownloade certificaat installeren maar dan is het meteen al onduidelijk
hoe je hem moet installeren, hij geeft dan de keuze (naast anderen) voor
WiFi certificaat of CA certificaat. Ik denk nu dat ie met WiFi certificaat
een client certificaat bedoelt maar dat gebruiken we dus niet. Maar een
CA certificaat toevoegen wat voor ALLES werkt, dat zou dom zijn.
Beiden geprobeerd maar het gaat niet zoals het moet.
Als je daarna naar de WiFi verbinding gaat en dat certificaat selecteert
vraagt ie om "domein". De door die scripts aangemaakte certificaten
hebben helemaal geen domein! Afijn wat je ook invult het werkt niet,
zonder foutmelding verder.
Nu is de vraag wat moeten we nu doen? Een server certificaat aanmaken
met andere attributen, bijv met ook een domein erin als alt.subject?
Voor nu is het (met Samsung toestellen) nog mogelijk om er om heen te
werken door "certificaat niet valideren" te kiezen maar toen ik ging
googlen om te zien of anderen ook het bovenstaande probleem hadden zag
ik dat er inmiddels een nieuwe update onderweg is die DIE optie ook
nog weg ging halen en dat nu de mensen die nooit de moeite namen om een
CA cert voor WiFi te installeren op hun devices in de problemen zaten.
Maar zover kom ik dus niet eens, dit is alleen probleem dat in de toekomst
nog lastiger kan gaan maken...
Het interessante is dat een toestel wat al voorzien is van de juiste
CA cert en verbinding het gewoon blijft doen als de update geinstalleerd
wordt die het onmogelijk maakt om die verbinding nog aan te maken
(door die vraag naar "domein").
Heeft hier al iemand mee lopen tobben?
Het grappige is dat Windows precies de andere kant op roeit. Daar kun
je tegenwoordig als je een WiFi verbinding met WPA2-EAP maakt alleen
nog een usernaam en password invullen, knopjes om CA cert of client
cert te specificeren die zijn allemaal weggehaald en een advanced
knopje is er ook niet. Dus de Windows clients draaien allemaal zonder
cert validatie, wat in principe onveilig is maar wat doe je eraan?