Inspecting a VPN Certificate Without Dumping Its Key

Reading a certificate's public fields never requires displaying the private key that matches it, and the tooling to do it ships with every system that terminates a VPN. The risk sits one step earlier: the file you were handed may not be a certificate at all. A PEM certificate, a DER blob, a PKCS#12 bundle and an OpenVPN profile can arrive with the same name and hold very different material, so identify the container before you choose a command.

Three facts decide which command is safe: what the file holds, what you need to read out of it, and who will see the output. Get any one of them wrong and the inspection itself becomes the incident.

Which of three files you were handed

A PEM certificate is text with visible BEGIN and END markers, a DER file is binary that needs an input-format flag, and a bundle is a container that may hold a key beside the certificate. file server.crt separates text from binary in a second, and a glance at the first line separates a bare certificate from a profile that embeds one. Guessing here is what turns an inspection into an incident.

If the file is a profile rather than a certificate, treat it as a credential until proven otherwise. That assumption costs nothing, and it prevents the most common mistake in this whole task.

Reading the public fields of a PEM certificate

For a certificate you are authorised to inspect, the x509 subcommand with -noout prints the fields you select and nothing else. Suppressing the body is what keeps the output to metadata, which is also what makes it safe to paste into a ticket. The selectors below are the public ones, and the openssl x509 documentation lists the rest.

openssl x509 -in server.crt -noout -subject -issuer -dates -fingerprint -sha256

On a locally generated test certificate that command prints a subject and issuer line, the notBefore and notAfter pair, and one SHA-256 fingerprint. Those fields identify the object; they do not establish a valid trust path, which is a separate verification task with its own command and its own answer. A chain file may also print only the first certificate unless you iterate over the file yourself. Comparing two files this way costs one command and settles which of them the peer actually presents.

Bundles that hold a key next to the certificate

A .p12 or .pfx file can carry a private key, and the parsing command prints it unless you suppress that part of the output. With -nokeys the same command still reports the container's structure, including a shrouded key bag, without emitting any key material; drop that flag and a key block appears in your terminal and in your shell history.

openssl pkcs12 -in bundle.p12 -nokeys -info -passin env:P12PASS

An OpenVPN profile embeds the same material as text, so the boundary is visible if you know where to look. Public material sits between BEGIN CERTIFICATE and END CERTIFICATE, while anything between BEGIN PRIVATE KEY and its matching END line is the key and must not leave the host. Copying the profile wholesale publishes both.

Getting the reference value from elsewhere

A fingerprint read from the connection you are trying to verify proves nothing, because the party you distrust supplied it. That is not an argument against fingerprints; it is an argument about provenance. Compare the value against one obtained through a channel the peer cannot write to, such as the certificate published in an internal repository or the hash printed in a signed change record.

Where a trust store performs validation, let it, and read the error it produces rather than substituting your own comparison. The distinction that matters is who supplied the reference, not which hash function was used.

Sharing the result, and what to do after a slip

Send the exact validation error, the relevant dates and only the identity details the recipient needs. Internal hostnames and account identifiers remain sensitive even when no key is present, and a public paste service is the wrong destination for any of it. Paste into the ticket, not into a scratch buffer someone else shares.

If key material did appear on screen or in a file, treat it as compromised and rotate it instead of hoping nobody looked. Then write down the file inspected, the command used and where the output went, because that record is what turns a scare into a procedure. Rotation is cheap next to the cost of assuming nobody kept a screenshot, and the same record tells the next engineer which files were touched at all. Do both before the ticket gets closed.