Export the certificates from a P12 without the private key

The support ticket asks which certificate sits inside the VPN bundle, and the first instinct is to export everything and attach it. A P12 file packages certificates and private-key material in one container, so exporting everything is precisely what you do not want to send. The command that answers the question is a selection problem, not a conversion problem. Four flags decide which half of the container you get, and two of them sound safer than they are.

Start by reading the container instead of emptying it.

What a PKCS12 file actually carries

A PKCS12 container holds one or more certificates, possibly a private key, and a message authentication code over the contents. The certificates may include the leaf for your client identity and the intermediates that chain it to a CA. The key, when present, is what makes the file a secret rather than a document.

That distinction is why -nokeys exists, and why it is the flag this task needs.

Read the bundle without writing the key out

The inspection form prints structure and algorithm details and writes nothing: openssl pkcs12 -in client.p12 -info -noout. It prompts for the import password, which is the right place for that value, and it tells you whether the file carries a key at all. Use -passin env:PKCS12_PASS when the password cannot be typed, because a password inside a shell command is a password in the process list. This step exports nothing, which is the entire point.

Read the output for three things: how many certificates, whether a key is present, and which algorithms protect it.

Use -nokeys, and do not confuse it with -nocerts

-nokeys excludes private keys and leaves the certificates. -clcerts narrows that to client certificates, -cacerts narrows it to CA certificates, and those two are filters rather than alternatives. -nocerts reads like the safe spelling of the same idea and means the opposite: no certificates, which leaves only keys. Mixing it into a certificate export is how a private key ends up on disk.

The two-line form that produces a certificate file and a CA file, and nothing else, is:

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

Legacy bundles need -legacy on OpenSSL 3 to read their older encryption, and that flag changes what the parser accepts rather than what it emits. If the parse fails with an unsupported algorithm error, adding -legacy is the correct first move and skipping the MAC check is not.

Check the output, not the exit code

A zero exit status says the command ran, not that the file contains what you expect. Count the certificates in the output and read the subject and dates: openssl x509 -in client-certificates.pem -noout -subject -dates -fingerprint. Compare the fingerprint with the one the support team expects, because a bundle holding two client certificates produces a file with two blocks and most tools read only the first. Purpose, trust and key match are separate tests again.

A certificate that parses is a certificate that parses. It is not a certificate the VPN accepts.

Decide whether you need files at all

If the receiving client imports PKCS12 directly, sending the original bundle through an approved channel with the password kept separate is simpler and preserves protection. Extraction is for inspection, for a client that needs PEM, or for a support case that asked for a specific artifact. Each extraction removes one layer and should have a reason.

Public certificates do not contain the private key, but they do contain names and organisation details. Share the fields the ticket asked for rather than the file, unless the file is what was requested.