Сертифікат шлюзу в порядку: чому вхід 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, інше сховище довіри або взагалі без перевірки сервера, тож його успіх нічого не каже про перевірку, яка тут не вдалася. Тримайте один навмисний негативний тест, наприклад сертифікат із хибним ім'ям або недовірений ланцюжок, який не проходить, як і очікується. Якщо цей тест тепер проходить, ви прибрали перевірку, а не виправили сертифікат. Запишіть, яка сутність не пройшла, щоб наступна людина не починала знову з сертифіката шлюзу.