P12 vechi eșuează pe OpenSSL 3: parolă greșită sau cifru vechi?

Dialogul de import preia parola, se învârte o clipă și apoi spune că nu poate citi pachetul. Nimic din acel mesaj nu spune dacă ai scris greșit fraza de acces sau dacă fișierul a fost sigilat cu un cifru pe care clientul nu îl mai livrează. Sunt eșecuri diferite cu remedieri diferite, iar alegerea greșită duce la o retrogradare a clientului care doar amână decizia. Urmărirea etapei în care clientul se oprește le separă în aproximativ un minut.

Ce se întâmplă între dialog și lista de certificate

Un fișier .p12 este un container, nu un certificat. Înăuntru se află unul sau mai multe saci de certificate și un sac de cheie privată criptat cu o cheie derivată din parola ta, plus o verificare de integritate numită MAC asupra întregului fișier. A deschide înseamnă a verifica acel MAC, a decripta sacul cheii și a potrivi certificatul cu cheia care iese.

Problema parolei apare la etapa MAC. Problema cifrului apare mai târziu, când sacul cheii trebuie desfăcut și build-ul care face asta nu are implementare pentru algoritmul numit în fișier.

Al doilea caz este frecvent pe sistemele actuale pentru că OpenSSL 3 a mutat un grup de algoritmi vechi într-un legacy provider opțional. Pachetele exportate de OpenSSL 1.x sigilau de obicei certificatele cu RC2 pe 40 de biți și cheia privată cu Triple DES cu trei chei. Un build implicit OpenSSL 3 verifică totuși MAC-ul cu parola corectă și apoi eșuează la sac, deci parola nu a fost niciodată greșită și rescrierea ei nu schimbă nimic.

Citește containerul fără a scrie o cheie

Cere build-ului OpenSSL de pe mașina ta să analizeze fișierul și să citească punctul în care renunță. O inspecție fără fișier de ieșire lasă cheia criptată pe disc, și acesta este singurul motiv pentru care acest pas este sigur pe un host partajat.

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

Pe un pachet vechi cu parola corectă, aceasta afișează atributele sacului și apoi se oprește cu digital envelope routines::unsupported. Cu o parolă greșită primești Mac verify error: invalid password? înainte de a fi citit vreun sac. Cele două mesaje indică direcții opuse, și exact aceasta este informația pe care clientul a ascuns-o.

Dacă eșecul este cel al algoritmului neacceptat, rulează aceeași comandă din nou cu -legacy adăugat și nimic altceva schimbat. Acel fanion încarcă legacy provider doar pentru acel singur proces. Nu obligă clientul VPN să analizeze pachete vechi, nu atinge politica criptografică la nivel de sistem și este o măsurătoare, nu o reparație, pentru că fișierul tot trebuie înlocuit.

Care eroare înseamnă care etapă

Un tabel scurt ține cele trei rezultate separate, iar formularea contează mai mult decât locul în care a apărut dialogul.

Text precum not enough data sau header too long nu aparține niciunuia dintre primele două grupuri. Este o problemă de format: un fișier DER redenumit în .pem, o copie stricată de un editor care a rescris capetele de rând, sau o descărcare incompletă. Compară suma de control cu cea trimisă de emitent înainte de a începe să te uiți la cifruri.

Tratează Mac verify error doar ca dovadă despre parolă. Înseamnă că MAC-ul calculat din ce ai tastat nu se potrivește cu valoarea stocată, ceea ce se întâmplă la o greșeală de tastare, la o parolă din cache de la un import anterior sau la un fișier reexportat sub altă frază de acces. Nu spune nimic despre dacă algoritmii dinăuntru sunt vechi.

Construiește un pachet pe care clientul chiar îl poate deschide

După ce analizatorul legacy confirmă că fișierul este sănătos, remedierea durabilă este un înlocuitor cu algoritmi acceptați de clientul țintă: AES-256-CBC pentru sacii cheii și ai certificatelor, PBKDF2 cu SHA-256 pentru derivare și SHA-256 pentru MAC. Administratorul tău PKI îl poate exporta din același material de cheie, iar certificatul dinăuntru rămâne cel în care serverele tale au deja încredere.

Când trebuie să convertești local, cere instrumentului pkcs12 să re-sigileze sacii în loc să îi arunce mai întâi. Ține ambele fraze de acces în afara istoricului shell-ului citindu-le dintr-un fișier.

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

O conversie reușită nu spune nimic despre expirare, utilizarea cheii, potrivirea cheii private sau dacă serverul are încredere în lanțul emitent. Reambalarea este o schimbare de transport, nu o reînnoire, iar fiecare dintre ele are în continuare nevoie de propria verificare.

Sari peste orice rețetă care scrie o cheie intermediară neprotejată sau o parolă de ieșire goală doar pentru că clientul a acceptat apoi fișierul. Un pachet lizibil cu protecția eliminată este un rezultat mai rău decât eșecul de import cu care ai început.

Confirmă că clientul a importat fișierul construit

O analiză curată în terminal dovedește că containerul este valid. Nu dovedește că clientul l-a ales, pentru că un profil rămas poate continua să indice fișierul vechi, iar unii clienți memorează identitatea importată sub un nume pe care nu l-ai ales.

Tipărește identitatea pe care urmează să o imporți și compar-o cu ce arată clientul în vizualizarea certificatelor.

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

Elimină mai întâi intrarea veche din profil, apoi importă. Dacă clientul înregistrează subiectul sau amprenta pe care a încărcat-o, potrivește-o cu linia de mai sus; dacă arată doar un nume prietenos, verifică în schimb data expirării, pentru că este mai greu de confundat cu un alt certificat de la același emitent.

Referința PKCS12 enumeră providerul, fraza de acces și opțiunile de ieșire folosite aici. Ținerea legacy provider în afara mediului clientului este ideea: măsoară cu el, livrează fără el și lasă cheia privată protejată pe disc.