Gammel P12 fejler på OpenSSL 3: forkert adgangskode eller forældet cipher?

Importdialogen tager din adgangskode, snurrer et øjeblik og siger derefter, at den ikke kan læse pakken. Intet i den besked fortæller dig, om du har skrevet adgangsfrasen forkert, eller om filen blev forseglet med en cipher, som klienten ikke længere leverer. Det er forskellige fejl med forskellige rettelser, og det forkerte valg fører til en nedgradering af klienten, som kun udskyder beslutningen. Ved at se på det trin, hvor klienten stopper, kan du skelne dem på cirka et minut.

Hvad der sker mellem dialogen og certifikatlisten

En .p12 fil er en beholder, ikke et certifikat. Indeni er en eller flere certifikatposer og en privatnøglepose, der er krypteret med en nøgle afledt af din adgangskode, plus et integritetstjek kaldet MAC over hele filen. At åbne den betyder at verificere den MAC, dekryptere nøgleposen og matche certifikatet med den nøgle, der kommer ud.

Adgangskodeproblemer dukker op ved MAC-trinnet. Cipher-problemer dukker op senere, når nøgleposen skal pakkes ud, og det build, der pakker den ud, ikke har nogen implementering af den algoritme, der er nævnt i filen.

Det andet tilfælde er almindeligt på nutidige systemer, fordi OpenSSL 3 flyttede en gruppe gamle algoritmer til en valgfri legacy-udbyder. Pakker eksporteret af OpenSSL 1.x forseglede typisk certifikaterne med 40-bit RC2 og privatnøglen med tre-nøgle Triple DES. Et standard OpenSSL 3-build verificerer stadig MAC'en med din korrekte adgangskode og fejler derefter på posen, så adgangskoden var aldrig forkert, og at skrive den igen ændrer intet.

Læs beholderen uden at skrive en nøgle ud

Bed OpenSSL-buildet på din egen maskine om at parse filen og læse det punkt, hvor det giver op. Inspektion uden en outputfil efterlader nøglen krypteret på disken, og det er den eneste grund til, at dette trin er sikkert på en delt vært.

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

På en legacy-pakke med den korrekte adgangskode udskriver dette posens attributter og stopper derefter med digital envelope routines::unsupported. Med en forkert adgangskode får du Mac verify error: invalid password?, før nogen pose læses. De to beskeder peger i modsatte retninger, og det er præcis den information, klienten tilbageholdt.

Hvis fejlen er den med den ikke-understøttede algoritme, kør den samme kommando igen med -legacy tilføjet og intet andet ændret. Det flag indlæser legacy-udbyderen for netop den proces. Det får ikke VPN-klienten til at parse gamle pakker, det rører ikke den systemdækkende kryptopolitik, og det er en måling snarere end en reparation, fordi filen stadig skal udskiftes.

Hvilken fejl betyder hvilket trin

En kort tabel holder de tre udfald adskilt, og formuleringen betyder mere end, hvor dialogen dukkede op.

Tekst som not enough data eller header too long hører ikke til nogen af de første to grupper. Det er et formatproblem: en DER-fil omdøbt til .pem, en kopi ødelagt af en editor, der har genskrevet linjeafslutninger, eller en ufuldstændig download. Sammenlign kontrolsummen med den, udstederen sendte, før du begynder at se på ciphers.

Behandl Mac verify error som bevis for adgangskoden alene. Det betyder, at den MAC, der er beregnet ud fra det, du skrev, ikke matcher den gemte værdi, hvilket sker med en tastefejl, med en adgangskode cachelagret fra en tidligere import eller med en fil, der er genudstedt under en anden adgangsfrase. Det siger intet om, hvorvidt algoritmerne indeni er gamle.

Byg en pakke, som klienten faktisk kan åbne

Når legacy-parseren har bekræftet, at filen er i orden, er den varige løsning en erstatning, hvis algoritmer målklienten understøtter: AES-256-CBC til nøgle- og certifikatposerne, PBKDF2 med SHA-256 til afledning og SHA-256 til MAC'en. Din PKI-administrator kan eksportere det fra det samme nøglemateriale, og certifikatet indeni forbliver det, som dine servere allerede stoler på.

Når du skal konvertere lokalt, bed pkcs12-værktøjet om at forsegle poserne igen i stedet for først at dumpe dem. Hold begge adgangsfraser ude af din shell-historik ved at læse dem fra en fil.

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

En vellykket konvertering siger intet om udløb, nøglebrug, privatnøgle-match eller om serveren stoler på udstederkæden. Genindpakning er en transportændring, ikke en fornyelse, og hver af disse ting kræver stadig sit eget tjek.

Spring enhver opskrift over, der skriver en ubeskyttet mellemliggende nøgle eller en tom output-adgangskode, blot fordi klienten derefter accepterede filen. En læsbar pakke med beskyttelsen strippet er et værre udfald end den importfejl, du startede med.

Bekræft, at klienten importerede den fil, du byggede

En ren parsing i en terminal beviser, at beholderen er gyldig. Det beviser ikke, at klienten valgte den, fordi en efterladt profil kan blive ved med at pege på den gamle fil, og nogle klienter cacher en importeret identitet under et navn, du ikke valgte.

Udskriv den identitet, du er ved at importere, og sammenlign den med det, klienten viser i sin certifikatvisning.

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

Fjern først den forældede profilpost, og importér derefter. Hvis klienten logger det subjekt eller fingeraftryk, den indlæste, skal du matche det med linjen ovenfor; hvis den kun viser et venligt navn, så tjek i stedet udløbsdatoen, da den er sværere at forveksle med et andet certifikat fra samme udsteder.

PKCS12-referencen viser de udbyder-, adgangsfrase- og outputindstillinger, der bruges her. Pointen er at holde legacy-udbyderen ude af klientmiljøet: mål med den, lever uden den, og lad privatnøglen være beskyttet på disken.