Ald P12 mislearret op OpenSSL 3: ferkeard wachtwurd of ferâldere sifer?

De ymportdialooch nimt jo wachtwurd, draait in momint en seit dan dat er de bondel net lêze kin. Neat yn dy melding fertelt jo oft jo it wachtwurd ferkeard yntype hawwe of oft it bestân fersegelle is mei in sifer dat de klant net mear leveret. Dat binne ferskate flaters mei ferskate oplossings, en de ferkearde kar liedt ta in delgong fan 'e klant dy't it beslút allinnich útstelt. Troch te sjen by hokker stap de klant stopet, skiede jo se yn sawat in minút.

Wat der bart tusken de dialooch en de sertifikaatlist

In .p12-bestân is in kontener, gjin sertifikaat. Binnenyn binne ien of mear sertifikaatsekken en in partikuliere-kaaisek fersegelle mei in kaai dy't fan jo wachtwurd ôflaat is, plus in yntegriteitskontrôle mei de namme MAC oer it hiele bestân. It iepenje betsjut dy MAC ferifiearje, de kaaisek ûntsiferje en it sertifikaat by de kaai passe dy't derút komt.

Wachtwurdproblemen komme by de MAC-stap. Siferproblemen komme letter, as de kaaisek útpakt wurde moat en de bou dy't dat docht gjin ymplemintaasje hat foar it algoritme dat yn it bestân neamd wurdt.

It twadde gefal is gewoan op hjoeddeiske systemen, om't OpenSSL 3 in groep âlde algoritmen nei in opsjonele legacy-leveransier ferpleatst hat. Bondels dy't troch OpenSSL 1.x eksportearre binne, fersegelen de sertifikaten meastentiids mei 40-bits RC2 en de partikuliere kaai mei trijekaaie Triple DES. In standert OpenSSL 3-bou ferifiearret noch altyd de MAC mei jo juste wachtwurd en mislearret dan op 'e sek, dus it wachtwurd wie nea ferkeard en it opnij yntype feroaret neat.

Lês de kontener sûnder in kaai út te skriuwen

Freegje de OpenSSL-bou op jo eigen masine it bestân te parsen en te lêzen wêr't er opjout. Ynspeksje sûnder útfierbestân lit de kaai fersegelle op 'e skiif, en dat is de iennige reden wêrom't dizze stap feilich is op in dielde host.

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

Op in legacy-bondel mei it juste wachtwurd printsje dit de sekattributen en stopet dan mei digital envelope routines::unsupported. Mei in ferkeard wachtwurd krije jo Mac verify error: invalid password? foardat hokker sek dan ek lêzen wurdt. De twa meldingen wize yn tsjinoerstelde rjochtingen, en dat is krekt de ynformaasje dy't de klant efterhold.

As de flater dy fan it net-stipe algoritme is, rin dan deselde opdracht opnij mei -legacy tafoege en neat oars feroare. Dy flagge lâdt de legacy-leveransier allinnich foar dat iene proses. It makket net dat de VPN-klant âlde bondels parset, it rekket it systeembrede kryptobelied net, en it is in mjitting yn stee fan in reparaasje, om't it bestân dochs ferfongen wurde moat.

Hokker flater betsjut hokker stap

In koarte tabel hâldt de trije útkomsten útinoar, en de formulearring telt mear as wêr't de dialooch ferskynde.

Tekst lykas not enough data of header too long heart by gjin fan 'e earste twa groepen. Dat is in formaatprobleem: in DER-bestân werneamd ta .pem, in kopy fernield troch in bewurker dy't rigelôfslutingen oerskreau, of in ûnfolsleine download. Fergelykje de kontrôlesom mei dy't de útjouwer stjoerde foardat jo nei sifers sjogge.

Behannelje Mac verify error as bewiis oer allinnich it wachtwurd. It betsjut dat de MAC berekkene út wat jo yntype hawwe, net oerienkomt mei de bewarre wearde, wat bart by in typflater, by in wachtwurd dat út in eardere ymport yn 'e cache sit, of by in bestân dat ûnder in oar wachtwurd opnij eksportearre is. It seit neat oer oft de algoritmen binnenyn âld binne.

Bou in bondel dy't de klant echt iepenje kin

Sadree't de legacy-parser befêstige hat dat it bestân goed is, is de duorsume oplossing in ferfanging wêrfan't de algoritmen troch de doelmakke klant stipe wurde: AES-256-CBC foar de kaai- en sertifikaatsekken, PBKDF2 mei SHA-256 foar ôflieding en SHA-256 foar de MAC. Jo PKI-administrator kin dat út itselde kaaimateriaal eksportearje, en it sertifikaat binnenyn bliuwt datjinge dat jo servers al fertrouwe.

As jo lokaal konvertearje moatte, freegje it pkcs12-ark dan om de sekken opnij te fersegeljen yn stee fan se earst te dumpen. Hâld beide wachtwurden bûten jo shell-skiednis troch se út in bestân te lêzen.

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

In suksesfolle konverzje seit neat oer ferfaldatum, kaaiberik, de oerienkomst fan 'e partikuliere kaai of oft de server de útjaanrige fertrout. Opnij ferpakken is in transportferoaring, gjin fernijing, en elk fan dy punten hat noch syn eigen kontrôle nedich.

Slaan elk resept oer dat in ûnbeskerme tuskenkaai skriuwt of in leech útfierwachtwurd, allinnich om't de klant it bestân dêrnei akseptearre. In lêsbere bondel mei de beskerming fuortslein is in slimmer resultaat as de ymportflater wêrmei't jo begûn binne.

Befêstigje dat de klant it bestân ymportearre dat jo boud hawwe

In skjinne parse yn in terminal bewiist dat de kontener jildich is. It bewiist net dat de klant him keazen hat, om't in efterbleaun profyl nei it âlde bestân bliuwe kin wizen, en guon klanten bewarje in ymportearre identiteit ûnder in namme dy't jo net keazen hawwe.

Printsje de identiteit dy't jo op it punt steane yn te ymportearjen en fergelykje dy mei wat de klant yn syn sertifikaatwerjefte lit sjen.

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

Ferwiderje earst de ferâldere profylynfier en ymportearje dan. As de klant it ûnderwerp of de fingerôfdruk logt dy't er laden hat, passe dy dan by de rigel hjirboppe; as er allinnich in freonlike namme lit sjen, kontrolearje dan ynstee de ferfaldatum, om't dy hurder is om mei in oar sertifikaat fan deselde útjouwer te betiizjen.

De PKCS12-referinsje listet de leveransier-, wachtwurd- en útfieropsjes op dy't hjir brûkt wurde. It punt is om de legacy-leveransier bûten de klantomjouwing te hâlden: mjitte mei, leverje sûnder, en lit de partikuliere kaai op 'e skiif beskerme.