Compare Two OpenVPN Profiles Without Leaking Keys

Two profiles, one connects and one does not, and the quick way to see why is a diff. The trouble is that the same diff prints the inline private key, the static key and any credential block the file carries, and people paste the output into a chat before they notice. Deciding what you are comparing comes before running the command. Compare structure and roles on protected copies, and build a separate redacted file when somebody else needs to see it.

What an .ovpn file actually carries

An .ovpn file is a configuration with optional inline blobs. It can hold a CA certificate, a client certificate, a private key, a tls-auth or tls-crypt key, and directives that point at external files or prompt for credentials. Two files can look almost identical and differ only inside a blob, or differ in one directive that changes the transport entirely. Line count tells you nothing about which of those happened.

A difference inside a key block is not public evidence of anything. A re-issued certificate and a re-keyed one can produce the same shape of change, so the blob mismatch tells you that the material is different, not which decision produced it. Treat it as a signal to compare fields, not as a finding.

Compare by role, not by line

Walk the connection's own order: endpoint and transport first, then trust and expected identity, then user authentication, then routes, DNS and script hooks. That sequence matches what the client does, so the first difference you meet is the first thing that could have broken the connection. Comparing alphabetically instead scatters related settings across the output.

A field-aware pass looks at these items, in that order. Anything the client prompts for interactively belongs with the authentication row rather than with the trust rows.

• remote, proto and port, including every connection block.
• ca and cert: issuer, subject and not-after date.
• Whether a private key is present at all, never what it contains.
• tls-auth or tls-crypt presence and key direction.
• Authentication directives, including any credential file reference.
• Routes, DNS options and script hooks that run on connect.

When a file holds several connection blocks, keep each option with its endpoint. Comparing only the first remote line can miss the alternative the client actually selects on this network.

Why a plain diff is the wrong tool

A plain diff is built for text, not for secrets. It will happily print a private key into scrollback, and it will not tell you that the directive you are staring at is irrelevant to the failure. Field extracts are both safer and more readable, because certificate material can be compared as metadata instead of bytes.

openssl x509 -in ca.crt -noout -subject -issuer -enddate
openssl x509 -in client.crt -noout -subject -issuer -enddate
grep -E '^(remote|proto|port|tls-auth|tls-crypt|route|dhcp-option)' profile.ovpn

The first two commands print identity and validity without touching the key, so their output is safe to paste. The grep prints directive names and values but never the blob bodies, which makes it the right first pass when you suspect a transport or routing difference. If a blob itself must be compared, compare its hash instead of the content.

Build a redacted copy for the ticket

Remove real secrets and unnecessary identifiers while keeping field names and enough structure to explain the difference. A marker of the same shape still reveals where the material sits and how long it was, so decide whether even that is acceptable. Check the final attachment itself rather than trusting the command you remember running. Do not edit the working original just to produce an example, because a redacted profile is not necessarily executable and should never be re-imported.

Keep the originals identifiable by filename and hash instead of copying them into three directories with similar names. A hash string is enough to prove which file was reviewed and costs nothing if it leaks. Prune the copies after the change closes so the next person inherits one authoritative file.

Keep the comparison tied to a failure

A comparison earns its cost when it answers a question about one import or one connection failure. Name the failing step first, then compare only the fields that step depends on; collecting every credential the client owns into one directory makes the next leak likelier and the next diagnosis slower. The narrower the question, the shorter the list of fields that can answer it.

If a new file came from the operator, confirm its distribution path before replacing trust material. After the change, inspect the imported copy the client actually selected and the negotiated result, because a directive can be ignored or read differently by another client version. The file on disk is not proof of the connection that ran. The directive semantics are in the OpenVPN 2.6 manual.