Esportare i certificati da un P12 senza la chiave privata

Il ticket di supporto chiede quale certificato si trova nel bundle VPN, e il primo istinto è esportare tutto e allegarlo. Un file P12 impacchetta certificati e materiale di chiave privata in un unico contenitore, quindi esportare tutto è proprio ciò che non va inviato. Il comando che risponde alla domanda è un problema di selezione, non di conversione. Quattro opzioni decidono quale metà del contenitore ottenete, e due di esse sembrano più sicure di quanto siano.

Iniziate leggendo il contenitore invece di svuotarlo.

Cosa contiene davvero un file PKCS12

Un contenitore PKCS12 contiene uno o più certificati, eventualmente una chiave privata e un codice di autenticazione del messaggio sul contenuto. I certificati possono includere il certificato foglia della vostra identità client e gli intermedi che lo collegano a una CA. La chiave, quando presente, è ciò che rende il file un segreto invece di un documento.

Questa distinzione è il motivo per cui -nokeys esiste ed è l'opzione che serve a questa attività.

Leggere il bundle senza scrivere la chiave

La forma di ispezione stampa la struttura e i dettagli degli algoritmi e non scrive nulla: openssl pkcs12 -in client.p12 -info -noout. Chiede la password di importazione, che è il posto giusto per quel valore, e vi dice se il file contiene una chiave. Usate -passin env:PKCS12_PASS quando la password non può essere digitata, perché una password dentro un comando shell è una password nella lista dei processi. Questo passaggio non esporta nulla, che è esattamente il punto.

Leggete l'output per tre cose: quanti certificati, se è presente una chiave e quali algoritmi la proteggono.

Usate -nokeys e non confondetelo con -nocerts

-nokeys esclude le chiavi private e lascia i certificati. -clcerts restringe il risultato ai certificati client, -cacerts lo restringe ai certificati CA, e questi due sono filtri, non alternative. -nocerts si legge come la grafia sicura della stessa idea e significa l'opposto: nessun certificato, il che lascia solo le chiavi. Mescolarlo in un'esportazione di certificati è il modo in cui una chiave privata finisce sul disco.

La forma in due righe che produce un file di certificati e un file CA, e nulla più, è:

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

I bundle legacy hanno bisogno di -legacy su OpenSSL 3 per leggere la loro crittografia più vecchia, e quell'opzione cambia ciò che il parser accetta, non ciò che emette. Se l'analisi fallisce con un errore di algoritmo non supportato, aggiungere -legacy è la prima mossa corretta e saltare il controllo del MAC non lo è.

Controllate l'output, non il codice di uscita

Un codice di uscita zero dice che il comando è stato eseguito, non che il file contenga ciò che vi aspettate. Contate i certificati nell'output e leggete il soggetto e le date: openssl x509 -in client-certificates.pem -noout -subject -dates -fingerprint. Confrontate l'impronta con quella che il team di supporto si aspetta, perché un bundle con due certificati client produce un file con due blocchi e la maggior parte degli strumenti legge solo il primo. Scopo, fiducia e corrispondenza della chiave sono di nuovo test separati.

Un certificato che si analizza è un certificato che si analizza. Non è un certificato che la VPN accetta.

Decidete se vi servono davvero dei file

Se il client ricevente importa PKCS12 direttamente, inviare il bundle originale attraverso un canale approvato con la password tenuta separata è più semplice e conserva la protezione. L'estrazione serve per l'ispezione, per un client che ha bisogno di PEM o per un caso di supporto che ha chiesto un artefatto specifico. Ogni estrazione rimuove uno strato e dovrebbe avere un motivo.

I certificati pubblici non contengono la chiave privata, ma contengono nomi e dettagli dell'organizzazione. Condividete i campi richiesti dal ticket invece del file, a meno che non sia stato richiesto il file.