时间边界

本报告依据本地处理记录整理。证书信任库处理记录的实际时间为：

2026-06-10 17:22-17:31 CST

桌面采集程序 URL 更新记录时间为：

2026-06-10 17:44 CST

触摸滚动修复记录时间为：

2026-06-10 18:00 CST

如果博客按“故障发生日”归档，而故障实际触发在 2026-06-09，可以把 2026-06-09 作为故障发生日，把 2026-06-10 作为修复和复核日。

事件摘要

灵初手套采集环境在切换 Keystone 地址后，需要访问新的 HTTPS 入口：

https://192.168.119.5/

该入口使用内部证书，证书的 Subject 和 Issuer 都是：

CN = keystone.factory.internal

也就是说，这不是公网浏览器默认信任的公开 CA 证书，而是工厂内网环境使用的内部证书。主机、Docker 容器和本地 Axon 镜像如果没有显式导入该证书，就可能出现 HTTPS 证书校验失败、浏览器信任提示、容器内请求失败，或下次重建容器后证书信任丢失等问题。

本次处理覆盖两台灵初手套采集机器：

处理目标不是简单让当前页面“能打开”，而是把信任链补齐到三个层面：

1. 宿主机系统信任库。

2. 当前正在运行的 Axon 容器。

3. 本地 Axon 镜像，防止容器重建后修复丢失。

证书信息

证书从 Keystone HTTPS 入口提取：

192.168.119.5:443

证书核心信息如下：

SAN 中包含 192.168.119.5 非常关键。现场访问方式使用 IP 地址，如果证书只包含域名、不包含 IP，即使把 CA 加入信任库，客户端仍可能因为 hostname/IP 不匹配而拒绝连接。

问题成因

这类问题通常不是服务端“没开 HTTPS”，而是客户端信任链不完整。具体到本次环境，有三个容易踩坑的点。

1. 内部证书不会被系统默认信任

公网浏览器和操作系统默认信任的是公开 CA 根证书。keystone.factory.internal 这种内部服务证书不会自动出现在系统信任库里。因此客户端访问 https://192.168.119.5/ 时，需要额外导入证书。

2. 主机信任不等于容器信任

采集程序运行在宿主机和 Docker 容器之间。即使宿主机已经信任该证书，容器内的 Debian/Ubuntu 信任库也不会自动继承宿主机证书。只修宿主机会导致容器内程序仍然可能报证书错误。

3. 当前容器信任不等于镜像信任

如果只进入当前运行容器执行 update-ca-certificates，当前容器可以恢复，但下一次用原始镜像重建容器时，证书又会丢失。这也是本次必须把证书写回本地 Axon 镜像的原因。

处置过程

1. 导入宿主机信任库

两台宿主机都写入证书文件：

/usr/local/share/ca-certificates/keystone-factory-internal.crt

随后执行：

sudo update-ca-certificates

这样宿主机上的浏览器、curl、Python requests、系统组件等才能通过系统 CA bundle 信任 Keystone HTTPS 入口。

2. 导入当前运行容器信任库

两台机器当前运行的容器均为：

ITW-release005-latest

容器内同样写入：

/usr/local/share/ca-certificates/keystone-factory-internal.crt

并在容器内执行：

update-ca-certificates

这一步保证当前容器内的采集组件、诊断命令、HTTPS 客户端能够立刻通过证书校验。

3. 更新本地 Axon 镜像

两台机器的本地镜像为：

docker-registry.psibot.net/synrobot/x86/release/1.0.1-axon:latest

本次通过临时容器更新 CA 后重新 commit 镜像，避免下次重建容器后证书丢失。

这个动作是本次修复中最容易被忽略、但最重要的一步。它把修复从“当前容器临时状态”提升为“本机后续容器重建仍然有效”的状态。

4. 更新桌面启动器 URL

两台机器的桌面采集程序启动项原来仍指向旧 Keystone 地址：

http://192.168.118.143:5174/

本次已更新为新 HTTPS 地址：

https://192.168.119.5/

涉及两个启动器路径：

