Ou P12 misluk op OpenSSL 3: verkeerde wagwoord of verouderde syfer?

Die invoerdialoog neem jou wagwoord, draai 'n oomblik en sê dan dat dit die bundel nie kan lees nie. Niks in daardie boodskap sê vir jou of jy die wagfrase verkeerd getik het of of die lêer met 'n syfer verseël is wat die kliënt nie meer lewer nie. Dit is twee verskillende foute met verskillende regstellings, en die verkeerde keuse lei tot 'n afgradering van die kliënt wat die besluit net uitstel. Deur te kyk by watter stap die kliënt stop, skei jy hulle binne omtrent 'n minuut.

Wat gebeur tussen die dialoog en die sertifikaatlys

'n .p12-lêer is 'n houer, nie 'n sertifikaat nie. Binne is een of meer sertifikaatsakke en 'n privaatsleutelsak wat met 'n sleutel versleutel is wat van jou wagwoord afgelei word, plus 'n integriteitskontrole wat 'n MAC genoem word oor die hele lêer. Om dit oop te maak beteken om daardie MAC te verifieer, die sleutelsak te ontsleutel en die sertifikaat by die sleutel te pas wat daaruit kom.

Wagwoordprobleme kom by die MAC-stap. Syferprobleme kom later, wanneer die sleutelsak oopgemaak moet word en die bou wat dit doen geen implementering het vir die algoritme wat in die lêer genoem word nie.

Die tweede geval is algemeen op huidige stelsels omdat OpenSSL 3 'n groep ou algoritmes na 'n opsionele legacy-verskaffer verskuif het. Bundels wat deur OpenSSL 1.x uitgevoer is, het die sertifikate gewoonlik met 40-bis RC2 verseël en die privaatsleutel met drie-sleutel Triple DES. 'n Standaard OpenSSL 3-bou verifieer steeds die MAC met jou korrekte wagwoord en misluk dan op die sak, so die wagwoord was nooit verkeerd nie en om dit weer te tik verander niks.

Lees die houer sonder om 'n sleutel uit te skryf

Vra die OpenSSL-bou op jou eie masjien om die lêer te ontleed en te lees waar dit tou opgooi. 'n Inspeksie sonder 'n uitleerlêer laat die sleutel versleutel op die skyf, en dit is die enigste rede waarom hierdie stap veilig is om op 'n gedeelde gasheer te loop.

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

Op 'n legacy-bundel met die korrekte wagwoord druk dit sak-eienskappe en stop dan met digital envelope routines::unsupported. Met 'n verkeerde wagwoord kry jy Mac verify error: invalid password? voordat enige sak gelees word. Die twee boodskappe wys in teenoorgestelde rigtings, en dit is presies die inligting wat die kliënt weerhou het.

As die fout die een met die onondersteunde algoritme is, loop dieselfde opdrag weer met -legacy bygevoeg en niks anders verander nie. Daardie vlag laai die legacy-verskaffer vir daardie enkele proses. Dit maak nie dat die VPN-kliënt ou bundels ontleed nie, dit raak nie die stelselwye kriptobeleid nie, en dit is 'n meting eerder as 'n herstel, want die lêer moet steeds vervang word.

Watter fout beteken watter stap

'n Kort tabel hou die drie uitkomste uitmekaar, en die bewoording maak meer saak as waar die dialoog verskyn het.

Teks soos not enough data of header too long hoort by nie een van die eerste twee groepe nie. Dit is 'n formaatprobleem: 'n DER-lêer wat na .pem hernoem is, 'n kopie wat deur 'n redigeerder vermink is wat reëindes herskryf het, of 'n onvolledige aflaai. Vergelyk die kontrolesom met die een wat die uitreiker gestuur het voordat jy na syfers begin kyk.

Behandel Mac verify error as bewys oor net die wagwoord. Dit beteken die MAC wat uit jou inskrywing bereken is, stem nie ooreen met die gestoorde waarde nie, wat gebeur met 'n tikfout, met 'n wagwoord wat van 'n vroeëre invoer gekas is, of met 'n lêer wat onder 'n ander wagfrase weer uitgevoer is. Dit sê niks oor of die algoritmes binne oud is nie.

Bou 'n bundel wat die kliënt werklik kan oopmaak

Sodra die legacy-ontleder bevestig dat die lêer gesond is, is die blywende oplossing 'n vervanging waarvan die algoritmes deur die teikenkliënt ondersteun word: AES-256-CBC vir die sleutel- en sertifikaatsakke, PBKDF2 met SHA-256 vir afleiding, en SHA-256 vir die MAC. Jou PKI-administrateur kan dit uit dieselfde sleutelmateriaal uitvoer, en die sertifikaat binne bly die een wat jou bedieners reeds vertrou.

Wanneer jy plaaslik moet omskakel, vra die pkcs12-gereedskap om die sakke weer te verseël eerder as om hulle eers te dump. Hou albei wagfrases uit jou skulpgeskiedenis deur hulle uit 'n lêer te lees.

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

'n Suksesvolle omskakeling sê niks oor vervaldatum, sleutelgebruik, die privaatsleutel-passing of of die bediener die uitreikketting vertrou nie. Herverpakking is 'n vervoerverandering, nie 'n hernuwing nie, en elkeen van daardie dinge het steeds sy eie kontrole nodig.

Slaan enige resep oor wat 'n onbeskermde tussenliggende sleutel skryf of 'n leë uitsetwagwoord, net omdat die kliënt die lêer daarna aanvaar het. 'n Leesbare bundel met die beskerming gestroop is 'n slegter uitkoms as die invoerfout waarmee jy begin het.

Bevestig dat die kliënt die lêer ingevoer het wat jy gebou het

'n Skoon ontleding in 'n terminaal bewys die houer is geldig. Dit bewys nie die kliënt het dit gekies nie, want 'n oorblywende profiel kan aanhou na die ou lêer wys, en sommige kliënte kas 'n ingevoerde identiteit onder 'n naam wat jy nie gekies het nie.

Druk die identiteit wat jy op die punt staan om in te voer en vergelyk dit met wat die kliënt in sy sertifikaataansig wys.

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

Verwyder eers die verouderde profielinskrywing en voer dan in. As die kliënt die onderwerp of vingerafdruk log wat dit gelaai het, pas dit by die reël hierbo; as dit net 'n vriendelike naam wys, kyk eerder na die vervaldatum, want dit is moeiliker om met 'n ander sertifikaat van dieselfde uitreiker te verwar.

Die PKCS12-verwysing lys die verskaffer-, wagfrase- en uitsetopsies wat hier gebruik word. Om die legacy-verskaffer uit die kliëntomgewing te hou is die punt: meet daarmee, lewer daarsonder, en laat die privaatsleutel op die skyf beskerm.