Why server keys and user credentials need separate owners

The key that proves your gateway is itself and the credential that says a person may join are both secrets, which is where the similarity ends. One identifies a service to every client; the other identifies one user to that service. Mixing them saves a step during setup and costs an afternoon during an incident, because the recovery for each is not the same operation. The split is dull to set up and memorable to skip.

Two secrets, two different owners

The gateway holds a private key or certificate whose only job is to prove its identity during the handshake. Clients need the matching public material to verify it, and they never need the private half. That asymmetry is what makes server authentication possible without handing every user the ability to impersonate the server.

User material is the other direction. A client private key, a client certificate or a password demonstrates that this particular person or device was issued access. It is expected to be distributed, copied between devices, and eventually revoked.

WireGuard makes the split obvious because every participant has a keypair: the server's private key stays on the server, and a configuration file you give a user contains their own private key plus the server's public key. A profile that contains the server's private key is not a shortcut, it is a compromise waiting for a file share.

Three questions that decide the split

Ask who must be able to read the secret, what an exposure would let an attacker do, and whether the fix is one revocation or a service rebuild.

If a user can read it and it proves the gateway identity, the answer to the second question is that the attacker can impersonate your server to every client — the worst outcome, because clients are designed to trust that identity. If it only proves one user, the exposure grants that user's access to one peer, and revocation is a routine operation. If it is a certificate authority key, exposure is worse than both, since the attacker can mint identities that every endpoint trusts.

Those three answers produce the storage rule: the CA key lives offline or in a vault, the gateway key lives on the gateway, and user keys live with users. Any layout that puts all three in one directory for convenience has collapsed a decision into an accident.

What a client actually needs

A client needs the public certificate or public peer key, the CA material or fingerprint it should trust, its own private key, and the endpoint details. That list contains nothing belonging to the gateway's private identity.

Documentation is where this leaks. A guide that says to copy the server directory and delete what you do not need has already taught the wrong model, because the file that remains after the deletion step is rarely checked by anyone.

Revoke one user without touching the gateway

Because user identities are issued separately, they can be withdrawn separately. A certificate-based deployment revokes the client certificate and publishes an updated revocation list; a WireGuard deployment removes the peer entry from the server configuration. Neither of those operations changes the gateway's own key.

Keep the issuance record, or you will not know which identity to withdraw. A spreadsheet is enough, provided it names the person, the device, the serial or public key and the date, and provided somebody owns it after the person who built it leaves.

The commands below inspect a client certificate and then revoke it through an OpenSSL-style authority, which is the flow easy-rsa wraps:

openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

Publish the new list wherever clients check it, or the revocation is a note in a file that changes nothing. If your gateway accepts client certificates without consulting a revocation list, say so explicitly rather than implying that revocation works.

Keep backups as separate as the secrets

A rebuild archive legitimately contains the gateway key and the CA material, because without them a restore cannot reproduce the service. A client setup package must not, and the two must not be stored together. Label each archive by who may hold it, not by the date it was made. That label is what a tired administrator reads at two in the morning.

That distinction also sets who may retrieve each one. Administering the gateway, issuing user identities and reading backups are three different powers, and a person who needs one does not automatically need the others. Write those permissions down, then check them against what your storage actually allows, because directory inheritance silently grants more than the policy intends.