Nebula blocklist: distribute it, the lighthouse will not

Blocklist enforcement is a property of the host doing the checking, not of the certificate being checked. A machine that never loaded the entry keeps accepting the identity, and nothing in the handshake warns you that two peers disagree. The cheap fix and the expensive fix for one exposed credential differ in reach and in reversibility, so pick deliberately. The sections below cover what the entry does, where it has to be delivered, when rotation is the better answer, and how to prove that either one worked.

What a blocklist entry actually does

The PKI configuration lists fingerprints that a host must reject even though the certificate is validly signed and unexpired. Enforcement happens locally, against the list that host loaded when the service started. Nothing about the entry travels inside the certificate, so a peer cannot learn the decision from the credential it is shown. That is why a lighthouse plays no part here: lighthouses help peers find one another and relay traffic where a direct path fails. They are a discovery and relay layer, not a configuration distribution channel.

Updating one machine changes that machine's decisions and leaves every other peer exactly as it was. A peer that trusts the signing authority and never saw the entry has no reason to refuse anything. Testing revocation by watching the lighthouse therefore proves nothing, because the component you are watching was never asked to enforce the list.

Identify the certificate, not the device

Use the fingerprint of the credential you intend to reject, because a hostname, a device label or a current address identifies a machine today and something else next month. None of those strings appear in the blocklist, and none of them survive a reinstall. Print the certificate, read the fingerprint, and check that it belongs to the credential being retired rather than to its replacement. Reading both files matters when a replacement is already issued, since the old and new certificates can share a name and differ in every other field.

Record which fingerprint was blocked and when, so a later audit separates a completed change from an intended one. Note what the entry does not do as well: it does not invalidate the signing authority, and it does not stop a future certificate from that authority being accepted. Blocking a host certificate and replacing a compromised authority are different operations with different consequences.

nebula-cert print -path /etc/nebula/host.crt
pki:
  blocklist:
    - "a1b2c3d4e5f6"

Distribute it like any other configuration

Treat the list as configuration with a delivery mechanism rather than a file somebody edits when they remember. Push the whole list rather than a delta, so a host that missed an earlier update converges instead of accumulating gaps. The Nebula PKI documentation recommends exactly that, and the advice is worth following literally rather than paraphrasing into a manual process.

Confirm that the running service reloaded the content, not merely that the file on disk changed. Track which machines applied the change and keep the outstanding list visible until it is empty. A laptop closed for a week is a peer that never learned the decision, and it may reconnect from a network nobody expected. Record the delivery method next to the fingerprint, because the next revocation reuses it and the first one is where the process gets debugged.

Blocklist or authority rotation

A blocklist entry is narrow: one identity stops working and everything else continues. Rotating the signing authority is broad: every certificate it issued becomes untrusted, and every host needs a new credential and a new trust anchor. The first is a targeted revocation and the second is a migration, so they need different approvals and different maintenance windows. The table puts the two side by side on reach, effort and reversibility.

A lost laptop calls for the blocklist, because the blast radius is one identity and the change is reversible if you blocked the wrong fingerprint. A leaked authority key calls for rotation, because the blocklist cannot help with certificates that have not been issued yet. Between those extremes, ask whether the exposed credential could have signed anything else, since an authority is more than one host.

Write the decision down before an incident, because choosing under pressure tends to produce the broad option by default. Whichever path you take, the remaining work item is identical: prove that enforcement happened on the hosts that matter. Recording the fingerprint and the date at that moment is what makes the proof possible later.

Verify the rejection and the remainder

Connect from the blocked identity and confirm the failure, then connect from an authorised peer and confirm it still reaches what it needs. A change that breaks everyone is not a successful revocation. Do both from fresh sessions, because cached state can hide the result.

Check whether an established session ends after the change, and note the behaviour for your version and configuration instead of assuming that editing a file terminates anything. The disconnect_invalid option covers clients whose certificates are expired or invalid, so confirm how it applies to your case before relying on it. If immediate termination is a requirement, test that specifically and record what you observed. Then repeat the test after a restart, because a host that enforces the list only until its next reboot has a delivery problem that the first test concealed. A healthy lighthouse tells you that discovery works, not that any peer applied a policy.