线上版本回滚后，团队常会问：旧版本以前已经签过名，能不能直接重新放回下载页？多数情况下可以，但前提是取回的是原来经过验证的签名制品，而不是重新编译出的“同版本”文件。两者的版本号可能相同，文件哈希和审计意义却完全不同。
先判断回滚属于哪一种情况
| 回滚原因 | 旧安装包是否可继续分发 | 签名处理重点 |
| 新版本存在功能故障 | 通常可以，需确认旧版本仍受支持且无已知严重漏洞 | 从可信制品库恢复原文件并复验签名 |
| 新版本发布配置错误 | 通常可以 | 核对安装包哈希，避免把配置错误带回旧包 |
| 构建环境被入侵 | 不能直接判断 | 扩大核查范围，确认旧包是否来自同一受影响环境 |
| 签名私钥疑似泄露 | 不应仅凭时间戳继续分发 | 暂停发布，联系 CA 评估吊销并识别异常签名 |
| 旧版本本身有高危漏洞 | 不建议继续公开分发 | 寻找安全补丁版本或限制为受控恢复用途 |
回滚应用版本不等于回滚数字签名
代码签名绑定的是具体文件内容。安装包只要有一个字节发生变化，原签名就无法继续证明该文件未被改动。因此，回滚时应恢复制品库中已签名、已测试、已发布的旧文件，同时恢复与它对应的哈希、发布清单和测试记录。
如果团队重新编译旧代码，即使版本号不变，也会生成新的制品。新的文件需要重新完成测试、审批和签名，不应借用原文件的签名状态。为了避免用户看到同一个版本号对应两个不同哈希，通常还要增加构建号或修订号。
可信时间戳解决的是证书到期问题
GlobalSign 对代码签名的说明指出，签名时加入可信时间戳后，文件在代码签名证书到期后仍可保持有效，前提是签名时证书有效，且文件没有被修改。时间戳并不能证明旧版本没有安全漏洞，也不能把使用泄露私钥生成的签名变成安全签名。
因此，证书到期与证书被吊销应分开处理。到期是正常生命周期事件；吊销通常意味着私钥泄露、错误签发或证书被用于可疑代码等风险。遇到后者，应依据CA 的调查和吊销规则评估受影响文件，不能只看安装包上是否有时间戳。
旧安装包重新上架前做四次核对
1. 核对来源。从只读制品库或已验证的发布归档恢复文件，不从个人电脑、群聊附件或临时网盘取包。
2. 核对哈希。将文件哈希与原发布记录、软件物料清单或下载页存档比对，确认取回的是同一个制品。
3. 核对签名。检查发布者名称、证书链、签名状态和时间戳，同时确认签名后文件没有被修改。
4. 核对风险。确认旧版本没有未修复的严重漏洞、被停用的依赖或已经失效的后端接口，并明确继续支持的期限。
下载页和更新服务需要同步调整
回滚并非只替换一个安装包。官网、应用内更新、镜像站、软件仓库和 CDN 可能保留不同版本。团队应以文件哈希作为识别依据，统一下架故障版本，并在下载页说明当前推荐版本及回滚原因。若客户必须保留问题版本用于取证，应放入权限受控的归档区，而不是继续公开分发。
更新服务还要防止“版本震荡”。例如客户端已经升级到故障版本后，回滚策略是否允许降级；旧版本启动后会不会再次拉取故障版本；自动更新元数据是否已经重新签名并同步到所有节点。这些问题与代码签名不同，却常在同一次回滚中出现。
私钥事件需要单独处置
如果回滚与签名系统异常同时发生，应立即停止使用相关证书继续签名，保存签名日志，并列出异常时段内所有签名文件。随后与 CA联系，确认是否需要吊销证书。已经签名的文件是否继续可信，应依据签名时间、吊销原因、验证平台规则和文件调查结果判断，不能用一条通用结论覆盖所有平台。
新证书签发后，不要无差别地把全部历史安装包重新签一遍。仍在维护且确有分发需求的版本，可以按风险和渠道重新构建或重新签名；已经停止支持的版本更适合保留验证记录并停止公开下载。
发布团队可以采用的记录格式
| 字段 | 记录内容 |
| 制品身份 | 产品名、版本号、构建号、文件名和 SHA-256 哈希 |
| 签名信息 | 发布者、证书序列号、签名时间和时间戳状态 |
| 回滚决策 | 回滚原因、批准人、推荐版本和支持截止日期 |
| 渠道状态 | 官网、更新服务、镜像站和合作分发渠道的上下架结果 |
| 风险结论 | 漏洞检查、私钥调查和证书吊销状态 |
对外发布时，最稳妥的做法是让每个版本对应一个不可变制品和一个可追溯哈希。这样，代码签名证明文件来源和完整性，发布记录解释为什么此刻仍允许分发。两类证据各自回答不同的问题。