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

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

Почніть із того, що профіль уже містить

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

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

Перевірте поставлений пакет на файли, на які посилається профіль: сертифікат CA, іноді окремий сертифікат клієнта та ключ, а можливо, файл tls-auth або tls-crypt. Профіль, який посилається на чотири файли, а приходить із двома, неповний, і жодне вказування на поля це не виправить. Попросіть в оператора відсутню частину замість того, щоб підставляти сертифікат, який випадково у вас є.

Розділіть чотири види матеріалу

Сертифікат CA — публічний матеріал, який використовується для перевірки автентичності сервера. Сертифікат клієнта засвідчує користувача або пристрій перед сервером. Закритий ключ — секретна половина цього сертифіката клієнта, і він ніколи не повинен бути ключем підпису CA або серверним ключем. Матеріал tls-auth або tls-crypt — окремий спільний секрет, який захищає канал керування. Ці чотири не взаємозамінні, а спрямування поля CA на сертифікат клієнта дає помилку перевірки, яка виглядає як проблема довіри.

Автентифікація лише за паролем змінює те, який із чотирьох вам потрібен, а не їхній зміст. З auth-user-pass і remote-cert-tls server клієнт і далі перевіряє сервер за CA, тому поле CA з'являється навіть тоді, коли сертифіката клієнта немає. Політика оператора вирішує, чи потрібен також сертифікат клієнта, і жоден діалог не може вам це сказати.

Спрямуйте клієнт на файл довіри

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

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

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

Читайте наступну помилку, а не ту саму

Сенс правильного CA у тому, щоб змінити помилку, а не змусити її зникнути. Збій ідентичності сервера після завантаження CA означає, що сертифікат не збігся з очікуваним ім'ям або очікуванням remote-cert-tls, і це інше виправлення, ніж відмова в паролі. Відмова в паролі означає, що рівень TLS пройшов, а облікові дані неправильні. Збережіть перше нове повідомлення; саме воно корисне.

Клієнт, який підключається, але нікуди не потрапляє, повністю пройшов повз довіру і тепер стикається з питанням маршрутизації або DNS.

Ніколи не вимикайте перевірку, щоб пройти цей діалог. Клієнтові, який приймає будь-який сертифікат, немає сенсу запитувати CA, і тунель, який він будує, — не той, що задумав оператор.

Схожі статті