AnyConnect 不受信任服务器警告：接受还是导入？

你把网关主机名粘贴进 AnyConnect，窗口变红或变白，弹窗问你是否信任一个客户端无法验证其证书的服务器。最自然的动作是点过去赶紧干活，而这恰恰是最该克制的反射。答案会写进该机器上的客户端首选项，并对之后的连接生效，所以这个弹窗其实是一次配置决策，只是穿着一次性警告的外衣。下面是我按客户端呈现顺序走的流程。

先看你实际遇到的是哪种警告

红色和白色不是外观差异。红色警告意味着配置文件或首选项被设成阻止不受信任的服务器，因此客户端在设置改变前拒绝继续；白色警告意味着只要你明确作答，它就放行。还有第三种情况看着像、行为却不同：证书已过期，客户端根本不会提供导入，因为导入并不能让它变有效。分清这三种只需一秒，却决定后面的一切。

这三种背后是一份很短的成因清单：网关证书自签名、终端不信任的私有 CA，或主机名不在证书的 subject alternative names 里。任何一种都会弹出同样的窗口，却需要不同的处理。

回答弹窗之前先读证书

从警告里打开证书详情，先看三个字段再动按钮。subject 和 SAN 应当写的是你真正想连的那台网关，签发者应当是你所在组织运营的 CA，有效期应当覆盖今天。然后把 SHA-256 指纹与你在本次连接之外取得的副本比对，比如内部文档页面或工单，因为从同一个弹窗里读到的指纹什么也证明不了。如果找不到独立副本，你就没有接受这个例外的依据。

这一步把实验环境和生产网关区分开来。在昨天刚生成自签名证书的测试机上，点过去是合理的。在用户接下来要输入凭据的企业网关上，一个你无法验证的证书就可能是像样的中间人架设，而客户端是唯一还在追问的组件。

搞清楚每个答案往信任库写了什么

对导入问题回答是，会把网关证书加入该机器上客户端的受信任存储。这不是一次会话的例外：之后的连接可以没有同样的提示就完成，这既是目的也是风险，因为屏幕上没有任何东西提醒任何人这个例外存在。回答否则只让本次会话继续登录。两条路都能连上，但只有一条改变了这台机器。

如果你在红色路径上，第一次尝试根本不是登录。文档记录的输入顺序是一行 connect，随后两次确认，它会改掉首选项然后退出；把它当成成功的脚本只是保存了一个设置，从未完成认证。证书导入的问题只在下一次尝试时出现，所以人们才会觉得这个提示时有时无。

这个顺序不只对手指重要，对自动化更重要。一个永远回答是的脚本回答，会在网关更换后继续工作，并继续信任接下来出现的任何证书。

按客户端提问的顺序写答案

当客户端警告但允许连接时，答案按固定顺序到来：connect、是（继续）、然后是导入问题、然后是组、用户名和密码。把这些写成输入文件里的独立行，而不是去猜提示出现的时机。拒绝导入只需在同一个文件里改一个字符，对于任何无人值守运行的东西都是更安全的默认值。

connect vpn2.example.net
y
n
GROUP
LOGIN
PASSWORD

与其教每个脚本接受叶子证书，不如把组织的 CA 分发到各终端。签发正确、SAN 正确的证书能为所有人消除提示，让验证保持有意义，也不依赖某一台终端对某个决定的记忆。安装根 CA 比导入叶子重得多，所以应当把它当成受管推广，而不是服务台的捷径。

清理掉活得比网关还久的例外

AnyConnect 按机器保存这些首选项，所以换过办公室的笔记本上会累积旧答案。审阅受管终端上保存的首选项和已导入的证书，检查某个例外是否还指向已经换了主人的主机名。一个接受任何不受信任服务器的首选项，比它当初为之创建的那张证书范围更宽。

值得保留的模式很窄：日常使用用受信任证书，临时例外用有记录的带外指纹核对，并由具名负责人在地迁移结束时清掉它。如果你在管理的机器上发现一个接受任何服务器的全局设置，把它当成一个发现，而不是一份便利。