Inderdaad materie om goed over na te denken, zeker gezien een trusted algemeen CA certificaat op Windows inderdaad ook voor andere zaken dan enkel het signen van een certificaat voor Wi-Fi gebruikt kan worden (HTTPS Man-in-the-Middle etc. ).

Echter zie ik een aanname die in ieder geval binnen onze omgeving niet op gaat, namelijk dat de private key van de CA op jouw NPS/RADIUS server aanwezig is. Dit hoeft namelijk niet, voor enkele van onze klanten hebben wij een wireless EAP oplossing en hier vraagt de NPS/RADIUS server een certificaat aan van onze CA t.b.v. EAP. De CA zit in een ander netwerk dan de RADIUS server en het verversen van het certificaat wordt jaarlijks manueel uitgevoerd. Hierdoor ligt er in ieder geval geen risico voor de private key van de CA bij de RADIUS server, enkel het getekende certificaat t.b.v. EAP (met key), maar hiermee is het niet mogelijk om andere zaken te doen dan Wi-Fi.

Als je vervolgens de CA trust op de devices (middels GPO, MDM etc. ) dan heb je in mijn ogen een afdoende beveiligde Wi-Fi omgeving, uiteraard blijft dan wel het risico dat bij een eventueel lek van jouw CA private key het inderdaad mogelijk is om een MitM te creëren echter is dit voor de meeste organisaties waarschijnlijk een acceptabel risico (mits er genoeg controls in-place zijn om jouw CA te beschermen, auditen etc. ).

Overigens zie ik ook andere IT organisaties welke een self-signed certificaat uitrollen en gebruikers intrueren om (een gedeelte van) de fingerprint te verifiëren alvorens connectie te maken. Ik denk niet dat dit een mooie oplossing is, en stel zelf de vraag of je die verantwoordelijkheid bij de eindgebruiker kan leggen, maar het werkt wel en het is verder niet nodig om een CA te trusten o.i.d. aangezien je deze fingerprint ziet bij het maken van de connectie.

Ja dat is inderdaad zo, die key is in normale productie niet nodig.
Maar goed we hebben evengoed geen aparte machine die veel veiliger is dan deze.

Het downloaden van het certificaat kunnen we met MDM doen en het configureren van de WiFi ook, dat is het probleem
niet, waar het om gaat is dat ik liever niet een CA certificaat op alle devices installeer zonder dat er gebruiksrestricties zijn.
En die zijn er bij Android dus wel: een dergelijk CA cert kan alleen binnen de WiFi WPA2-EAP checks gebruikt worden
en niet in de browser ofzo. Ik vind het een beetje teleurstellend dat Windows dat niet heeft, er zijn al zoveel mapjes
in die certificaat manager dat er best apart een bij had gekund voor dit doel.
Maar uit je antwoord begrijp ik dat dit inderdaad niet het geval is, en dat het nou eenmaal zo krom werkt in Windows.

Je maakt een denk fout, tussen een CA en een Certificaat.

Even simpel uitgelegd:

Een CA is een Certificaat Authority, dit is ook een specifiek certificaat en kan nieuwe certificaten uitgeven.
Een certificaat, kan selfsigned zijn, of uit een CA komen en heeft bepaalde eigenschappen (OID). Deze eigenschappen bepalen waarvoor je certificaat kunt gebruiken. Om een CA te zijn, heeft het certificaat dus bepaalde eigenschappen nodig, die een standaard 'server' certificaat niet heeft.

Je kunt dus voor je WPA Auth kun je een self signed Certificaat gebruiken en deze importeren in je omgeving, zonder enige verdere complicaties of risico's die jij beschetst.

Ik denk dat jouw terleurstelling voornamelijk voort koment uit missende kennis en ervaring.

Dat denk ik toch niet, hoor.
Die WPA-EAP auth heeft een server certificaat nodig maar dat moet ondertekend worden door een CA.
Om te weten of het server certificaat echt is, moet de client checken of het door een vertrouwde CA ondertekend is.
Daarom moet je het CA certificaat op de client installeren. Maar dat certificaat heeft als attribuut alleen "CA" en kan
dus gebruikt worden om allerlei andere certificaten te ondertekenen, niet alleen "servercertificaten tbv WPA-EAP".
Om dat onderscheid te maken moet de client het rubriceren bij certificaten met dat doel, en dat doet Android ook.
Maar Windows dus niet.

Je kunt geen certificate signen met een CA Certificate.
Maar wel met de private key van de CA.
Dus als je zorgt dat niemand bij je private key kunt komen ben je "veilig", En kun je de CA Certificate vrij distribueren.

