Расширения файлов не определяют алгоритмы ключей, а оболочка .pem может содержать материал RSA или ECDSA. PEM описывает, как упакованы байты, тогда как RSA и ECDSA обозначают разные алгоритмы, а файл PKCS12 — это третье. strongSwan загружает учётные данные через плагины и конфигурационный backend, поэтому сертификат может появиться в списке, а закрытый ключ так и не станет пригодным к использованию. Разделите эти уровни, прежде чем править любой секрет.

Кодирование, алгоритм и упаковка — три уровня

Файл ключа имеет кодирование, алгоритм и часто контейнер. PEM — знакомая оболочка base64; DER — её двоичный аналог; PKCS12 объединяет сертификат с его ключом и цепочкой. Файл цепочки сертификатов — ещё один контейнер, и обычно он вовсе не содержит закрытого ключа. Ни одна из этих меток не говорит, что внутри — RSA или ECDSA.

Читайте алгоритм из самого объекта. Маркетинговое название поставщика или расширение файла не являются доказательством, потому что один и тот же издатель может выпускать разные типы ключей.

Сравните открытые ключи, прежде чем винить загрузчик

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

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

Вторая команда касается закрытого материала на вашей машине, но выводит только открытую половину. Оставьте так и никогда не вставляйте закрытый ключ в тикет. Если ключ зашифрован, позвольте поддерживаемому инструменту запросить пароль, а не помещать его в командную строку, где список процессов может его раскрыть.

Старые ipsec.secrets или учётные данные swanctl

У strongSwan есть два распространённых пути учётных данных. Старый стек starter читает записи, специфичные для типа, из ipsec.secrets, и каждая запись должна указывать правильный тип для материала. Стек swanctl и vici загружает ключи из собственного каталога учётных данных через собственную конфигурацию. Правка файла, который работающий backend не читает, ничего не меняет.

: ECDSA "/etc/ipsec.d/private/server-key.pem"

Выясните, какой backend действительно работает, затем поместите ключ туда, куда смотрит этот backend. старое руководство strongSwan 5.9 определяет записи секретов, специфичные для типа, и это не документация swanctl. Смешивание обоих порождает демон, который игнорирует файл, считающийся администратором авторитетным. Перезагрузка, не сообщающая об ошибке, означает лишь то, что конфигурация разобрана.

Читайте событие загрузки и результат аутентификации

После контролируемой перезагрузки прочитайте собственный вывод загрузки демона для конкретного ключа. Сертификат, указанный в дампе состояния, не показывает, что закрытый ключ был сопоставлен с ним.

Если клиент всё ещё терпит неудачу, держите событие сервера и ошибку клиента отдельно. Проверка цепочки, сопоставление идентичности и совместимость методов — это последующие вопросы с собственными доказательствами. Запишите результат с точным путём ключа и хешем, который вы сравнили, иначе следующая смена повторит ту же перезагрузку. Замена CA — не первая реакция на несоответствие загрузчика.

Похожие статьи