Is That Published OpenVPN Key a CA, a Peer Key or tls-auth?

Someone reports that the VPN key is public, and the sentence hides three completely different situations. It could be a CA certificate that every client is supposed to have, a private identity key that should never have left one machine, or a shared control-channel secret that both ends must hold. The repair, the urgency and the blast radius differ in each case, so the first task is classification rather than action. Get the category wrong and every later step is wasted effort.

Start from the directive, not the filename

Read the active configuration and find which directive points at the material in question. OpenVPN's TLS options use ca for trusted certificate material, cert for the local peer certificate, and key for the private key that belongs to it.

Filenames prove nothing. A file called key.pem may hold a certificate, and an inline block in the profile can contain exactly the same object as a separate file on disk. Open the file and look at its header instead of trusting the name. That one check removes most of the ambiguity in the report.

If the profile is a PKCS#12 bundle, unpack it in a controlled place to see what it actually contains. A single bundle can carry a certificate, its chain and a private key, which means a leak of the bundle is a leak of all three.

Write the classification down before anyone changes a file: object, directive, which peers hold it, and who can read it. That sentence is what the rest of the response depends on.

A CA certificate is designed to be shared

A public CA certificate is trust material. Clients need it to verify the server, and distributing it is the normal case rather than an incident. Publishing it does not publish the CA's private signing key, which is the object that would let an attacker mint new identities.

That distinction is worth stating explicitly in the ticket, because the two get conflated constantly. The question to answer is whether the leaked file is the certificate or the signing key, and a quick look at the file's contents settles it. A certificate carries a public key and a signature; the signing key does not appear in it at all.

Distribution still deserves care. Clients should obtain the certificate through the approved profile-delivery path, not from a paste site, and a certificate that arrives by an untrusted route can be replaced in transit.

A peer key and a tls-auth secret are not

A peer's private key is identity material. Once it is copied, the server can no longer distinguish the intended device from anyone holding the copy, because exclusive possession was the property being demonstrated. Continued authorization and replacement are decisions for the VPN owner, not for whoever found the file.

A tls-auth secret is a third thing. It adds HMAC authentication around control-channel packets so that incorrectly authenticated ones are discarded before a TLS exchange, and it is neither the peer's private key nor the key that encrypts application data.

If that shared secret is public, the barrier it provided is gone for everyone who has it. It does not follow that every holder passes the certificate and user checks behind it, which is why the classification matters more than the alarm level. Say which barrier fell, and say which ones remain.

Repair the role that leaked, not a neighbour

A shared secret cannot be made private again by renaming the file or hiding the download link. Replacement means generating a new value and distributing it to every peer in a coordinated change, and replacing one side only breaks the arrangement for everyone still holding the old value.

If a peer identity was exposed, use the operator's revocation and re-enrollment process for that identity. Changing an unrelated account password does not invalidate a copied certificate, and neither does swapping the tls-auth file.

Confirm what the deployed server actually enforces before you rely on any of it. A revocation list that is not refreshed, or a role check that was disabled during an outage, changes the answer entirely. Read the running configuration rather than the repository copy.

Judge past traffic on its own terms

An exposed file does not by itself tell you whether previously captured sessions can be decrypted. That depends on the key-establishment method, the material exposed and what records exist, and both all traffic is lost and nothing happened are guesses without those facts.

Do not post another copy of the credential while asking which category it belongs to. Share directive names and non-secret metadata through the approved support path instead.

The useful conclusion names the object, its role, the protection that was lost and the coordinated action required. Anything shorter is a headline rather than an assessment.