Вход по 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 и к перевыпуску учётных данных до того, как известен сбойный этап. Заменяющая карта, которая срывается так же, — дорогое доказательство того, что проблема никогда не была на карте.