Почему 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 — это отдельные результаты, и именно их разделение не позволяет ограничению фронтенда превратиться в ослабленную политику сертификатов.