Quarkus 证书从 A 换 B 再恢复 A，服务仍提供 B

Quarkus 的 HTTPS 证书从 A 切到 B 正常，恢复启动时那份原封不动的 A 后，服务却继续出示 B，这是一个与热加载比较基准有关的故障。先确认连接拿到的证书确实来自这个应用实例，并使用新的 TLS 连接检查，避免复用已有连接造成误判。

该问题有 Quarkus 3.39.2、通过 quarkus.http.ssl.certificate.* 配置文件证书并开启 reload-period 的具体案例。最有用的定位顺序是 A→B→A：前半段证明重读配置已生效，后半段要求 A 的证书和私钥内容与启动时完全一致。重新生成同 subject 的另一张证书不能代替这个对照。

受影响实现把每次读到的 SSL options 与启动快照比较。A→B 时两者不同，服务器更新为 B；但比较基准仍是 A。恢复 A 后，文件看起来“与启动相同”，更新被跳过，当前服务器继续保持 B。

Quarkus 3.40.1 已包含当前状态跟踪：重读时对比 currentSslOptions，服务器更新 SSL options 的异步调用成功后，再把 holder 更新到这次结果。更新失败不前移这个基准。通过项目现有 Quarkus 平台版本入口升级到包含这项处理的版本，重建并重启，让应用使用新运行代码。

测试环境可保留原文件配置，例如：

quarkus.http.ssl.certificate.files=cert.pem
quarkus.http.ssl.certificate.key-files=key.pem
quarkus.http.ssl.certificate.reload-period=30s
quarkus.http.ssl-port=8443
quarkus.http.insecure-requests=disabled

准备两套证书，分别保存 A、B 的原始证书及对应私钥。启动时把 A 放在配置路径，确认生效后，按部署已有的安全替换方式一起切换证书与匹配私钥到 B，等待至少一个 reload 周期；最后把保存的 A 原字节恢复，再等待一个周期。不要在生产验证中混用两套证书与私钥，或降低客户端验证要求来规避错误。

每一步用一个新连接观察服务端证书：

openssl s_client -connect localhost:8443 -servername localhost </dev/null   2>/dev/null | openssl x509 -noout -fingerprint -sha256 -enddate

这条命令用于检查出示的证书指纹，不等于完成信任链或主机名校验。测试需先知道两套证书的预期指纹，并按应用既有 CA 信任配置另外验证 HTTPS 请求。验收是依次出示 A、B、A，且恢复后业务请求仍正常；“文件已经复制回去”或“日志没有报错”都不够。

这个故障针对非 TLS registry 的文件重载路径。quarkus.tls.* registry 的证书 holder 使用另一条重载路径，不能从本例推断同样受影响。若 A→B 本身就失败，先查配置路径、权限、格式与证书私钥匹配，再考虑这里的 A→B→A 状态问题。