PIV-aanmelding mislukt op Windows EAP-TLS? Controleer het ondertekeningspad

Toon het certificaat van een PIV-kaart in elk Windows-dialoogvenster en de VPN-aanmelding kan nog steeds mislukken, omdat zichtbaarheid en bruikbaarheid verschillende eigenschappen zijn. Het certificaat is een openbaar object; de aanmelding vereist een privésleutelbewerking die de kaart uitvoert volgens haar eigen toegangsregels. Tussen die twee feiten liggen vier fasen die op vier verschillende manieren mislukken: profielselectie, certificaatselectie, lokaal ondertekenen en validatie aan de serverzijde. Ze in volgorde doorlopen maakt van een algemene handshake-fout een concrete vraag voor wie het volgende stuk bezit.

Begin bij het profiel en de EAP-methode

Open de eigenschappen van de verbinding en lees welke EAP-methode het profiel werkelijk gebruikt, en lees daarna welk certificaat de methode is geconfigureerd om te selecteren. Veel implementaties hebben zowel een op certificaten gebaseerde buitenste methode als een binnenste methode, en een certificaat dat op verbindingsniveau is geconfigureerd is niet automatisch het certificaat dat binnen EAP-TLS wordt aangeboden. Als het profiel een certificaat kiest op basis van uitgever of van een onderwerpsfilter, selecteert dat filter uit wat Windows in het relevante archief kan zien, niet uit wat de kaart toevallig bevat. Een filter dat niets vindt, valt terug op een prompt of op een stille fout, afhankelijk van de configuratie van het profiel, en daarom is het de moeite waard de gekozen vingerafdruk vast te leggen vóór elke wijziging.

Stel ook vast of de verbinding als de aangemelde gebruiker of als de machine draait. Dat ene feit bepaalt welke certificaatarchieven binnen bereik zijn en welke beveiligingscontext de handtekening zet.

Bevestig welk certificaat is geselecteerd

Vergelijk de vingerafdruk die Windows koos met de eis: gebruik voor clientauthenticatie, een keten die eindigt in een vertrouwde root, een identiteit die het beleid van de authenticatieserver toewijst, en een geldigheidsperiode die het werkelijke moment van de poging dekt. Dat zijn afzonderlijke controles en de laatste vangt meer verrassingen dan mensen verwachten, vooral bij certificaten die roulerend worden uitgegeven en gecachte profielen die nog naar de selectie van gisteren wijzen.

Gebruikers- en machinecontext is de andere helft van de controle. Een certificaat in de persoonlijke opslag van de gebruiker is onzichtbaar voor een service die als de machine draait, en een machinecertificaat wordt niet door een EAP-uitwisseling in gebruikersmodus aangeboden tenzij het profiel dat zegt. Een certificaat opnieuw importeren in de verkeerde opslag levert een zichtbaar certificaat en een onzichtbare aanmeldingsreferentie op. Lees het opslagpad in het profiel, niet dat in het dialoogvenster dat toevallig openging.

Test de sleutelbewerking zonder de pincode te raden

Zodra de selectie vaststaat, is de vraag of de kaart de handtekening zal zetten. Windows heeft een ondersteunde kaartprovider of minidriver nodig om de privésleutel te bereiken, en het apparaat past zijn eigen pincode- en aanwezigheidsregels toe op de bewerking. Een kaart die voor elke handtekening een aanraking vereist, gedraagt zich anders dan een kaart die een verificatie voor een sessie cachet, en beide zijn legitieme configuraties die veranderen wanneer een prompt verschijnt. Dat verschil verklaart een aanmelding die slaagt bij een verse invoer en mislukt na een hervatting, zonder dat er een certificaat fout is.

certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'

De eerste opdracht inventariseert de kaart en rapporteert de status van lezer en provider, wat is gedocumenteerd in Microsofts richtlijnen voor het debuggen van smartcards. De tweede somt op wat de gebruikerscontext werkelijk kan zien. Geen van beide bewijst een geslaagde authenticatie; beide vernauwen waar het stopte.

Raad de pincode niet. Kaarten handhaven limieten voor nieuwe pogingen, en een paar optimistische pogingen veranderen een rechtenprobleem in een geblokkeerde referentie die administratief herstel vereist. Als een lokale handtekening mislukt, leg dan de status van de provider en de toestand van de kaart vast in plaats van varianten te proberen. Herhaal de poging één keer met hetzelfde profiel, hetzelfde certificaat en een bekend goed lezerpad, en vergelijk daarna de twee registraties; meerdere variabelen tegelijk wijzigen levert een verhaal op in plaats van een resultaat.

Lees beide kanten van de handshake

Een voltooide handtekening is nog geen toegang. De authenticatieserver moet de keten accepteren, de intrekking controleren, de identiteit volgens haar huidige regels toewijzen en het verzoek autoriseren; de client moet op zijn beurt het certificaat van de server valideren zoals het profiel vereist. Een TLS-waarschuwing van de server ziet er in het log van de client identiek uit aan een die lokaal is gegenereerd, en daarom is de kant die hem uitzendt belangrijker dan de tekst van de waarschuwing.

Verzamel de Windows-gebeurtenissen en de gebeurtenissen aan de serverzijde met uitgelijnde tijdstempels, en bepaal daarna welke kant de eerste fout produceerde. RFC 5216 beschrijft de stap waarbij bewijs van bezit wordt geleverd in EAP-TLS, en een algemene handshake-waarschuwing noemt op zichzelf geen lokale sleuteloorzaak. De vergelijking van tijdstempels is wat twee logs in een reeks verandert.

Houd de grenzen recht in het rapport

Schrijf het rapport als vier fasen met elk één oordeel: welk profiel en welke context liepen, welk certificaat Windows selecteerde, of de kaart ondertekende, en wat de server besloot. Die structuur maakt de volgende stap voor de hand liggend en voorkomt de gangbare reparatie waarbij validatie wordt uitgeschakeld om een fase te passeren die niemand heeft geïdentificeerd.

Een softwarecertificaat als tijdelijke vergelijking is een legitieme beheerderstest, maar het verandert het referentie- en assurancemodel, dus het hoort in een goedgekeurde wijziging en niet in een stille productie-omweg. Dezelfde discipline geldt voor pincodepogingen en voor het opnieuw uitgeven van referenties voordat de falende fase bekend is. Een vervangende kaart die identiek faalt is duur bewijs dat het probleem nooit op de kaart zat.