Ja maar als je daar de middelen niet voor hebt dan heb je dus een probleem.
Althans, op Windows. Niet op Android.

Wat is het toch met ITers dat ze zo graag pedant doen - alleen maar irritant.

Dat weet TS en m'n neus ook. Maar als je - zoals TS - in de situatie zit dat je de veiligheid van de Wifi-CA-private key minder goed kunt garanderen vraag je je af of er een manier is om de rechten van certificaten getekend met de minder-trusted-CA key te beperken tot "WPA-EAL" .
Geen rare vraag omdat het bijvoorbeeld op Android wel kan .

Goed uitgelegd , terechte vraag of het op de een of andere manier dan ook op Windows kan.
En wat krijgt ie - niks dan geneuzel van wannabe's .

Voor TS -

Je zegt dat Windows default toch al niet checked - als je dat uberhaupt niet kunt wijzigen naar "check wel" - dan doe je het al helemaal nergens voor.
Dus - aangenomen dat je windows WEL het Wifi certificaat kunt laten checken zou ik zeggen " importeren" .

Je moet een cruciale component als een freeradius EAP server gewoon _toch_ zwaar dichttimmeren en goed bewaken.
Er is iets heel verkeerd in je setup als de meerwaarde van de HSM ook echt gebruikt wordt - een compromise waarbij de HSM z'n nut moet bewijzen (dwz - aanvaller die lokaal alles kan) - dan is er iets enorm mis gegaan.

Stel dat je constateert dat je WPA-EAP server compromised is en de CA private key gestolen - dan moet je 'gewoon' op al je clients die private CA deleten en een nieuwe installeren.

Dat is wel het voordeel van een managed client base en een private CA - je kunt in principe de impact van het lekken van die private key ongedaan maken door het CA certificaat "gewoon" overal te vervangen.

Ik zet "gewoon" tussen quotes omdat het natuurlijk - bij een grote en roamende populatie nogal een klus is om dat acuut te doen .
Maar goed - moet maar voor de situatie waarin dan eventueel die EAP server helemaal gehacked zou zijn.

Dat is op zich wel waar, maar helaas zitten er ook flink wat devices op de WiFi die niet direct onder MDM vallen.
Echter ik kan uiteraard wel een aparte realm gebruiken voor Windows clients, daar een nieuwe CA voor maken en DIE
kan ik wel gemakkelijk schonen als er wat fout mee gaat. Immers met MDM (Intune) kun je dit soort dingen ook op clients
regelen zonder dat ze "op de zaak" zijn, en voor clients die helemaal nooit online zijn (omdat ze ongebruikt in een kast
liggen ofzo) is het ook niet zo van belang dat het accuut geregeld wordt.

Zou toch al handig zijn om dit apart te houden want dan kan ik die hele toestand ergens bij Azure onderbrengen en de RADIUS server voor die realm als proxy laten werken.
Het lijkt er alleen wel op dat een SCEP server en radius weer iets is wat extra 3rd party producten of een hoop gedoe gaat geven, als de stories die ik daarover vind niet inmiddels achterhaald zijn. Ga ik maar eens navragen.

Vooraf: ik weet wel wat van certificaten en door gebruikers veroorzaakte risico's, maar ik ben geen RADIUS-expert.

Als "publieke" RADIUS certificaten door alle actuele client-besturingssystemen worden geaccepteerd (of dat het geval is, weet ik niet en kon ik niet vinden op internet), dan vraag ik me sterk af of dat "algemene advies" verstandig is, vooral bij kleinere organisaties en/of met gebruikers zonder MDM.

Mijn eerste zorg zou namelijk niet zijn dat de private key [*] van je CA-certificaat in verkeerde handen valt, maar dat gebruikers domme dingen doen: zoals onbekende certificaten accepteren, certificaat-checks disablen of klakkeloos een bijvoorbeeld gemailde "certificaat-update" installeren (schrijvers van een fake e-mail kunnen leken wellicht overtuigen/afleiden door erbij te schijven wat de fingerprint is van het meegezonden certificaat en dat ze die moeten checken).

[*] Hoewel je niet wilt dat die server gehacked wordt, zou ik die private key versleuteld opslaan (en niet het wachtwoord ervoor "onder de deurmat" opnemen in scripts voor het genereren van nieuwe client en server certs).