/home/psibot/Desktop/start-tele-operation.desktop
/home/psibot/.local/share/applications/start-tele-operation.desktop

更新后，启动器会同时打开：

• 本机 HMI：http://localhost:8080

• Keystone：https://192.168.119.5/

修改前已在同目录生成：

*.bak_keystone_url_<timestamp>

这样如果新入口异常，可以快速对比或回退启动器内容。

5. 修复 Firefox 触摸滚动

在 sh01-dc93 上出现过 Firefox 页面无法通过触摸屏滑动的问题。排查后确认，问题与桌面启动器启动 Firefox 的方式有关：

如果 Firefox 复用了已有进程，新的环境变量可能不会生效。也就是说，即使启动命令里写了 MOZ_USE_XINPUT2=1，只要浏览器复用旧进程，触摸事件处理仍可能沿用旧配置。

最终两台机器的启动器都同步调整为：

• 启动采集程序前，后台延迟 3 秒打开 Firefox。

• 打开前先关闭当前用户已有的 Firefox 进程。

• 使用 MOZ_USE_XINPUT2=1 MOZ_ENABLE_WAYLAND=0 firefox --new-window。

• 同时打开 http://localhost:8080 和 https://192.168.119.5/。

这一步虽然不是证书本身的问题，但属于同一次入口切换后的客户端可用性修复。

验证结果

主机验证

两台宿主机的证书验证结果均为：

Verification: OK
Verify return code: 0 (ok)

当前容器验证

两台当前运行容器内的验证结果均为：

Verification: OK
Verify return code: 0 (ok)

本地镜像验证

两台本地镜像的一次性容器验证结果均包含：

/usr/local/share/ca-certificates/keystone-factory-internal.crt: OK

启动器验证

两台机器以下两个路径中的启动器内容已确认一致：

/home/psibot/Desktop/start-tele-operation.desktop
/home/psibot/.local/share/applications/start-tele-operation.desktop

并确认没有残留损坏的 Exec= 行。

为什么要同时修主机、容器和镜像

证书问题很容易被“局部修好”。例如：

• 浏览器能打开了，但容器内程序还是失败。

• 当前容器修好了，但下次重建又失败。

• URL 更新了，但证书没进系统信任库，用户仍看到安全警告。

因此，内部 HTTPS 入口切换时，推荐把修复边界定义为：

服务证书 -> 主机信任库 -> 运行中容器信任库 -> 基础/业务镜像 -> 客户端入口配置

只有这条链路都处理完，才算从根上解决“证书不被信任”的问题。

后续建议

1. 建立证书分发脚本

内部 CA 或内部服务证书应有标准分发脚本，至少覆盖：

• Ubuntu/Debian 主机的 /usr/local/share/ca-certificates

• Dockerfile 或镜像构建阶段的证书导入

• 运行中容器的临时修复命令

• 验证命令和回滚说明

2. 把证书有效期纳入巡检

当前证书到期时间为：

2028-09-06 09:42:29 GMT

建议至少提前 30 天告警，避免到期当天所有客户端同时失败。

3. 避免只记录“能打开”

证书类问题的验证不能只看浏览器页面是否能打开，还需要检查：

• openssl s_client 的 verify return code。

• 容器内证书链是否 OK。

• 应用日志中是否仍有 certificate verify failed。

• 容器重建后证书是否仍然存在。

4. URL 和证书要一起切换

本次旧入口是：

http://192.168.118.143:5174/

新入口是：

https://192.168.119.5/

这不仅是 IP 和端口变化，也是 HTTP 到 HTTPS 的安全模型变化。切换入口时，应同步检查证书、启动器、浏览器配置、容器配置和用户操作路径。

发布前脱敏建议

本文保留了内网 IP、主机名、镜像名和证书指纹，方便技术复盘。如果发布到公开博客，建议按需要脱敏：

• 将 192.168.*.* 替换成 Keystone 内网地址、采集机 A/B。

• 保留证书有效期和 SAN 的技术含义，但可隐藏完整 fingerprint。

• 不发布任何 SSH 登录方式、访问密钥、MinIO AK/SK 或私有仓库凭据。