01确认访问的名字与证书一致
证书中的 Subject Alternative Name 应包含浏览器访问的域名。直接用 IP 地址测试域名证书，可能出现名称不匹配，这与服务是否正常启动是两个不同的问题。
一台服务器可以托管多个 HTTPS 站点。客户端在 TLS 握手中提供服务器名称，服务据此选择配置与证书；测试时应带上预期的域名。
02检查服务实际返回的证书
磁盘上的证书已经更新，不代表运行中的服务已经加载。可以从另一台机器建立 TLS 连接，检查返回证书的域名、签发机构与到期时间，再与服务器上的文件核对。
部署时通常应提供完整证书链。仅在本地浏览器里成功，不一定意味着所有客户端都能完成链验证，尤其当本地已经缓存了中间证书时。
03续期验证方式必须与部署相容
HTTP 验证需要外部能够访问约定的验证路径。如果证书工具依赖临时启动的独立服务，而正式 Web 服务后来占用了同一个端口，续期可能失败。使用 Web 根目录验证时，应单独保留挑战文件路径。
DNS 验证则依赖 DNS 服务的权限和记录更新。两种方式没有普遍适用的优劣，关键是自动化流程在下一次运行时仍具备相同条件。
04让续期和重载成为完整流程
定时器负责发起续期，部署钩子负责在成功后重载服务。重载之前先检查配置语法，避免把无效配置带入运行环境。测试环境签发的证书不能代替浏览器信任的正式证书。
安排模拟续期，并单独核对部署钩子的行为。再配合证书到期提醒，就能把“已经申请过证书”变成一项可持续运行的维护流程。