Прежде чем конвертировать: ключ 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, регистрация становится следующим шагом, и этот разговор идёт гораздо быстрее с правильным существительным в первом предложении.