Самопідписаний сертифікат клієнта? VPN-сервер усе одно його відхиляє

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

Довіра живе на сервері, а не у вашому профілі

Автентифікація сертифікатом — це порівняння. Клієнт подає сертифікат; шлюз перевіряє, чи підписаний він однією з CA у його конфігурації.

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

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

Чому самопідписаний сертифікат не може його замінити

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

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

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

Шлях через CSR зберігає ваш закритий ключ

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

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

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

Керовані сервіси часто пропускають CSR і видають весь пакет. Це розумний обмін, коли той самий провайдер уже завершує тунель і володіє CA. Зберігання ключа не покращується від того, що ви його тримаєте, бо провайдер може будь-коли створити новий.

Пакети імпортуються, а не встановлюються

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

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

Додайте перевірки, які оператор міг пропустити

У профілі, створеному маршрутизатором, іноді немає перевірки партнера. remote-cert-tls server вимагає, щоб сертифікат партнера ніс призначення автентифікації сервера, тому сертифікат клієнта не можна відтворити як сервер. Цей один рядок — невелика зміна з ясним обґрунтуванням.

verify-x509-name іде далі, коли оператор може назвати очікуваний суб'єкт або SAN. Обидва — невеликі доповнення до профілю, і обидва виправдані. Перевірте, що ви отримали, перш ніж імпортувати.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

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

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