Oude P12 mislukt op OpenSSL 3: verkeerd wachtwoord of oude cipher?

De importdialoog neemt je wachtwoord, draait even en zegt dan dat hij de bundel niet kan lezen. Niets in die melding vertelt of je de wachtwoordzin verkeerd hebt getypt of dat het bestand is verzegeld met een cipher die de client niet meer meelevert. Dat zijn verschillende fouten met verschillende oplossingen, en een verkeerde keuze leidt tot een downgrade van de client die de beslissing alleen uitstelt. Kijken bij welke stap de client stopt, scheidt ze in ongeveer een minuut.

Wat er gebeurt tussen de dialoog en de certificatenlijst

Een .p12-bestand is een container, geen certificaat. Binnenin zitten een of meer certificaatzakken en een privésleutelzak die is versleuteld met een sleutel die van je wachtwoord is afgeleid, plus een integriteitscontrole genaamd MAC over het hele bestand. Het openen betekent die MAC verifiëren, de sleutelzak ontsleutelen en het certificaat koppelen aan de sleutel die eruit komt.

Het wachtwoordprobleem komt bij de MAC-stap. Het cipherprobleem komt later, wanneer de sleutelzak moet worden uitgepakt en de build die dat doet geen implementatie heeft voor het algoritme dat in het bestand staat.

Het tweede geval komt veel voor op huidige systemen omdat OpenSSL 3 een groep oude algoritmen naar een optionele legacy provider heeft verplaatst. Bundels die met OpenSSL 1.x zijn geëxporteerd, verzegelden de certificaten meestal met 40-bits RC2 en de privésleutel met drie-sleutel Triple DES. Een standaard OpenSSL 3-build verifieert de MAC nog steeds met je juiste wachtwoord en faalt dan op de zak, dus het wachtwoord was nooit fout en opnieuw typen verandert niets.

Lees de container zonder een sleutel weg te schrijven

Vraag de OpenSSL-build op je eigen machine het bestand te parsen en te lezen waar hij opgeeft. Inspectie zonder uitvoerbestand laat de sleutel versleuteld op schijf staan, en dat is de enige reden waarom deze stap veilig is op een gedeelde host.

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

Bij een oude bundel met het juiste wachtwoord drukt dit de zakattributen af en stopt dan met digital envelope routines::unsupported. Met een verkeerd wachtwoord krijg je Mac verify error: invalid password? voordat er een zak wordt gelezen. De twee meldingen wijzen in tegengestelde richtingen, en dat is precies de informatie die de client achterhield.

Als de fout de niet-ondersteunde algoritme is, voer dan dezelfde opdracht opnieuw uit met -legacy toegevoegd en niets anders gewijzigd. Die vlag laadt de legacy provider alleen voor dat ene proces. Het dwingt de VPN-client niet om oude bundels te parsen, het raakt het systeembrede cryptobeleid niet aan, en het is een meting en geen reparatie, omdat het bestand nog steeds vervangen moet worden.

Welke fout welke fase betekent

Een korte tabel houdt de drie uitkomsten uit elkaar, en de formulering is belangrijker dan waar de dialoog verscheen.

Tekst zoals not enough data of header too long hoort bij geen van de eerste twee groepen. Dat is een formaatprobleem: een DER-bestand dat is omgedoopt tot .pem, een kopie die is verminkt door een editor die regeleinden herschreef, of een onvolledige download. Vergelijk de checksum met die de uitgever stuurde voordat je naar ciphers gaat kijken.

Behandel Mac verify error alleen als bewijs over het wachtwoord. Het betekent dat de MAC berekend uit wat je typte niet overeenkomt met de opgeslagen waarde, wat gebeurt bij een typefout, bij een wachtwoord dat uit een eerdere import is gecacht, of bij een bestand dat opnieuw is geëxporteerd onder een andere wachtwoordzin. Het zegt niets over de vraag of de algoritmen binnenin oud zijn.

Bouw een bundel die de client echt kan openen

Zodra de legacy-parser bevestigt dat het bestand gezond is, is de blijvende oplossing een vervanging waarvan de algoritmen door de doelclient worden ondersteund: AES-256-CBC voor de sleutel- en certificaatzakken, PBKDF2 met SHA-256 voor de afleiding en SHA-256 voor de MAC. Je PKI-beheerder kan dat uit hetzelfde sleutelmateriaal exporteren, en het certificaat binnenin blijft het certificaat dat je servers al vertrouwen.

Als je lokaal moet converteren, vraag het pkcs12-gereedschap dan om de zakken opnieuw te verzegelen in plaats van ze eerst te dumpen. Houd beide wachtwoordzinnen buiten je shellgeschiedenis door ze uit een bestand te lezen.

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

Een geslaagde conversie zegt niets over verlopen, sleutelgebruik, de koppeling met de privésleutel of het vertrouwen van de server in de uitgevende keten. Opnieuw verpakken is een transportwijziging, geen verlenging, en elk daarvan heeft nog steeds zijn eigen controle nodig.

Sla elk recept over dat een onbeschermde tussensleutel schrijft of een leeg uitvoerwachtwoord gebruikt, alleen omdat de client het bestand daarna accepteerde. Een leesbare bundel met de bescherming eraf is een slechter resultaat dan de importfout waarmee je begon.

Controleer of de client het bestand heeft geïmporteerd dat je bouwde

Een schone parse in een terminal bewijst dat de container geldig is. Het bewijst niet dat de client hem heeft gekozen, omdat een achtergebleven profiel naar het oude bestand kan blijven wijzen, en sommige clients cachen een geïmporteerde identiteit onder een naam die je niet hebt gekozen.

Druk de identiteit af die je gaat importeren en vergelijk die met wat de client toont in zijn certificaatweergave.

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

Verwijder eerst de verouderde profielregel en importeer daarna. Als de client het onderwerp of de vingerafdruk logt die hij heeft geladen, vergelijk die dan met de regel hierboven; als hij alleen een vriendelijke naam toont, controleer dan in plaats daarvan de vervaldatum, want die is moeilijker te verwarren met een ander certificaat van dezelfde uitgever.

De PKCS12-referentie somt de provider, de wachtwoordzin en de uitvoeropties op die hier worden gebruikt. De legacy provider buiten de clientomgeving houden is het punt: meet ermee, lever zonder, en laat de privésleutel beschermd op schijf staan.