Старий 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 поза середовищем клієнта і є суттю: вимірюйте з ним, постачайте без нього й залишайте закритий ключ захищеним на диску.