Nebula 需要三个文件：CA、主机证书和主机密钥

把 Nebula 目录交给别人，对方通常会整个复制，连那个永远不该离开工作机的文件也一起带走。这种混淆可以理解，因为主机 PKI 块里的三个文件长得很像，其中两个还是证书。它们各自回答不同的问题，而只有两个该放在节点上。复制任何东西之前，先按角色把它们分开。

三个文件，三种不同的职责

CA 证书是信任锚：当另一台主机出示身份时，它告诉本机该信任哪些机构。主机证书是节点自己的凭据，由该机构签发。主机密钥是与之配对的私钥那一半，只属于一台机器。拥有 CA 证书和自己密钥对的节点可以加入 overlay 并证明自己是谁。而持有他人密钥的节点也能冒充那个人，这正是这套布置要防止的故障。

因此，把可用的主机目录复制到第二台机器并不是捷径。那是可预见结果的重复身份。

签名密钥永不外传

CA 签名密钥不属于任何主机配置。它铸造新的身份，持有者可以为任意 overlay 地址和任意组签发证书。对等节点只需公开的 CA 证书即可验证签名，所以私钥在客户端上根本没有角色。把它留在签发证书的机器上，并把意外复制当作事件而不是便利。

如果有多人需要签发证书，给他们流程而不是密钥副本。放在笔记本上的共享签名密钥，是一种无人能审计或吊销的权限。

主机证书里有什么

主机证书绑定到密钥的不只是一个文件名。它携带节点的 overlay 地址、名称和组成员关系，全部经过签名，以便对等节点决定是否接受。这也是为什么给主机改名意味着签发新证书，而不是改一行配置。

nebula-cert print -path host.crt 会显示实际签发的内容。在假定证书携带了你想要的地址之前，先读一读它。

重新加载并不总是足够

有些 PKI 设置会随信号重新加载，有些则不会。overlay 地址已变更的证书 就是需要重启进程而不是重新加载的典型案例。

确认运行中的进程实际打开了哪些路径，而不只是配置文件写了哪些路径。然后更换一项凭据，验证连通性和日志，之后才动下一项。旧证书留在内存里、重载却看似成功，会产生一种看着像路由问题的错配。重启很便宜；排查半个 overlay 仍按旧方式看待的身份可不便宜。

移除身份需要阻止名单

替换丢失或泄露的凭据有两半。新证书恢复访问，而旧身份必须停止被接受。这是两个独立操作，只做前一半会让已泄露的凭据继续有效。

阻止名单是你分发给主机的文件，而不是 lighthouse 自行推送的东西。规划它如何到达每个节点，包括今天离线的那些，并记录你阻止了哪些指纹。在签发机器上轮换密钥，并把新证书的细节与主机记录放在一起。只存在于你编辑过的那台机器上的吊销，不算吊销。