Access Server 的 Web 证书错误：修复空的 CA 包

ca_bundle 为空或 PEM 损坏会让管理界面停摆。重启前把证书、私钥和证书链当作一个整体校验，不要动 VPN 的 PKI。

DNS 解析正常却打不开登录页，通常不是 DNS 的问题。如果服务日志提到证书包路径为空，或 Web 证书与私钥的 PEM 解析失败，说明 HTTPS 监听器没有可用材料，再怎么排查域名解析也无济于事。修复只涉及三个配置键，且完全不需要重签任何 VPN 客户端证书。

三个键究竟指向什么

自定义 Web 证书集由 cs.cert、cs.priv_key 和 cs.ca_bundle 描述。三项各存一个文件路径，Web 服务会把三者一起使用。证书配错私钥，或把叶子证书当成证书链，失败方式与空值完全一样：监听器凑不出浏览器认可的证书链。

这三个键属于管理端和客户端 Web 界面。它们 与给 VPN 客户端签发证书的 PKI 相互独立，所以替换时不必碰客户端配置、服务端私钥或 CA。把 Web TLS 故障当成重建整套 PKI 的理由，是这里最昂贵的错误。

一个区分能省时间：显式写成空值，与完全不做覆盖并不是同一种状态。前者把空路径交给解析器，日志提示的正是这种情况；后者让 Access Server 继续使用自带的材料，这也是升级后有的主机正常、有的不正常的原因。

为什么文件存在还是解析失败

解析器读的是文件内部的标签块，不是文件名。.crt 里塞了私钥、把整条链拼成一个块却按单张证书填写、或末行被截断的文件都会被拒绝。RFC 7468 规定这些可读标签，正是因为只有它们能告诉读者后面跟的是什么对象。

要看对象本身，而不是扩展名。在 Linux 主机上，openssl x509 -noout -subject -issuer -in server.pem 和 openssl pkey -noout -check -in key.pem 能回答两个关键问题，比较两者的模数或公钥即可证明它们配对。私钥输出不要贴进工单和聊天记录；校验需要的是指纹，不是私钥。

空路径和损坏文件一样值得怀疑，因为两者都会在下游产生含糊的报错。日志说包路径为空时，先读出存下来的值，再去调试那个文件。

有意识地回退到兜底证书

Access Server 的 CLI 自带校验，把三个路径作为参数传入即可判断这套材料是否可用。下面的路径只是示例，请替换成主机上的受保护位置。

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

先看结果，再动正在运行的服务，然后才导入数值，并按已安装版本文档化的操作生效。官方 CLI 教程 覆盖校验、导入配置库和生效步骤，其版本比任何摘要都重要。

验证用户真正输入的域名

如果自定义材料已损坏，而有效的内置兜底材料还在，文档化的恢复方式是删掉这三个覆盖项，让 Access Server 用回兜底。动手前先准备好控制台访问和当前配置的备份，因为要重启的正是提供管理界面的那个服务。

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

清空整个配置库不是修证书。只针对这三个键，生效后确认 Web 界面能响应。web-ssl 目录下的自签文件是兜底资源，不是草稿区：覆盖或重新生成它们，可能让主机失去唯一能用的材料。

兜底生效后，浏览器会显示另一张证书，这是正常结果。正确的做法是通过可信的管理流程去确认，而不是教用户以后忽略所有警告。

登录成功才算恢复完成

出现 TCP 监听不等于恢复完成。要校验 DNS 名称、证书身份和该名称对应的证书链，再打开管理端与客户端两个 Web 界面并完整登录一次。端口探测证明不了这些。

Access Server 3.1 及更高版本还能按 SNI 主机名提供不同的 Web 证书。若已这样配置，默认键与主机名专属条目是两套材料，用 IP 地址测试很容易看到与用户实际拿到的不一样的证书。修好并校验出错名称的那一套，关闭事件前再重复一次登录测试。

相关文章