Nebula needs three files: CA, host certificate, host key

Hand someone a Nebula directory and they will usually copy the whole thing, including the file that should never leave your workstation. The confusion is understandable, because the three files in a host's PKI block look alike and two of them are certificates. Each one answers a different question, and only two of them belong on the node. Sort them by role before you copy anything.

Three files, three different jobs

The CA certificate is a trust anchor: it tells a host which authorities to believe when another host presents its identity. The host certificate is the node's own credential, signed by that authority. The host key is the matching private half, and it belongs to exactly one machine. A node with the CA certificate and its own pair can join the overlay and prove who it is. A node with somebody else's key can also claim to be that somebody, which is the failure this layout exists to prevent.

Copying a working host directory onto a second machine is therefore not a shortcut. It is a duplicate identity with a predictable outcome.

The signing key never travels

The CA signing key is not part of any host configuration. It mints new identities, and whoever holds it can create a certificate for any overlay address and any group. Peers need only the public CA certificate to verify signatures, so the private half has no role on a client at all. Keep it on the machine where certificates are issued, and treat an accidental copy as an incident rather than a convenience.

If several people need to issue certificates, give them a process instead of a copy of the key. A shared signing key on a laptop is an authority nobody can audit or revoke.

What is inside a host certificate

A host certificate binds more than a filename to a key. It carries the node's overlay address, its name and its group membership, all signed so a peer can decide whether to accept it. That is why renaming a host means issuing a new certificate rather than editing a configuration line.

nebula-cert print -path host.crt shows what was actually issued. Read it before assuming a certificate carries the address you intended.

Reload is not always enough

Some PKI settings reload on a signal, and some do not. A certificate whose overlay address changed is the classic case that needs a process restart rather than a reload.

Confirm which paths the running process actually opened, not just which paths the configuration file names. Then change one credential, verify connectivity and logs, and only then touch the next. A reload that appears to succeed while the old certificate stays in memory produces a mismatch that looks like a routing problem. Restarting is cheap; debugging an identity that half the overlay still sees the old way is not.

Removing an identity takes a blocklist

Replacing a lost or exposed credential has two halves. The new certificate restores access, and the old identity has to stop being accepted. Those are separate operations, and doing only the first leaves the compromised credential valid.

The blocklist is a file you distribute to hosts, not something a lighthouse pushes out on its own. Plan how it reaches every node, including the ones offline today, and record which fingerprints you blocked. Rotate the key on the issuing machine and keep the new certificate's details with the host record. A revocation that exists only on the machine you edited is not a revocation.