Het veiligste is het als je alle users zo opvoedt dat zij je bellen bij elke certificaatfoutmelding en/of verzoek om iets te installeren (met een fout rootcert moet je niet alleen vrezen voor MITM-aanvallen, er kunnen ook codesigning-certificaten mee worden gemaakt). Mede voor jouw eigen rust is het dus belangrijk dat users zo min mogelijk foutmeldingen zien. En dat een verzoek om uiterst risicovolle dingen te doen (zoals een rootcert installeren) nooit bij jou vandaan komt, en als het wel daarop lijkt, de users snappen dat dit foute boel is en ze jou moeten bellen (als het gebruikelijk is dat jij zoiets doet, bellen ze je niet meer bij nep).

Zoals ik schreef, ik weet niet of "publieke" RADIUS certificaten door alle client-besturingssystemen worden geaccepteerd (ik zou het een slechte zaak vinden als dit niet het geval is).

Natuurlijk moet de installatie wel goed gedaan worden, zoals door de RADIUS-server laten meesturen van alle intermediate certificaten. Met Googlen vond ik dat de RADIUS-server over een geldige en unieke FQDN (zoals radius.example.com) moet beschikken. Het zou kunnen dat sommige (oudere?) clients vereisen dat de OID "1.3.6.1.5.5.7.3.14" ("eapOverLAN" voor "EAPoL (802.1X)" [1]) in het lijstje van "Extended key usage" items in het RADIUS-certificaat staat.

[1] https://www.alvestrand.no/objectid/submissions/1.3.6.1.5.5.7.3.14.html

Essentieel is dat in de netwerkinstellingen op de client de check op het RADIUS-certificaat niet is uitgezet. Op internet las ik dat dit in Android t/m versie 10 gewoon kan, in 11 deels niet meer en in 12 helemaal niet meer. De meeste lezers zullen begrijpen wat de gevolgen zijn als de client met een wachtwoordhash authenticeert op een fake RADIUS-server, maar ook bij authenticatie met een client-certificaat kan een fake RADIUS-server voor de huidige sessie als MitM optreden.

Het zou ook best kunnen dat self-signed RADIUS-certificaten goed werken (met daarin, onder "Basic Constraints": "CA=False"). Met zo'n certificaat geïnstalleerd in een OS kan een aanvaller niet meer kwaad dan met een publiek uitgegeven certificaat. Maar met zo'n self-signed cert bestaat wel het risico dat een eindgebruiker wordt overgehaald om een ander certificaat (met heel andere eigenschappen) te installeren.

Kortom, hoewel het in MS AD omgevingen gebruikelijk is om zelf RADIUS-certificaten te maken, is dat niet persé in alle gevallen de meest veilige optie.

Zijn er lezers die goede ervaringen hebben met "publieke" RADIUS- certificaten?

P.S. ik heb niets te maken met de verkoop van certificaten (ook nooit gehad). Ik ben gewoon benieuwd wat de veiligste oplossingen o.a. voor authenticatie zijn en tegen welke praktijkproblemen men oploopt. Dus dank aan de TS voor deze draad!

Het probleem is dat je niet veel hebt aan een "officieel" certificaat, omdat iedereen een officieel certificaat kan aanvragen.
Voor niks zelfs, tegenwoordig.
Het gaat er niet om of de server "officieel" is, maar of het precies de server is die je wilt.
En als je verbindt met een WiFi SSID weet je niet wat de naam van de server is die daar achter hoort te zitten.

Om dat te bereiken is de methode dus om een EIGEN CA op te zetten, en DIE CA in de client aan te merken als
de uitgever van het server certificaat. De client vertrouwt dus niet zomaar ieder certificaat, maar alleen die certificaten
die uitgegeven door de CA die hij/zij gekozen heeft bij het maken van de verbinding. Om dat (in een zakelijke
omgeving) wat eenvoudiger te maken wordt er een MDM (mobile device management) platform gebruikt waarmee
je de parameters en ook het CA certificaat in het device download op het moment dat dit gejoined wordt met de MDM.
Je kunt het ook handmatig doen maar dan moet je dus eerst het CA certificaat downloaden vanaf een plek die
je vertrouwt (bijvoorbeeld een website waar een "officieel" certificaat aan hangt) en in je device installeren.
Dit CA certificaat moet CA=True hebben, want het signed vervolgens een server certificaat (of keten) die tijdens
het login proces aan de client gepresenteerd wordt, en dat moet die client dan dus checken.

Waar ik me nu zorgen om maak is dat dit checken in Windows alleen mogelijk lijkt te zijn via CA certificaten die
geinstalleerd zijn in de systeem-brede certificaat store en die niet specifiek beperkt zijn tot gebruik voor een WiFi
verbinding. Dus als de key niet zo veilig bewaard is als die van een "officiele" uitgever dan zou het kunnen gebeuren
dat er willekeurige andere certificaten uitgegeven worden die de client dan vertrouwt. Uiteraard kan het certificaat
dan ingetrokken worden.

