Nebula 黑名单：要分发的是它，灯塔不会代劳

黑名单的执行是执行检查的那台主机的属性，而不是被检查的证书的属性。从未加载过该条目的机器会继续接受这个身份，握手中没有任何东西会提醒你两端并不一致。针对一份已泄露的凭据，便宜的做法和昂贵的做法在影响范围和可逆性上不同，所以要刻意选择。下面几节涵盖这条目做什么、必须在何处投递、什么时候轮换是更好的答案，以及如何证明其中任一种做法确实生效。

黑名单条目实际做了什么

PKI 配置会列出主机必须拒绝的指纹，即使该证书签名有效且未过期。执行发生在本地，依据的是该主机在服务启动时加载的那份名单。条目的任何内容都不会随证书一起传输，因此对端无法从被展示的凭据中得知这个决定。这就是灯塔在这里毫无作用的原因：灯塔帮助对端互相发现，并在直连路径失败处中继流量。它们属于发现与中继层，不是配置分发通道。

更新一台机器只会改变那台机器的判断，其他每个对端都保持原样。信任签发机构且从未见过该条目的对端没有任何理由拒绝什么。因此，靠观察灯塔来测试吊销什么都证明不了，因为你观察的组件从未被要求执行这份名单。

识别证书，而不是设备

使用你打算拒绝的那份凭据的指纹，因为主机名、设备标签或当前地址今天指向一台机器，下个月就指向别的东西。这些字符串都不会出现在黑名单里，也都熬不过一次重装。打印证书，读取指纹，并确认它属于正在退役的凭据，而不是它的替代品。在替代证书已经签发时，两份文件都要读，因为新旧证书可能共用同一个名字，而在其他每个字段上都不同。

记录被拉黑的是哪个指纹、何时拉黑，好让日后的审计能把已完成的变更与计划中的变更区分开。也要记下条目做不到的事：它不会使签发机构失效，也不会阻止该机构未来签发的证书被接受。拉黑主机证书与更换已泄露的机构是两种不同的操作，后果也不同。

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

像分发其他任何配置一样分发它

把名单当成带投递机制的配置，而不是谁想起来才改一下的文件。推送整份名单而不是增量，这样错过上次更新的主机会收敛，而不是不断积累缺口。Nebula PKI 文档推荐的正是这一点，这条建议值得照字面执行，而不是改写成手工流程。

确认正在运行的服务重新加载了内容，而不只是磁盘上的文件变了。跟踪哪些机器应用了这项变更，并让未完成的名单保持可见，直到清空。一台关了一周的笔记本就是从未得知该决定的对端，它可能从没人预料到的网络重新连上来。把投递方式记在指纹旁边，因为下一次吊销会复用它，而第一次正是调试流程的地方。

黑名单还是轮换机构

黑名单条目很窄：一个身份停止工作，其余一切照常。轮换签发机构很宽：它签发的每张证书都不再被信任，每台主机都需要新凭据和新信任锚。前者是定点吊销，后者是迁移，所以它们需要不同的审批和不同的维护窗口。表格从影响范围、投入和可逆性三方面把两者并排放在一起。

丢失的笔记本该用黑名单，因为影响半径只有一个身份，而且如果你拉错了指纹，这项变更可以撤销。泄露的机构密钥该用轮换，因为黑名单对尚未签发的证书无能为力。在这两个极端之间，要问已泄露的凭据是否还可能签过别的东西，因为一个机构不止一台主机。

在事故之前就把决定写下来，因为压力之下做选择往往默认产出更宽的那个选项。无论走哪条路，剩下的工作都一样：证明执行确实发生在重要的主机上。在当时就记下指纹和日期，正是日后让证明成为可能的东西。

验证被拒绝的一方与其余部分

从被拉黑的身份连接并确认失败，然后从已授权的对端连接并确认它仍能到达需要的地方。让所有人都断掉的变更不是成功的吊销。两者都从全新会话里做，因为缓存状态可能掩盖结果。

检查已建立的会话在变更后是否结束，并为你的版本和配置记下实际行为，而不是假定改个文件就能终止什么。disconnect_invalid 选项覆盖证书已过期或无效的客户端，所以在依赖它之前，先确认它在你的情形里如何适用。如果要求立即终止，就专门测试这一点并记录你观察到的结果。然后在重启之后再重复测试，因为只在下次重启前执行名单的主机存在一个投递问题，而第一次测试把它掩盖了。健康的灯塔说明发现机制能用，并不说明任何对端已经应用了策略。