Чому OpenConnect відхиляє шлюз після заміни сертифіката?

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

Прочитайте збій, перш ніж змінювати будь-яке налаштування довіри

Помилка виду «відсутній підписувач» означає, що ланцюг закінчується на чомусь, чого клієнт не приймає. Це може бути оновлений сертифікат внутрішнього центру, заміна від публічного центру або пристрій посередині, що пред'являє власний сертифікат. Лише формулювання не може розрізнити ці випадки, тому подивіться на видавця, перш ніж вирішувати.

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

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

Виберіть між довірою видавцеві та закріпленням одного ключа

Обидва варіанти дають змогу з'єднанню працювати. Пізніше вони ламаються протилежними способами, тож вибір належить збою, який ви можете витримати.

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

Хоч би що ви обрали, довірене значення має надійти каналом, якому довіряли до зміни. Адміністратор, консольна сесія на шлюзі або заздалегідь знята копія — усі підходять. Копіювання будь-якого відбитка, який показує запит, зручне і є саме тим, на що сподівається перехоплювач.

Помістіть значення в команду, яку ви справді запускаєте

Закріплення передається в параметрі сертифіката сервера, і його префікс визначає кодування: шістнадцяткові дайджести відкритого ключа під sha1 або sha256 та закріплення ключа в base64 під pin-sha256. Його надання також вимикає системну довіру для цього запуску, тож закріплений ключ стає всім рішенням.

sudo openconnect --protocol=gp vpn.example.com --user alice \
  --servercert pin-sha256:AbCdEf...   # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trust

Клієнт зіставляє урізаний дайджест, приймаючи лише чотири символи після префікса, що є пастка, а не зручність. Скорочене значення проходить локально і все одно не ідентифікує потрібний шлюз. Скопіюйте повний рядок, який клієнт надрукував у першій спробі, замість того щоб передруковувати його з повідомлення. Потім перенесіть готовий параметр у скрипт-обгортку, unit-файл або профіль, що запускає з'єднання, щоб рішення про довіру можна було переглянути, а пізніші правки були свідомими.

Робочі стільниці та плагін NetworkManager зберігають власну копію аргументів з'єднання. Скрипт, відредагований на диску, не досягає профілю, імпортованого раніше, тож збережене значення далі перемагає.

Обробіть перехід, не замкнувши себе зовні

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

Напишіть дату зміни поряд із закріпленням. Закріплення без дати перегляду — це майбутній збій із заплутаним повідомленням про помилку.

Виключіть версію клієнта, перш ніж редагувати довіру

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

openconnect --version

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