OpenVPN 配置文件里有三个证书块：哪一个才是秘密？

你打开 .ovpn 文件只想改一行，却发现三段 base64，看上去全都像凭据。其中一段可以放心公开，一段和密码同样敏感，还有一段是公钥——除非有人用配对的私钥签过名，否则它毫无意义。因为这几段看起来可以互换，人们会把整个文件贴到求助帖里，客户端私钥就是这样流进公开存档的。弄清每段各干什么，能解释这类配置文件的大部分困惑，也能告诉你哪些故障该由你自己修。

一个文件，三个块，各司其职

典型配置文件会在 BEGIN 与 END 标记之间嵌入 ca 块、cert 块和 key 块，或者 分别指向三个独立文件。有些配置还会为 tls-auth 或 tls-crypt 密钥加第四块，那是共享密钥而不是证书。客户端按指令名读取对应的块，所以标签比它们出现的顺序更重要。

在真正看过内容之前，请把拼装好的配置文件当作敏感文件。公开证书和私钥可能在同一文件里只隔几行，一张连表头一起截的图可能把两者都带走。手工涂掉可见的 base64 也不可靠，因为残缺的块仍会泄露点名你部署环境的证书元数据。只复制三条指令而不带值，通常就够问出一个有用的问题了。

块周围的指令决定它们的用法。改了 ca，客户端就信任另一个签发机构；改了 cert 却没改 key，握手会因不匹配而失败，而这与信任毫无关系。

CA 块是公开的，CA 私钥永远不是

证书颁发机构为把公钥绑定到身份的证书签名，它自己的证书就是客户端判断整条链是否可信的锚点。这份证书按设计就是公开的：把它放进每个配置文件是常规做法，也正是自签名部署无需商业机构也能运转的原因。

绝不该出现在客户端配置文件里的，是机构的签名私钥。客户端验证任何东西都不需要它，而它一旦在场，拿到配置文件的人就能为整个部署铸造新身份。

信任一个机构，范围也比听起来窄。客户端接受由该 CA 签发的任何证书，也就会接受同一 CA 为别的服务签发的证书。把预期服务器角色或名字钉死的选项能补上这个缺口，而 TLS 选项参考 列出了负责此事的校验指令。

服务器证书和客户端证书指向相反的方向

服务器证书是客户端用来确认自己连对了端点的那一份。你的客户端证书方向相反：服务器用它来判断这台设备或这个用户是它登记过的。格式相同，信任方向相反。

地址不等于身份。连到正确的 IP 并不能证明对面是谁，因此 主机名或证书名校验仍然属于配置文件的一部分。账户密码也不会悄悄替代必需的客户端证书，因为两者在不同阶段校验，一个部署可以同时要求两者。

客户端私钥是必须保密的那一部分。如果它可能已经泄露，从你笔记本上删掉文件对服务器毫无影响，服务器会继续接受对应证书，直到运维方将其吊销。请运维方更换或吊销那个身份，才是唯一能带得走的补救。

两个长得一样、其实不同的提示

以加密形式保存的密钥，会先要一个口令短语，客户端才能使用。VPN 服务可能另外索要账户密码，两个提示可以相隔几秒出现，措辞几乎相同。口令短语保护的是你磁盘上的文件；密码是向服务器证明账户。把两者搞混，会把人送去根本帮不上忙的改密流程。

先读提示，再动手重置。账户密码重置对忘记的密钥口令、被吊销或过期的证书毫无用处；当故障是证书校验时重置密码，只会把两分钟的修复变成一张工单。如果投诉里提到有效期，先看设备时钟，再看那张被点名证书自己的时间窗。

证书确实过期时，替换只能来自签发方。别人的密钥不是续期途径，借同事一份能用的配置文件也不是。

一次干净的握手能证明什么，不能证明什么

完成 TLS 握手，说明配置好的身份关系成立了：服务器证书链到你的 CA，你的证书被接受。它并不说明运维方的日志政策，也不说明隧道起来之后你的应用能不能用。

路由和 DNS 是连接的后续阶段，所以登录成功后仍访问不到内网主机，是连通性问题而不是证书问题。去修那一层，别忙着换凭据；把配置文件交给别人时，请连来源、私密材料与身份校验一起交代。