那把已公开的 OpenVPN 密钥是 CA、对端密钥还是 tls-auth？

有人报告说 VPN 密钥已经公开，而这句话背后其实藏着三种完全不同的情况。它可能是每个客户端本就该持有的 CA 证书，可能是绝不该离开某台机器的私有身份密钥，也可能是 两端都必须持有的控制通道共享密钥。修复方式、紧急程度和影响范围在每种情况下都不同，所以第一件事是分类，而不是行动。类别判断错了，后面每一步都是白费力气。

从指令入手，而不是从文件名入手

读取当前生效的配置，找出是哪条指令指向了相关材料。OpenVPN 的 TLS 选项用 ca 指定受信任的证书材料，用 cert 指定本地对端证书，用 key 指定与之对应的私钥。

文件名证明不了任何事。名为 key.pem 的文件里可能装着证书，而配置文件中的内联块也可能与磁盘上的独立文件内容完全相同。打开文件看它的头部，而不是相信文件名。仅这一项检查就能消除报告中的大部分歧义。

如果配置是 PKCS#12 包，请在受控位置解包，看看里面到底装了什么。一个包可以同时携带证书、证书链和私钥，这意味着包一旦泄露，三者就一起泄露。

在任何人改动文件之前先把分类写下来：对象、指令、哪些对端持有、谁能读取。后面的整段处置都取决于这句话。

CA 证书本来就是用来分发的

公开的 CA 证书属于信任材料。客户端需要它来验证服务器，分发它属于正常操作而不是事件。公开它并不会公开 CA 的私有签名密钥，而恰恰是那个对象才会让攻击者能够伪造新身份。

这个区别值得在工单里写明，因为两者经常被混为一谈。要回答的问题是：泄露的文件是证书还是签名密钥，看一眼文件内容就能定论。证书里含有公钥和签名；签名密钥根本不会出现在证书里。

分发仍然需要小心。客户端应当通过批准的配置文件下发渠道获取证书，而不是从粘贴网站获取；通过不可信途径送达的证书可能在途中被替换。

对端密钥和 tls-auth 密钥不是一回事

对端的私钥属于身份材料。一旦被复制，服务器就无法再区分预期设备与任何持有副本的人，因为被证明的属性正是独占持有。是否继续授权、是否更换，是 VPN 所有者的决定，而不是发现文件的人的决定。

tls-auth 密钥是第三种东西。它在控制通道数据包外层增加 HMAC 认证，使认证不通过的数据包在 TLS 交换之前就被丢弃；它既不是对端私钥，也不是加密应用数据的密钥。

如果这个共享密钥已经公开，它提供的屏障对所有持有者都已消失。但这并不意味着每个持有者都能通过其后的证书与用户校验，所以分类比警报级别更重要。说清楚倒掉的是哪道屏障，以及还剩下哪些。

修的是泄露的那个角色，不是旁边的角色

共享密钥不能靠改名或隐藏下载链接重新变成秘密。更换意味着生成新值，并在一次协调变更中分发到每个对端；只换一侧，就会让仍持有旧值的所有人之间的约定失效。

如果对端身份已经暴露，请对该身份走运营方的吊销与重新登记流程。修改一个无关账户的密码并不会让已复制的证书失效，替换 tls-auth 文件同样不会。

在依赖上述任何一项之前，先确认已部署的服务器实际强制执行了什么。一份不刷新的吊销列表，或在故障期间被关闭的角色校验，会完全改变结论。要读正在运行的配置，而不是仓库里的副本。

用过去的条件来评判过去的流量

仅凭一份暴露的文件，并不能判断此前抓取的会话能否被解密。这取决于密钥建立方式、暴露的材料以及存在哪些记录；没有这些事实，「全部流量都丢了」和「什么都没发生」都只是猜测。

在询问凭据属于哪一类时，不要再贴出另一份副本。改为通过批准的支援渠道分享指令名称和非机密元数据。

有用的结论会点明对象、它的角色、失去的保护以及需要协调的行动。比这更短的只是标题，而不是评估。