Старый P12 не работает в OpenSSL 3: неверный пароль или устаревший шифр?

Диалог импорта принимает пароль, крутится мгновение, а затем сообщает, что не может прочитать пакет. Ничто в этом сообщении не говорит, ошиблись ли вы в парольной фразе или файл запечатан шифром, который клиент больше не поставляет. Это разные сбои с разными исправлениями, и неверный выбор ведёт к откату клиента, который лишь откладывает решение. Наблюдение за тем, на каком этапе клиент останавливается, разделяет их примерно за минуту.

Что происходит между диалогом и списком сертификатов

Файл .p12 — это контейнер, а не сертификат. Внутри находятся один или несколько мешков с сертификатами и мешок закрытого ключа, зашифрованный ключом, производным от вашего пароля, а также проверка целостности под названием MAC по всему файлу. Открыть его — значит проверить этот MAC, расшифровать мешок ключа и сопоставить сертификат с полученным ключом.

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

Второй случай часто встречается в современных системах, потому что OpenSSL 3 перенёс группу старых алгоритмов в необязательный legacy provider. Пакеты, экспортированные OpenSSL 1.x, обычно запечатывали сертификаты 40-битным RC2, а закрытый ключ — трёхключевым Triple DES. Стандартная сборка OpenSSL 3 всё равно проверяет MAC с правильным паролем, а затем терпит неудачу на мешке, поэтому пароль никогда не был неверным и повторный ввод ничего не меняет.

Прочитайте контейнер, не выводя ключ

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

openssl pkcs12 -in vpn-identity.p12 -info -noout

На старом пакете с правильным паролем это печатает атрибуты мешка и затем останавливается с digital envelope routines::unsupported. С неверным паролем вы получите Mac verify error: invalid password? ещё до чтения любого мешка. Оба сообщения указывают в противоположные стороны, и именно эту информацию клиент скрыл.

Если сбой связан с неподдерживаемым алгоритмом, запустите ту же команду ещё раз, добавив -legacy и не меняя ничего другого. Этот флаг загружает legacy provider только для одного этого процесса. Он не заставляет VPN-клиент разбирать старые пакеты, не затрагивает общесистемную криптополитику и является измерением, а не ремонтом, потому что файл всё равно нужно заменить.

Какая ошибка означает какой этап

Короткая таблица разделяет три исхода, и формулировка важнее того, где появился диалог.

Текст вроде not enough data или header too long не относится ни к одной из первых двух групп. Это проблема формата: файл DER, переименованный в .pem, копия, испорченная редактором, переписавшим окончания строк, или неполная загрузка. Сравните контрольную сумму с той, что прислал издатель, прежде чем смотреть на шифры.

Воспринимайте Mac verify error только как свидетельство о пароле. Это значит, что MAC, вычисленный из введённого, не совпадает с сохранённым значением, что бывает при опечатке, при пароле из кэша прошлого импорта или при файле, повторно экспортированном с другой парольной фразой. Он ничего не говорит о том, стары ли алгоритмы внутри.

Соберите пакет, который клиент действительно откроет

Когда legacy-анализатор подтвердит, что файл в порядке, долговременное решение — замена, алгоритмы которой поддерживает целевой клиент: AES-256-CBC для мешков ключа и сертификатов, PBKDF2 с SHA-256 для вывода и SHA-256 для MAC. Ваш администратор PKI может экспортировать это из того же ключевого материала, а сертификат внутри останется тем, которому ваши серверы уже доверяют.

Когда нужно конвертировать локально, попросите утилиту pkcs12 заново запечатать мешки вместо того, чтобы сначала их выгружать. Держите обе парольные фразы вне истории оболочки, читая их из файла.

openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
  -keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
  -passin file:old.pass -passout file:new.pass

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

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

Убедитесь, что клиент импортировал созданный вами файл

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

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

openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
  | openssl x509 -noout -subject -dates -fingerprint -sha256

Сначала удалите устаревшую запись профиля, затем импортируйте. Если клиент записывает в журнал загруженный субъект или отпечаток, сопоставьте его со строкой выше; если он показывает только понятное имя, проверьте вместо этого дату истечения, потому что её труднее спутать с другим сертификатом того же издателя.

Справочник PKCS12 перечисляет provider, парольную фразу и параметры вывода, использованные здесь. Держать legacy provider вне окружения клиента и есть суть: измеряйте с ним, поставляйте без него и оставляйте закрытый ключ защищённым на диске.