Перш ніж конвертувати: ключ SSH чи сертифікат OpenVPN

Імпорт завершується помилкою сертифіката, тому очевидний крок виглядає як конвертація. Цей інстинкт веде людей шляхом, де розширення файлу змінюється, а відмова залишається точно такою ж. Рядок ssh-ed25519 у authorized_keys і клієнтський сертифікат OpenVPN — окремі об’єкти облікових даних, з різними видавцями, різними кодуваннями та різними шляхами відкликання. Якщо пройти ці перевірки по черзі, за хвилину стане зрозуміло, чи може конвертація взагалі допомогти.

Який об’єкт у вас насправді?

Є п’ять речей, які люди називають ключем, і лише одна з них — те, що потрібно профілю TLS. Відкритий ключ SSH — це один рядок тексту з префіксом типу та корисним навантаженням base64. Сертифікат OpenSSH — це той самий ключ плюс підпис, principals і параметри, які створює ssh-keygen, виступаючи як власний маленький CA. Сертифікат X.509 — зовсім інша структура: він несе суб’єкт, вікно дії, розширення та підпис від центру сертифікації. Закритий ключ — це секретна половина, а виданий пакет зазвичай є сертифікатом плюс його ланцюжок плюс закритий ключ в одному файлі.

Перша перевірка коштує однієї команди. Спрямуйте openssl на файл і попросіть розібрати структуру сертифіката:

openssl x509 -in client.crt -noout -subject -issuer

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

Профіль узагалі вимагає сертифікат?

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

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

Що перекодування може і чого не може

Закриті ключі справді мають законні альтернативні контейнери. Той самий ключ RSA або EC можна записати як традиційний PEM, як PKCS#8 або всередині пакета PKCS#12, і інструменти охоче конвертують між ними. Відкриті ключі мають схожу історію: ssh-keygen може вивести форму RFC 4716 ключа SSH, а OpenSSH розуміє і власний формат сертифіката. Усе це — подання, а подання не є довірою.

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

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

Де в картину входить центр сертифікації

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

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

Чого вам коштує повторне використання ключа SSH

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

Тому контрольний список закінчується умовою зупинки, а не трюком. Якщо openssl не розбирає файл як сертифікат, припиніть конвертацію і опишіть, що у вас є: ключ SSH, сертифікат SSH, сертифікат X.509, закритий ключ або пакет. Якщо профіль не вимагає клієнтського сертифіката, зупиніться і запитайте, якого методу автентифікації очікує сервер. Лише коли обидві відповіді вказують на X.509, реєстрація стає наступним кроком, і ця розмова йде значно швидше з правильним іменником у першому реченні.