网关更换证书后，OpenConnect 为何拒绝它？

网关会更换证书，而昨天还能连接的客户端开始在第一次 TLS 交换时停住。消息给出的是验证原因而非网络故障，机器本身也没有变化，这才是有用的线索。坏掉的是现在出示的证书与客户端愿意采信的根证书之间的关系。修复它是信任决定，所以在输入某个选项之前先做这个决定。

在改动任何信任设置之前先读懂这次失败

缺少签名者一类的错误意味着证书链终止于客户端不接受的东西。它可能来自内部机构续签的证书、公共机构的替换证书，或者中间设备出示自己的证书。 仅凭措辞无法区分这些情况，所以在做出决定前先看签发者。

在前台运行一次连接并让它失败，因为交互输出带有服务器名称、签发链和客户端计算出的指纹。把这个签发者与你所在组织实际运营的机构对比。如果指纹变了而签发者没变，在通过你已经信任的渠道确认续签之前，应当视其为可疑。此刻去猜，正是人最终固定了拦截者密钥的原因。

在同一条记录里写下客户端版本。看起来像信任问题的大量失败，来自较旧的客户端遇到较新的网关交换。

在信任签发者与固定单个密钥之间选择

两种做法都能让连接成功。它们日后以相反的方式出问题，所以选择取决于你能承受哪种失败。

当证书来自你可以独立核实的机构时，选用 CA 文件，因为续签之后无需改动客户端参数即可继续工作。把它与禁用系统根证书的开关配合使用，否则公共机构就能替你满足该检查。反过来，当网关没有可获取的 CA，或目标就是尽可能窄的例外时，则固定密钥。抽象地说两者都不更安全：CA 能跨续签扩展，固定更容易审查。

无论选哪种，受信任的值都必须在改动发生之前就通过已经可信的渠道送达。管理员、网关上的控制台会话，或事先取得的副本，都算合格。复制提示里显示的指纹很方便，也恰恰是拦截者所期望的。

把值放进你真正启动的命令

固定信息写在服务器证书选项里，其前缀决定编码方式：sha1 或 sha256 下的十六进制公钥摘要，以及 pin-sha256 下的 base64 密钥固定。提供它还会为该次运行禁用系统信任，于是被固定的密钥就成了全部决定。

sudo openconnect --protocol=gp vpn.example.com --user alice \
  --servercert pin-sha256:AbCdEf...   # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trust

客户端按截短的摘要匹配，前缀之后只要四个字符也接受，这是陷阱而非便利。缩短的值在本地能通过，却仍然无法标识你想要的网关。复制客户端第一次尝试时打印的完整字符串，而不是从消息里重敲一遍。随后把成品选项移入启动连接的包装脚本、单元文件或配置档，让信任决定可以复查，日后的修改也出于有意。

桌面启动器和 NetworkManager 插件各自保存一份连接参数。在磁盘上改过的脚本到不了先前导入的配置档，所以保存的值继续占上风。

在不把自己锁在外面的前提下处理轮换

该选项可以给多次，因此计划中的变更能同时接受旧密钥与新密钥。在网关切换之前加入新的固定，在会话迁移期间把两者都列着，旧密钥消失后就去掉退役的那个。那个窗口需要有人负责，因为被遗忘的双重固定会让一个密钥在无人看守下继续被信任。会产生新密钥对的重建会打破纯粹的固定，而恢复就是反方向的同一套流程。

把变更日期写在固定旁边。没有复查日期的固定，是一场携带着令人困惑错误信息的未来故障。

在改动信任之前先排除客户端版本

过时的客户端在解析网关后来改动过的认证应答时可能失败，而表层消息仍只谈连接、不谈解析器。把已安装的版本与网关文档所述对比，并在改动任何信任设置之前，用一次性配置档测试当前软件包。

openconnect --version

修复之后，要核对两件事而不是一件：门户能通过隧道加载，以及普通内部地址有应答。完成握手只证明信任决定被接受了。