(inderdaad hebben moderne clients ook een invoerveld voor een domeinnaam die dan in het server certificaat moet
staan, maar dit is een "recente" toevoeging die lang niet alle clients ondersteunen. ik denk inderdaad dat dit een
poging is om het CA probleem de wereld uit te helpen door met "officiele" certificaten te gaan werken)

Hiermee zette je mij op het verkeerde been, maar uit de tekst daarna denk ik nu (eindelijk) te begrijpen wat het probleem is: er zijn (nog) clients waarbij je in de netwerkinstellingen voor een specifiek SSID niet kunt specificeren wat ofwel de FQDN van de radius server is (bijv. "radius.jouwbedrijf.nl" of "wifi.jouwbedrijf.nl") ofwel de FQDN van jouw domein ("jouwbedrijf.nl").

Dus omdat de naam in het certificaat niet door sommige clients gecheckt wordt, zal elk willekeurig geldig certificaat geaccepteerd worden. Wie verzint zo'n systeem?

Nog meer frustratie tussendoor:

Ik was in de veronderstelling dat WPAx-Enterprise veel veiliger is dan personal, maar dat is niet zo: wat een puinhoop. Overal lees ik adviezen als volgt, uit https://cloud4wi.zendesk.com/hc/en-us/articles/360036215531-WPA2-Enterprise-Android:
Vervolgens zie ik veel boze reacties over dat de mogelijkheid voor "Do not validate" is verdwenen in Android 11 en 12.

En uit https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/certificate-requirements-eap-tls-peap van 24 sept 2021 maak ik op (mogelijk onterecht) dat als een radius-server een ander certificaat stuurt dan is geconfigureerd, de eindgebruiker ervoor mag kiezen om dat nieuwe certificaat voortaan te vertrouwen (opmaak door mij):

Terug naar de vraag van de TS, waarvan ik de achtergrond nu wel hoop te begrijpen:

Kennelijk kun je op die suffe clients die geen domeinnaam accepteren, voor een specifieke SSID wel een rootcertificaat installeren en aangeven dat elk daarvan afgeleid (end-entity) certificaat geaccepteerd moet worden (ongeacht welke CN daarin gespecificeerd is), en dat andere certificaten, die valideren met in het OS meegeleverde rootcertificaten, moeten worden geweigerd.

Overigens vermoed ik dat je bij dit soort clients (en wellicht bij alle), in plaats van een eigen rootcert, ook een end-entity cert kunt importeren (zie het einde van deze post).

Kort antwoord: wat je wilt kan, zo te zien, gedeeltelijk.

Lang: Windows lijkt het beperken van "certificate purposes" te ondersteunen, maar daarbij gaat het kennelijk uitsluitend om EKU (Extended Key Usage) certificaat-velden. Hoe dit werkt was mij niet meteen duidelijk; dit is wat ik ervan begrijp:

Als je bijvoorbeeld 'certlm' (lm voor Local Machine) start en een categorie kiest is er een kolom "Intended purposes". Ook kun je onder menu View -> Options kiezen voor "view by purpose". Sommige rootcerts hebben purpose "All", maar de meeste zijn beperkt.

Als je dubbel-klikt op een beperkt certificaat en de Details tab opent, zie je onderaan een "Enhanced key usage" veld. Dat vind ik verwarrend, want die rootcerts hebben helemaal niet zo'n veld (logisch want het gaat niet om eigenschappen van dat rootcert zelf, maar van daarmee uitgegeven end-entity certs). Als je zo'n certificaat exporteert en dat bekijkt, zul je zien dat er geen EKU-veld is.

Als je de dialoogbox sluit en met de rechter muistoets (in certlm of certmgr) op zo'n beperkt certificaat voor Properties kiest, zie je dat het een overlay is, een masker zeg maar. Je kunt ook een purpose toevoegen, dat moet een OID zijn (bijv. "1.3.6.1.5.5.7.3.14" die ik eerder noemde).

Als ik het goed begrijp kun je, als je zelf een rootcert installeert, dus beperken welke toepassingen afgeleide end-entity certificaten mogen hebben. Voor jouw doel kun je, vermoed ik, alles uitzetten behalve "Server Authentication". En misschien moet je "1.3.6.1.5.5.7.3.14" toevoegen en toestaan.

