Стариот 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 надвор од опкружувањето на клиентот е поентата: мерете со него, испорачувајте без него и оставете го приватниот клуч заштитен на дискот.