PIV најавата не успева на Windows EAP-TLS? Проверете ја патеката на потпишување

Прикажете го сертификатот на PIV картичката во секој дијалог на Windows, а најавата на VPN сепак може да не успее, бидејќи видливоста и употребливоста се различни својства. Сертификатот е јавен објект; најавата бара операција со приватен клуч што картичката ја извршува според сопствените правила за пристап. Помеѓу тие два факти стојат четири фази што не успеваат на четири различни начини: избор на профил, избор на сертификат, локално потпишување и валидација на страната на серверот. Поминувањето низ нив по редослед ја претвора општата грешка при ракување во конкретно прашање за оној што го поседува следниот дел.

Започнете со профилот и EAP методот

Отворете ги својствата на врската и прочитајте кој EAP метод профилот навистина го користи, потоа прочитајте кој сертификат методот е конфигуриран да го избере. Многу распоредувања имаат и надворешен метод заснован на сертификат и внатрешен метод, а сертификатот конфигуриран на ниво на врска не е автоматски тој што се претставува во EAP-TLS. Ако профилот избира сертификат според издавач или според филтер за субјект, тој филтер избира од она што Windows го гледа во релевантното складиште, а не од она што картичката случајно го содржи. Филтер што не совпаѓа ништо преминува на покана или на тивок неуспех, зависно од конфигурацијата на профилот, поради што избраниот отпечаток вреди да се запише пред каква било промена.

Исто така утврдете дали врската работи како најавен корисник или како машина. Тој единствен факт одредува кои складишта на сертификати се во опфат и кој безбедносен контекст го извршува потпишувањето.

Потврдете кој сертификат е избран

Споредете го отпечатокот што го избрал Windows со барањето: намена за автентикација на клиент, синџир што завршува во доверлив корен, идентитет што политиката на серверот за автентикација го мапира и период на важност што го покрива вистинскиот момент на обидот. Тоа се одделни проверки и последната фаќа повеќе изненадувања отколку што луѓето очекуваат, особено со сертификати издадени во тек и кеширани профили што сѐ уште покажуваат на вчерашниот избор.

Контекстот на корисник и машина е другата половина од проверката. Сертификат во личното складиште на корисникот е невидлив за услуга што работи како машина, а сертификат на машина не се претставува со EAP размена во кориснички режим, освен ако профилот не го кажува тоа. Повторното увезување на сертификат во погрешно складиште произведува видлив сертификат и невидлив пријавен акредитив. Читајте ја патеката на складиштето во профилот, не онаа во дијалогот што случајно се отворил.

Тестирајте ја операцијата со клучот без погодување на PIN-от

Откако изборот е решен, прашањето е дали картичката ќе го изврши потпишувањето. На Windows му треба поддржан провајдер за картичка или минидрајвер за да стигне до приватниот клуч, а уредот ги применува сопствените правила за PIN и присутност врз операцијата. Картичка конфигурирана да бара допир за секое потпишување се однесува поинаку од онаа што кешира верификација за сесија, и двете се легитимни конфигурации што менуваат кога се појавува покана. Таа разлика објаснува најава што успева при свежо вметнување и не успева по враќање од мирување, без ниту еден сертификат да е погрешен.

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

Првата команда ја инвентаризира картичката и ја пријавува состојбата на читачот и провајдерот, што е документирано во упатството на Microsoft за отстранување грешки кај паметни картички. Втората наведува што корисничкиот контекст навистина може да види. Ниту една не докажува успешна автентикација; двете го стеснуваат местото каде што запрела.

Не го погодувајте PIN-от. Картичките применуваат ограничувања за повторени обиди, а неколку оптимистички обиди претвораат проблем со дозволи во блокиран акредитив што бара административно обновување. Ако локалното потпишување не успее, забележете ја состојбата на провајдерот и на картичката наместо да пробувате варијанти. Повторете го обидот еднаш со истиот профил, истиот сертификат и позната добра патека на читач, потоа споредете ги двата записа; менувањето на неколку променливи одеднаш произведува приказна, а не резултат.

Прочитајте ги двете страни на ракувањето

Завршено потпишување сѐ уште не е прием. Серверот за автентикација мора да го прифати синџирот, да ја провери отповикувањето, да го мапира идентитетот според неговите тековни правила и да го одобри барањето; клиентот пак мора да го валидира сертификатот на серверот како што бара профилот. TLS предупредување генерирано од серверот изгледа идентично во дневникот на клиентот како она генерирано локално, поради што страната што го емитува е поважна од текстот на предупредувањето.

Соберете ги настаните од Windows и настаните од страната на серверот со усогласени временски ознаки, потоа утврдете која страна го произвела првиот неуспех. RFC 5216 го опишува чекорот за докажување на поседување во EAP-TLS, а општото предупредување при ракување само по себе не именува локална причина поврзана со клучот. Споредбата на временските ознаки е она што два дневника ги претвора во низа.

Држете ги границите јасни во извештајот

Напишете го извештајот како четири фази со една пресуда за секоја: кој профил и контекст работеле, кој сертификат го избрал Windows, дали картичката потпишала и што одлучил серверот. Таа структура го прави следниот чекор очигледен и го спречува вообичаениот поправак на исклучување на валидацијата за да се помине фаза што никој не ја идентификувал.

Софтверски сертификат како привремена споредба е легитимен администраторски тест, но тој го менува моделот на акредитив и гаранција, па припаѓа во одобрена промена, а не во тивок производствен обид. Истата дисциплина важи за обидите со PIN и за повторното издавање акредитиви пред да се знае фазата што не успева. Заменска картичка што не успева идентично е скап доказ дека проблемот никогаш не бил на картичката.