Je hebt dan in elk geval o.a. code-signing uitgesloten, maar niet https. Niet zo selectief als Android dus, waar je niet alleen het doel beperkt tot WPAx-Enterprise, maar ook koppelt aan een specifieke SSID. En ook dat is belangrijk, anders kan jij voor elke SSID een radius-cert maken dat de client zal accepteren (en daarmee zou jij MITM aanvallen kunnen uitvoeren als jouw client(s) elders met WPAx-Enterprise inloggen). Een kwaadwillende die jouw rootcert-private key in handen krijgt, kan dat dus ook.

Andere risico's van het uitlekken van de private key van jouw rootcert zijn:
1) Als je client certificaten gebruikt die afgeleid zijn van hetzelfde rootcert, kan een aanvaller zelf een client certificaat maken en zo op jouw netwerk komen (tenzij freeRadius een "allow-list" gebruikt, ik weet niet of dat zo is).
2) Als je geen gebruik maakt van client certs kan een aanvaller een MITM-attack uitvoeren door zelf een RADIUS-certificaat te maken voor een fake RADIUS server en een user via een fake AP laten aanmelden.

Ook zullen mensen die jouw rootcert installeren er niet alleen op moeten vertrouwen dat jij de private key goed beschermt, maar ook dat jij zelf te vertrouwen bent (zie de onderste reactie in https://support.google.com/pixelphone/thread/93933361/can-t-connect-to-wifi-as-domain-is-mandatory-wifi-network-is-wpa3-and-doesn-t-need-a-domain?hl=en).

Ik weet niet of alle clients de pre-installatie van een self signed (end-entity) RADIUS cert accepteren (dus in plaats van een rootcert); daarbij zijn de risico's kleiner. Als de private key daarvan in verkeerde handen valt, kan een aanvaller wel een MITM-attack uitvoeren als de gebruiker aanmeldt op jouw WiFi, maar verder heeft hij er dan niets aan. En dit risico heb je sowieso met elk type end-entity certificaat.

Ja ik weet het ook niet hoor, ik ben alleen een gebruiker, geen ontwerper van dit soort dingen.
Het is inderdaad zo dat er steeds vanalles veranderd wordt. Wat vandaag een "best practice" is kan morgen best
een "uit te faseren oplossing" zijn en overmorgen "deprecated, kan niet meer, moet je anders gaan doen".
Heel vervelend is dat, want er zit vaak aan iedere wijziging een hoop werk vast.

Bij freeradius bijvoorbeeld zitten scripts om die certificaten te genereren en die veranderen ze de hele tijd. Toen ik
de freeradius server geinstalleerd had als onderdeel van Debian 10 waren er meteen al problemen en toen ik daar
naar ging googlen las ik al "oh ja maar dat is een oude versie freeradius je moet de nieuwe versie gebruiken van
onze github". Okeee.... daar heb ik toen die scripts van gedownload en die gebruikt om de certificaten te maken.

Maar dat was ruim een jaar geleden dus kan best zijn dat dat nu al weer allemaal over de kop gegooid is. Ik zal er
maandag eens naar kijken of dat zo is. (dit is werk dus daar ga ik in het weekend niet te veel tijd in steken)

Wat betreft "andere sites", kijk maar eens op de websites van organisaties die dit soort dingen gebruiken (*roam)
naar de handleidingen die ze geven, bijvoorbeeld publicroam. Die lui zitten ook met dat probleem dat er zo veel
verschillende versies zijn en dat de een iets niet kan wat de ander juist vereist, enz...

In ieder geval bedankt voor de reacties. Je zult er wel achter zijn dat het allemaal niet zo simpel ligt als sommige
reageerders wellicht dachten.

De beperkingen van het server-side deel van EAP kunnen worden opgevangen door certificaten te gebruiken op de client om mee te authentiseren. Dan gaan er geen wachtwoorden meer over de lijn of door de lucht.

Een eigen CA inregelen en die voor EAP gebruiken is een goede optie, maar onwerkbaar als er ook externen op de je netwerk moeten komen. Die moeten jouw eigen CA dan ook impliciet vertrouwen (of door foutmeldingen e.d. heen worstelen). In dat geval is het gebruik van een publieke CA weer gewenst. Ik vertrouw liever een PKI Overheid Root CA dan een ACME Snake Oil CA die onder het bureau van de boekhouder draait.

Verder heeft Windows de mogelijkheid de CN in het certificaat te checken en als je dan een certificaat op de RADIUS gebruikt die uit een gerenormeerde CA komt en waar meer dan alleen domein eigendom gecheckt wordt, dan is de kans erg klein dat iemand uit die CA een certificaat kan trekken met dezelfde CN.

Zoals met alle security vraagstukken in de IT; alles heeft voor en nadelen.