Can You Share a VPN Public Key? Check These Three Things

You can hand your VPN public key to a peer, a provider, or a forum, and the tunnel still holds. You cannot hand over the private key, even to support staff, without handing over the identity that key proves. The decision rarely stays that clean, because people confuse which half of the pair they are looking at, and because some deployments treat the public value as a name. Three checks settle it: which half you have, what the deployment binds to it, and what replacement costs.

Check one: which half of the pair is in your clipboard

Asymmetric keys come in pairs, and the direction of derivation is the whole point. In WireGuard the private key is 32 random bytes and the public key is computed from it; you cannot go the other way. wg genkey writes the private value, wg pubkey derives the public one, and only the second belongs in a message to a peer.

wg genkey | tee private.key | wg pubkey > public.key
chmod 600 private.key
openssl x509 -noout -pubkey -in server.crt

The certificate world uses the same split with more moving parts. A server certificate carries a public key plus names, and it is signed by a CA private key that never leaves the CA. A client verifying that server needs the CA certificate, which is public, and has no use for the CA's private signing key.

If you are unsure which value you are holding, look for the marker rather than the filename. A PEM block beginning with -----BEGIN PRIVATE KEY-----, or the older BEGIN RSA PRIVATE KEY form, is the secret half. A value you can paste without that marker is a candidate for sharing, subject to the next two checks.

Check two: what the deployment binds to that public value

Cryptographic safety and anonymity are different properties. A WireGuard peer public key is a stable identifier inside the deployment: the server config lists it, the handshake names it, and an administrator reading logs sees the same string every time that peer connects. Post the key next to a question about your setup, and you have linked that string to everything else in the post.

Certificates leak identity by design. Subject and subject alternative names are readable, and for publicly trusted TLS certificates the certificate itself is published to Certificate Transparency logs, which are searchable. None of that exposes a private key, and all of it exposes a relationship.

This is where deployments differ, and it decides the answer. A throwaway test peer on a lab server is a different object from the key identifying a company's site-to-site endpoint, even though the bytes look identical.

Check three: what you can revoke, and how fast

The third check separates the two halves completely. A public key that has been published can be replaced on your schedule. A private key that has been published cannot be recalled: deleting your copy does not touch copies already taken, and every peer that trusted it now trusts something an outsider holds.

Revocation is a configuration action, not a cryptographic one. WireGuard ships no revocation list, so you remove the peer:

wg set wg0 peer <peer-public-key> remove
# then delete the [Peer] block from the config so it does not return on restart

OpenVPN deployments built on certificates revoke the certificate and publish a CRL that the server actually checks through crl-verify. Without that directive the revocation list is decoration. Either way the sequence is the same: issue a replacement, distribute it through the supported channel, then retire the old identity.

The mistakes that come from collapsing the three checks

Most real leaks are not a person deciding to publish a private key. They are a whole profile pasted into a forum: a WireGuard .conf with a PrivateKey line, an .ovpn bundle with an inline key block, or a screenshot of a client window that happens to include the key field. The public value was probably fine; it travelled with the part that was not.

Support workflows are the second source. No legitimate verification step needs your private key, because the other side derives what it needs from the public half. When a form or a person asks for the private value, the correct answer is the public one plus the local command that produces it.

Logs and screenshots belong in the same category. Diagnostic output can carry key material, session identifiers and internal addresses, and posting all of it to get one question answered trades a small convenience for a larger exposure.

After a private value leaks, retire the identity

If a private value did get out, treat that identity as retired. Generate a new pair, install the public half where peers expect it, remove the old peer or revoke the old certificate, and check the places you published it. You cannot delete copies you do not control, so removal is about the future, not the past.

Then write the distribution down: which key belongs to which device, who holds a copy, how a replacement is delivered, and who removes a retired peer. Those are the parts people forget, and they decide how long a leak stays useful.