De certificaten uit een P12 exporteren zonder de privésleutel

Het supportticket vraagt welk certificaat in de VPN-bundel zit, en de eerste neiging is alles te exporteren en mee te sturen. Een P12-bestand verpakt certificaten en materiaal voor de privésleutel in één container, dus alles exporteren is precies wat je niet wilt versturen. De opdracht die de vraag beantwoordt is een selectieprobleem, geen conversieprobleem. Vier flags bepalen welke helft van de container je krijgt, en twee ervan klinken veiliger dan ze zijn.

Begin met de container te lezen in plaats van hem leeg te maken.

Wat een PKCS12-bestand werkelijk bevat

Een PKCS12-container bevat een of meer certificaten, mogelijk een privésleutel en een message authentication code over de inhoud. De certificaten kunnen het leaf-certificaat voor je clientidentiteit bevatten en de tussenliggende certificaten die het aan een CA koppelen. De sleutel, wanneer aanwezig, is wat het bestand een geheim maakt in plaats van een document.

Dat onderscheid is waarom -nokeys bestaat en waarom het de flag is die deze taak nodig heeft.

De bundel lezen zonder de sleutel weg te schrijven

De inspectievorm print structuur- en algoritmedetails en schrijft niets: openssl pkcs12 -in client.p12 -info -noout. Hij vraagt om het importwachtwoord, wat de juiste plek is voor die waarde, en hij vertelt je of het bestand überhaupt een sleutel bevat. Gebruik -passin env:PKCS12_PASS wanneer het wachtwoord niet getypt kan worden, want een wachtwoord in een shell-opdracht is een wachtwoord in de proceslijst. Deze stap exporteert niets, en dat is precies het punt.

Lees de uitvoer op drie dingen: hoeveel certificaten, of er een sleutel aanwezig is en welke algoritmen die beschermen.

Gebruik -nokeys en verwar het niet met -nocerts

-nokeys sluit privésleutels uit en laat de certificaten staan. -clcerts beperkt dat tot clientcertificaten, -cacerts beperkt het tot CA-certificaten, en die twee zijn filters in plaats van alternatieven. -nocerts leest als de veilige spelling van hetzelfde idee en betekent het tegenovergestelde: geen certificaten, waardoor alleen sleutels overblijven. Het in een certificaatexport mengen is hoe een privésleutel op schijf belandt.

De vorm van twee regels die een certificaatbestand en een CA-bestand oplevert, en niets anders, is:

openssl pkcs12 -in client.p12 -nokeys -clcerts -out client-certificates.pem
openssl pkcs12 -in client.p12 -nokeys -cacerts -out ca-certificates.pem

Verouderde bundels hebben -legacy nodig op OpenSSL 3 om hun oudere versleuteling te lezen, en die flag verandert wat de parser accepteert, niet wat hij uitvoert. Als het parsen mislukt met een fout over een niet-ondersteund algoritme, is -legacy toevoegen de juiste eerste stap en het overslaan van de MAC-controle niet.

Controleer de uitvoer, niet de exitcode

Een exitstatus van nul zegt dat de opdracht liep, niet dat het bestand bevat wat je verwacht. Tel de certificaten in de uitvoer en lees het subject en de datums: openssl x509 -in client-certificates.pem -noout -subject -dates -fingerprint. Vergelijk de fingerprint met degene die het supportteam verwacht, want een bundel met twee clientcertificaten levert een bestand met twee blokken op en de meeste tools lezen alleen het eerste. Doel, vertrouwen en sleutelovereenkomst zijn weer aparte tests.

Een certificaat dat parseert is een certificaat dat parseert. Het is geen certificaat dat de VPN accepteert.

Beslis of je überhaupt bestanden nodig hebt

Als de ontvangende client PKCS12 rechtstreeks importeert, is het originele bundel via een goedgekeurd kanaal sturen met het wachtwoord apart eenvoudiger en blijft de bescherming behouden. Extractie is voor inspectie, voor een client die PEM nodig heeft, of voor een supportcase die een specifiek artefact vroeg. Elke extractie verwijdert een laag en zou een reden moeten hebben.

Openbare certificaten bevatten niet de privésleutel, maar wel namen en organisatiegegevens. Deel de velden die het ticket vroeg in plaats van het bestand, tenzij het bestand juist is aangevraagd.