Вход с 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 и за преиздаването на данни за достъп, преди да е известен провалилият се етап. Резервна карта, която се проваля по идентичен начин, е скъпо доказателство, че проблемът никога не е бил в картата.