Чому cryptoapicert не працює в OpenVPN 3 і Connect під Windows

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

У цьому звіті змішуються три шари: клієнт Community, основна бібліотека і фронтенд, який хтось установив. Лише один із них колись розумів цю директиву.

Що означає ця опція там, де вона існує

У клієнті Community OpenVPN 2 під Windows cryptoapicert позначає сертифікат, який клієнт має знайти в сховищі сертифікатів Windows, а не у файлі. Це зручність, специфічна для Windows, і вона працює, бо цей клієнт уміє перелічити сховище й передати отриманий ключ своєму стеку TLS. Тому директива є частиною мови конфігурації цього клієнта, а не властивістю протоколу OpenVPN. Ніщо у форматі передавання її не несе.

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

Що натомість надає основна бібліотека

OpenVPN 3 Core — це бібліотека, яку вбудовують інші програми, і вона обробляє зовнішні облікові дані через API, а не через пошук у сховищі. Вбудовувана програма надає ланцюжок сертифікатів і згодом просить бібліотеку підписати зовнішнім ключем, і бібліотека для цього викликає програму назад. Це загальніший дизайн, і він означає, що фронтенд вирішує, які постачальники існують. У власній обробці опцій бібліотеки cryptoapicert з'являється серед директив, які не реалізовано, що узгоджується з таким розподілом відповідальності.

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

Що натомість робить фронтенд Windows

OpenVPN Connect іде іншим шляхом: оператор імпортує файл PKCS#12 із сертифікатом і його приватним ключем у OpenVPN Certificate Store, створене для цієї мети, а потім призначає зовнішній сертифікат профілю. Це навмисний крок імпорту, а не автоматичне виявлення того, що випадково лежить в особистому сховищі. Різниця важлива, коли хтось припускає, що сертифікат, установлений для іншої мети, просто з'явиться в списку клієнта.

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

Виберіть шлях, що відповідає політиці ключа

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

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

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