Сертификат шлюза в порядке: почему вход IKEv2 PEAP всё равно не удаётся

Сертификат вашего VPN-шлюза действителен, цепочка проверяется, а клиент IKEv2 всё равно отказывает во входе с сообщением об интервале действия сертификата. Первый порыв — перевыпустить сертификат шлюза или сменить метод EAP, и оба варианта обычно неверны. Попытка входа несёт две отдельные сущности сервера: сертификат шлюза, который использует IKE, и сертификат, который предъявляет тот, кто завершает PEAP. Одна из них в порядке, а другая — причина, по которой клиент остановился.

Две сущности, одна попытка входа

Сертификат в профиле VPN относится к обмену IKE: он доказывает, что шлюз — та сторона, которую называет профиль, согласно настроенной политике IKE. Сертификат, который здесь не проходит, относится к другому разговору, сессии TLS, которую PEAP открывает с тем, кто аутентифицирует пользователя, а это часто сервер RADIUS вроде NPS, а не сам шлюз. Третья проверка, учётные данные пользователя, происходит внутри этой сессии. Верный пароль не может исправить просроченный серверный сертификат, а действительный сертификат шлюза не может поручиться за конечную точку PEAP.

Такая слоистость объясняет, почему ошибка сертификата появляется там, где единственным настроенным сертификатом был сертификат шлюза. Она же объясняет, почему перевыпуск этого сертификата ничего не меняет.

Читайте строку журнала относительно этапа

Найдите сообщение, в котором названы причина и даты. Жалоба на интервал действия рядом с ошибкой субъекта означает, что сервер отклонил выданный ему сертификат, а не то, что пользователь отклонил вход. Затем определите этап: журнал charon в strongSwan показывает IKE_SA .* established до начала обмена EAP, поэтому ошибка сертификата после этой строки относится к сущности EAP, а ошибка до неё указывает на шлюз. Текст этапа на панели подключения клиента Windows говорит то же самое.

Проверьте часы клиента, прежде чем трогать любой сертификат. Устройство с расхождением в несколько часов даёт ту же ошибку действия, что и действительно просроченный сертификат. Сброс часов — это пятисекундная правка, а замена сертификата, который никогда не был проблемой, — это простой.

Определите, какая конечная точка завершает PEAP

В схеме «шлюз плюс RADIUS» шлюз пересылает EAP и не завершает его. Плагин eap-radius в strongSwan передаёт обмен серверу RADIUS, которому принадлежат сессия TLS PEAP и её сертификат. Сопоставьте одну неудачную попытку в обоих журналах и подтвердите, какой процесс действительно выбрал сертификат для этой сессии.

Для NPS сертификат должен находиться в хранилище локального компьютера, нести назначение проверки подлинности сервера, совпадать с именем, которого ждут клиенты, и быть читаемым для служебной учётной записи. Требования Microsoft к сертификатам для NPS перечисляют эти условия. У других серверов EAP свои правила выбора, поэтому не копируйте особенности NPS в развёртывание FreeRADIUS и наоборот. Правило, которое сохраняется в обоих случаях: конечная точка, завершающая PEAP, владеет сертификатом, который вы собираетесь менять.

Замените сертификат там, где завершается EAP

Обновите или замените сертификат на конечной точке, которая завершает PEAP, с помощью поддерживаемой процедуры, сохранив назначение проверки подлинности сервера и ожидаемое имя. Установите полную цепочку там, где служба её ищет, и дайте службе доступ к закрытому ключу. Перезапустите или перепривяжите службу, потому что многие службы держат старый сертификат в памяти и продолжают его предъявлять. Файл, скопированный на машину, ничего не доказывает о том, какой сертификат служба фактически предъявляет.

Подтвердите изменение, сопоставив следующую попытку с собственным журналом службы или проверив сертификат, который предъявила сессия. Если в этом журнале всё ещё старый отпечаток, перезапуск не сработал.

Не думайте, что самый новый файл в каталоге — тот, который используется. Копия с правильным именем и неверными правами ничего не меняет. Судите об изменении по предъявленной сущности, а не по отметке времени файла.

Чего не делать

Не отключайте проверку PEAP и не навязывайте более слабый внутренний метод, чтобы обойти ошибку. Это меняет политику и убирает свойство проверки подлинности сервера, которое и поймало просроченный сертификат. Вы обменяли бы работающую проверку на работающее соединение, а следующий просроченный сертификат пришёл бы без ничего, что о нём возвестило бы.

Не считайте успешное подключение из другой операционной системы доказательством того, что сертификат приемлем. Тот клиент может использовать другой метод EAP, другое хранилище доверия или вообще без проверки сервера, поэтому его успех ничего не говорит о проверке, которая здесь не прошла. Держите один намеренный негативный тест, например сертификат с неверным именем или недоверенную цепочку, который не проходит, как и ожидается. Если этот тест теперь проходит, вы убрали проверку, а не исправили сертификат. Запишите, какая сущность не прошла, чтобы следующий человек не начинал снова с сертификата шлюза.