You Do Not Need the Private Key to Debug a VPN

The request sounds reasonable: send the configuration so support can see what is wrong. It is also how private keys end up in ticket systems and chat logs. A configuration is an identity, not a diagnostic, and the person debugging your tunnel almost never needs the half that proves who you are. Status output answers the same questions without that risk.

The myth is that a config is the only complete view. It is the least safe complete view.

The myth: support needs the config

Support needs the error text, the client and server versions, the endpoint, the handshake state and the order of events. All of that is status. A configuration adds keys, and keys are what let someone else be you. Handing over a config to fix a routing problem is like mailing your passport to explain a delayed flight. The request usually comes from someone who has never seen your network, asking for the thing that is easiest to attach.

Send the smallest output that answers the question, not the largest one you can find.

What status actually shows

WireGuard's wg show prints interfaces, peers, allowed IPs, endpoints, the latest handshake and transfer counters, and it does not print the private key. OpenVPN's status and log output gives connection state and errors without the inline key blocks. Both are enough to see whether a handshake completes, whether counters move, and which peer is in use, which is what the wg manual documents as the status view.

If a helper asks for a config before asking for that output, ask what the config would show that the status does not.

Where secrets hide in each format

WireGuard configuration files contain PrivateKey lines, and public peer keys plus endpoint metadata are still identifying even without them. OpenVPN profiles can embed <key> and <tls-crypt> blocks or point at separate files that travel with the profile. A client's support archive can contain far more than the log window shows, including cached profiles you forgot existed. Screenshots are the other common leak, because a terminal window shows more than the command you meant to share.

Read the export documentation, then open the file. An output labelled diagnostics has not necessarily been stripped of anything.

Redact, then send a reviewed copy

Keep the original somewhere protected and send a reviewed copy. Replace endpoints and public keys with stable placeholders when the real values are not needed, and remove private-key blocks entirely rather than partially obscuring them. Partial redaction of a base64 blob is still a leaked key. Read the file once more before it leaves, because archives often carry a second copy of the same profile.

Use a verified channel, and check who is receiving it before you attach anything.

If a key already leaked

Deleting the message does not recover the copies other people already have. Rotate the identity through the operator's revocation and replacement process, and treat the old key as compromised from the moment it was sent. Most operators will replace a client identity quickly once the exposure is reported, and the report is the part people delay.

The same rule applies to a key pasted into a ticket, a screenshot or a chat thread. Rotation is the fix; deletion is housekeeping.