Стари P12 не ради у OpenSSL 3: погрешна лозинка или стари шифра?
Разликујте погрешно откуцану лозинку од старог RC2 пакета који 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 клијент да раставља старе пакете, не дира системску крипто политику и представља мерење, а не поправку, јер датотека и даље мора да се замени.
Која грешка значи која фаза
Кратка табела раздваја три исхода, а формулација је важнија од места на ком се дијалог појавио.
| Text you see | Stage | What it tells you |
|---|---|---|
Mac verify error: invalid password? | Integrity check | Passphrase or cached credential, not the cipher |
digital envelope routines::unsupported | Bag decrypt | Algorithm missing from the default provider |
not enough data / header too long | Container format | Wrong encoding, edited file, or truncated download |
Текст као 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-а ван клијентског окружења је поента: мерите са њим, испоручујте без њега и оставите приватни кључ заштићен на диску.