Стар P12 не работи с OpenSSL 3: грешна парола или остарял шифър?

Диалогът за импортиране приема паролата ви, завърта се за момент и след това казва, че не може да прочете пакета. Нищо в това съобщение не ви казва дали сте сбъркали паролата, или файлът е запечатан с шифър, който клиентът вече не доставя. Това са различни откази с различни поправки и грешният избор води до връщане към по-стара версия на клиента, което само отлага решението. Наблюдението на етапа, на който клиентът спира, ги разделя за около минута.

Какво се случва между диалога и списъка със сертификати

Файлът .p12 е контейнер, а не сертификат. Вътре има една или повече торби със сертификати и торба с частен ключ, криптирана с ключ, извлечен от паролата ви, плюс проверка за цялост, наречена MAC, върху целия файл. Отварянето му означава проверка на този MAC, декриптиране на торбата с ключа и съпоставяне на сертификата с ключа, който излиза от нея.

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

Вторият случай е често срещан на съвременните системи, защото OpenSSL 3 премести група стари алгоритми в незадължителен legacy доставчик. Пакетите, експортирани от 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 доставчика само за този процес. Той не кара 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 изброява използваните тук опции за доставчик, парола и изход. Смисълът е legacy доставчикът да остане извън средата на клиента: измервайте с него, доставяйте без него и оставете частния ключ защитен на диска.