Це повідомлення про сертифікат Wi-Fi не є новим кореневим центром сертифікації

Діалог з’являється, коли ви приєднуєтеся до університетської або офісної мережі, згадує сертифікат і пропонує кнопку з написом довіряти або продовжити. За цією кнопкою ховаються дві дуже різні зміни. Одна вчить клієнт Wi-Fi, який сервер автентифікації приймати для цієї однієї мережі. Інша встановлює центр сертифікації, який інші застосунки потім можуть використовувати. Текст на екрані — єдина підказка, яку ви отримуєте, тож прочитайте його, перш ніж торкатися.

Крок 1: прочитайте, що насправді запитує діалог

Шукайте три речі: показане ім’я сервера, названого видавця та чи дію описано як довіру серверу для цього з’єднання чи як встановлення сертифіката на пристрої. Це різні об’єкти, і підказка, яка не каже, який із них ви схвалюєте, варта паузи.

Не схвалюйте жодного варіанта лише тому, що назва мережі здається знайомою. SSID обирає той, хто керує точкою доступу, а назва на captive порталі не є доказом щодо сервера автентифікації за нею. Будь-хто з точкою доступу може транслювати переконливий SSID. Саме тому перевірка сертифіката й існує.

Що доводить сертифікат сервера 802.1X

У розгортанні 802.1X із сертифікатами supplicant пристрою під час переговорів перевіряє сервер автентифікації. Посібник Apple з розгортання 802.1X описує сервер RADIUS, що подає свій сертифікат, і рішення про довіру, яке належить цій службі.

Остання частина — це вся суть. Сертифікат, виданий відомим центром сертифікації, доводить, що видавець його підписав, а не те, що цей конкретний сервер належить установі, до якої ви, на вашу думку, приєдналися. Довіра, обмежена призначенням, існує саме тому, що друге питання є тим, яке має значення.

Підтримувані конфігурації можуть обмежувати довіру вибраними сертифікатами сервера або очікуваними іменами сервера. Тому установи розповсюджують перевірений профіль Wi-Fi, замість того щоб казати користувачам приймати перший-ліпший сертифікат, і тому підказка без очікуваного імені — погане місце для ухвалення рішення.

Крок 2: перевірте, чи не встановлено ширший орган

Центр сертифікації, якому довіряє браузер або операційна система, сягає значно далі, ніж сертифікат сервера Wi-Fi, прийнятий для однієї мережі. Визначте об’єкт, сховище, до якого він потрапив, призначення, для якого він дозволений, і які застосунки звертаються до цього сховища.

Пакет конфігурації може містити кілька налаштувань одразу, тож перегляньте вміст, а не довіряйте Wi-Fi етикетці інсталятора. Етикетка описує завдання, не обов’язково все, що робить вміст.

Навіть широкий корінь не доводить, що кожна сесія HTTPS перевіряється. Перевірка потребує відповідного шляху трафіку й сертифіката сервера, який застосунок приймає за своєю реальною політикою валідації, а застосунки можуть використовувати різні сховища довіри з додатковими перевірками.

Крок 3: тримайте VPN поза рішенням про довіру

VPN захищає свій покритий шлях після того, як пристрій досягає партнера VPN. Він не видаляє встановлений корінь, не змінює рішень застосунку про довіру і не перевіряє за вас неочікуваний сервер автентифікації Wi-Fi.

Запитайте адміністратора про мережеву автентифікацію, керування пристроями та дозволену перевірку TLS як три окремі питання. Це не три назви однієї й тієї самої функції сертифіката, і відповідь підтримки, яка їх зливає, не скаже вам, яку зміну ви схвалили.

Крок 4: усуньте розбіжність, не зламавши все

Запишіть не-таємні дані з підказки: ім’я сервера, видавця та відбиток, якщо він показується. Порівняйте їх зі значеннями, які установа публікує для своєї мережі, і розбіжність сприймайте як питання до власника конфігурації, а не як щось, що можна проклацати.

Перегляньте встановлену конфігурацію через підтримувані налаштування платформи, щоб знати, що насправді діє. Видалення всіх сертифікатів на пристрої ламає не пов’язаний доступ, а прийняття невідомої заміни послаблює перевірку ідентичності, яку ви хотіли зберегти. Виправте конкретну розбіжність і залиште решту сховища довіри в спокої.