Exportera certifikaten från en P12 utan den privata nyckeln

Supportärendet frågar vilket certifikat som ligger i VPN-paketet, och den första impulsen är att exportera allt och bifoga det. En P12-fil packar certifikat och privat nyckelmaterial i en enda container, så att exportera allt är precis det du inte vill skicka. Kommandot som besvarar frågan är ett urvalsproblem, inte ett konverteringsproblem. Fyra flaggor avgör vilken halva av containern du får, och två av dem låter säkrare än de är.

Börja med att läsa containern i stället för att tömma den.

Vad en PKCS12-fil faktiskt innehåller

En PKCS12-container innehåller ett eller flera certifikat, möjligen en privat nyckel och en message authentication code över innehållet. Certifikaten kan omfatta leaf-certifikatet för din klientidentitet och de mellanliggande certifikat som kedjar det till en CA. Nyckeln, när den finns, är det som gör filen till en hemlighet i stället för ett dokument.

Den skillnaden är anledningen till att -nokeys finns och till att det är den flagga uppgiften behöver.

Läs paketet utan att skriva ut nyckeln

Inspektionsformen skriver ut struktur- och algoritmdetaljer och skriver ingenting: openssl pkcs12 -in client.p12 -info -noout. Den frågar efter importlösenordet, vilket är rätt plats för det värdet, och den berättar om filen överhuvudtaget innehåller en nyckel. Använd -passin env:PKCS12_PASS när lösenordet inte kan skrivas in, för ett lösenord i ett shell-kommando är ett lösenord i processlistan. Det här steget exporterar ingenting, vilket är hela poängen.

Läs utdata efter tre saker: hur många certifikat, om en nyckel finns och vilka algoritmer som skyddar den.

Använd -nokeys och blanda inte ihop det med -nocerts

-nokeys utesluter privata nycklar och lämnar certifikaten. -clcerts begränsar det till klientcertifikat, -cacerts begränsar det till CA-certifikat, och de två är filter snarare än alternativ. -nocerts låter som den säkra stavningen av samma idé och betyder motsatsen: inga certifikat, vilket bara lämnar nycklar. Att blanda in det i en certifikatexport är hur en privat nyckel hamnar på disken.

Den tvåradiga form som ger en certifikatfil och en CA-fil, och inget annat, är:

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

Äldre paket behöver -legacy på OpenSSL 3 för att läsa sin äldre kryptering, och den flaggan ändrar vad parsern accepterar, inte vad den ger ut. Om parsningen misslyckas med ett fel om en algoritm som inte stöds är det rätta första steget att lägga till -legacy, och att hoppa över MAC-kontrollen är det inte.

Kontrollera utdata, inte exitkoden

En exitstatus på noll säger att kommandot kördes, inte att filen innehåller det du förväntar dig. Räkna certifikaten i utdata och läs subject och datum: openssl x509 -in client-certificates.pem -noout -subject -dates -fingerprint. Jämför fingeravtrycket med det som supportteamet förväntar sig, för ett paket med två klientcertifikat ger en fil med två block och de flesta verktyg läser bara det första. Syfte, förtroende och nyckelmatchning är återigen separata tester.

Ett certifikat som går att parsa är ett certifikat som går att parsa. Det är inte ett certifikat som VPN:en accepterar.

Avgör om du alls behöver filer

Om den mottagande klienten importerar PKCS12 direkt är det enklare att skicka det ursprungliga paketet via en godkänd kanal med lösenordet hållet åtskilt, och skyddet bevaras. Extrahering är till för inspektion, för en klient som behöver PEM eller för ett supportärende som bad om en specifik artefakt. Varje extrahering tar bort ett lager och bör ha ett skäl.

Offentliga certifikat innehåller inte den privata nyckeln, men de innehåller namn och organisationsuppgifter. Dela fälten som ärendet bad om i stället för filen, om det inte är filen som efterfrågades.