У профілі OpenVPN три блоки сертифікатів: який із них секретний?

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

Один файл, три блоки, різні завдання

Типовий профіль вбудовує блок ca, блок cert і блок key між маркерами BEGIN і END або вказує на ті самі три як на окремі файли. Деякі профілі додають четвертий блок для ключа tls-auth або tls-crypt, який є спільним секретом, а не сертифікатом. Клієнт читає кожен блок згідно з директивою, що його називає, тому позначки важливіші за порядок появи.

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

Директиви навколо блоків визначають, як їх використовують. Змініть ca — і клієнт довіряє іншому центру; змініть cert, не змінюючи key, — і рукостискання зривається через невідповідність, що не має нічого спільного з довірою.

Блок CA відкритий, ключ CA — ніколи

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

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

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

Серверний і клієнтський сертифікати спрямовані в протилежні боки

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

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

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

Два запити, які виглядають однаково й такими не є

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

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

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

Що доводить чисте рукостискання, а що — ні

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

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