APK 签名证书过期会怎样影响安装与升级

直接答案：先判断 signer 连续性，再判断日期风险

APK 签名证书包含有效期字段，工程团队应持续监控，但 Android 应用更新首先依赖包身份和兼容签名关系。看到 NotAfter 已过或临近，不能立刻写成所有设备无法安装；看到日期尚远，也不能写成更新一定连续。要把证书日期、APK 内签名方案、signer 摘要、轮换 lineage、渠道责任和目标系统放在同一审查表。

最小验收对象是最终 APK，不是 keystore 文件名、构建配置或后台截图。先计算候选 SHA-256，使用固定版本 apksigner 保存方案和证书输出，再与允许证书清单比较。随后选择准确历史版本，在声明支持的系统上分别做全新安装和原位升级，任何重新构建或重新签名的替代包都不能代表用户历史状态。

日期风险仍需提前治理。证书过期可能影响工具、渠道政策、未来签名操作或特定平台路径，密钥丢失则可能直接破坏更新能力。团队应在到期前完成角色盘点、轮换方案、历史升级矩阵和应急发布演练，但结论必须基于实际回执，不能把网站 TLS 证书的 CA 验证逻辑机械套到 APK 身份。

证书有效期、签名身份和私钥可用性是三个问题

证书有效期是公开元数据，描述签发者设定的时间范围；签名身份由证书公钥及其摘要参与建立；私钥可用性决定团队能否继续签署新候选。三者不能混写。证书尚未到期但私钥丢失，更新风险可能更紧迫；私钥仍存在但证书角色或渠道策略不接受，也不能正常发布。

Android 应用通常使用开发者控制的签名证书，不以网页浏览器的公共 CA 信任链作为应用身份基础。审查重点是平台对 APK 签名方案、证书连续性和轮换证明的验证结果。文章不从这一差异推导所有过期证书都可继续使用，而是要求按实际 SDK、渠道和工具版本验证。

证书摘要必须使用完整 SHA-256 等明确表示并防止截断混淆，Subject、Alias 或文件名只供展示。允许清单记录 artifactRole、当前 signer、历史 signer、轮换状态和批准来源。发现未登记摘要时失败关闭，不应因名称相似或有效期更长自动替换生产身份。

应用签名密钥与上传密钥必须分开治理

Android 发布文档区分应用签名密钥、上传密钥、证书和 Play App Signing 责任。启用商店托管后，开发团队上传的工件身份与最终设备交付签名可能承担不同角色。到期盘点若只检查本地 upload keystore，就无法说明用户设备上应用 signer 的日期、摘要和轮换状态。

每条分发路径都要写明谁持有应用签名密钥、谁接受上传证书、设备最终看到哪个 signer，以及证书或上传凭据如何恢复。直接分发、企业渠道和商店分发可能不同，不能共享一张没有 artifactRole 的证书表。平台后台状态必须与实际下载 APK 的 apksigner 输出交叉核对。

上传密钥轮换通常解决提交身份问题，不应被报告为设备安装身份已轮换。相反，应用签名密钥轮换涉及平台能力、lineage、最低系统和历史安装基础。变更单必须明确目标角色，审核者拒绝使用“已换证”这种没有对象、摘要和渠道的模糊结论。

更新连续性由包名、版本和兼容 signer 共同决定

Android 更新要求保持 applicationId、兼容签名或轮换证明，并使用可接受的 versionCode。证书日期只是输入之一。真正的升级测试以设备上已安装历史包为起点，保留应用数据，不先卸载，再安装最终候选并核对 Package Manager 结果和更新后的 signer。

全新安装成功不能代表升级成功，因为卸载会清除历史签名状态。反过来，一条历史路径失败也不等于所有设备都失败，可能与 SDK、旧证书、lineage 或渠道包有关。矩阵应按旧包摘要、旧 signer、设备 API、新包摘要和新 signer 记录，避免只按版本名聚合。

versionCode 更高和证书 NotAfter 更晚都不能修复不兼容 signer。若没有被平台接受的轮换证明，使用新私钥重签同包名通常会成为不同身份。团队不能为解决日期焦虑临时生成新证书并覆盖发布，而应先验证可用轮换机制、支持范围和渠道流程。

v3.1 轮换要围绕最低 SDK 和历史安装基础验证

APK Signature Scheme v3.1 描述签名轮换、最低轮换 SDK 和与 v4 的关联。轮换不是把新证书塞进配置就结束，而是需要生成符合方案的身份演进材料，并让不同平台按其能力选择兼容 signer。矩阵至少覆盖轮换边界前、边界本身和边界后。

对于边界以下系统，发布策略可能仍需要旧 signer 路径；对于支持轮换的系统，新安装和从旧包升级也可能观察不同身份状态。验证报告应记录每个 SDK 的 apksigner 方案结果、设备 Package Manager 结果和实际 signer，不能用最高系统的一次成功填平矩阵。

历史安装基础还受渠道影响。若用户曾从不同商店、企业 MDM 或直接下载获得同包名但不同 signer，轮换计划可能无法覆盖。上线前需要从真实渠道归档准确历史 APK，禁止用当前源码重新构建同版本作为替代，因为字节和身份可能不同。

证书到期治理要提前建立不可变证据和告警

证书台账至少包含角色、完整摘要、NotBefore、NotAfter、算法、持有人、存储位置类别、备份验证日期、使用渠道和关联 applicationId。私钥位置只记录受控标识，不把密钥、口令或云凭据写进报告。告警应给轮换设计、渠道审批、历史测试和回滚留出充足时间。

到期演练不是修改系统时间后看 App 能否启动。应使用公开证书元数据检查告警逻辑，使用测试签名环境验证工具与渠道行为，再对生产身份只做非破坏性读取。任何签名、轮换或后台变更都必须经过明确授权，不能为了“试一下”重签冻结候选。

应急计划要区分密钥泄露、密钥丢失、证书临近到期、上传凭据失效和应用 signer 轮换失败。不同事件需要不同权限和平台协调。把所有情况归为证书过期会延误处置，也容易产生错误重签。每次演练保存输入、命令、输出和责任人审批回执。

apksigner 输出是静态证据，真实设备升级才是闭环

apksigner 可以验证 APK 的签名方案与证书，并输出 signer 证书信息。流水线应固定 build-tools 版本，保存完整输出、退出状态和候选摘要。证书元数据可用于日期告警，方案输出用于 SDK 范围判断，但命令成功不证明 keystore 治理、渠道交付或历史升级正确。

设备测试要绑定精确基线和候选。记录旧包与新包 SHA-256、证书摘要、API、型号、系统构建、安装命令、退出状态、Package Manager 错误、数据保留、首次启动和关键流程。仅出现启动页、安装命令退出零或模拟器通过都不能登记完整连续性。

发现失败时先分类：日期或工具政策、signer 不兼容、lineage 缺失、versionCode、渠道工件、split 集合、设备存储或业务迁移。只有证据指向签名身份时才归入连续性问题。这样的归因可以避免把加固、证书日期和应用崩溃混成一个模糊故障。

用公开证书元数据生成到期与连续性审查表

下面的 Python 示例读取公开安全的 JSON 回执，包含评估日期、证书有效期、SHA-256、签名方案、轮换信息和 apksigner 退出码。它验证日期格式、摘要长度、方案字段和工具状态，计算到期观察值，并输出必须继续执行的历史升级与渠道检查。

脚本不读取 keystore、私钥、口令或 APK 内容，也不会签名和安装。expired 只被记录为日期状态，不自动写成 Android 安装失败；apksigner 非零、摘要不合法或证据字段缺失则失败关闭。生产环境可从已脱敏的工具输出生成这份结构化投影。

输出通过表示元数据完整且静态验签记录成功，不代表证书角色正确、私钥仍可用或用户可连续升级。下游仍需与允许 signer 清单、平台后台和设备矩阵交叉验证。任何候选变化都要重新产生回执，不能只更新日期字段。

import json
import re
import sys
from datetime import date
from pathlib import Path

if len(sys.argv) != 2:
    raise SystemExit("usage: review_signer_metadata.py public-receipt.json")
receipt_path = Path(sys.argv[1]).resolve()
if not receipt_path.is_file():
    raise SystemExit(f"receipt missing: {receipt_path.name}")
with receipt_path.open("r", encoding="utf-8") as stream:
    receipt = json.load(stream)
if not isinstance(receipt, dict):
    raise SystemExit("receipt root must be a JSON object")

required = {"evaluated_on", "not_before", "not_after", "certificate_sha256", "schemes", "rotation", "apksigner_exit"}
missing = sorted(required - set(receipt))
if missing:
    raise SystemExit(f"missing fields: {missing}")
try:
    evaluated = date.fromisoformat(receipt["evaluated_on"])
    not_before = date.fromisoformat(receipt["not_before"])
    not_after = date.fromisoformat(receipt["not_after"])
except (TypeError, ValueError) as error:
    raise SystemExit("certificate dates must use YYYY-MM-DD") from error
if not_before > not_after:
    raise SystemExit("certificate validity range is reversed")
digest = str(receipt["certificate_sha256"]).replace(":", "").lower()
if not re.fullmatch(r"[0-9a-f]{64}", digest):
    raise SystemExit("certificate_sha256 must contain 64 hexadecimal characters")
if not isinstance(receipt["schemes"], dict) or not receipt["schemes"]:
    raise SystemExit("schemes must be a non-empty object")
if receipt["apksigner_exit"] != 0:
    raise SystemExit("apksigner verification did not succeed")
if not isinstance(receipt["rotation"], dict):
    raise SystemExit("rotation must be an object")

days_remaining = (not_after - evaluated).days
status = "expired" if days_remaining < 0 else "active"
report = {
    "date_observation": {"status": status, "days_remaining": days_remaining},
    "certificate_sha256": digest,
    "verified_schemes": receipt["schemes"],
    "rotation_metadata": receipt["rotation"],
    "still_required": [
        "match the signer against the approved role and channel",
        "verify exact historical APK upgrades across the SDK matrix",
        "confirm Play or direct-distribution signing responsibility",
        "record private-key recovery and rotation evidence separately",
    ],
    "boundary": "certificate date alone is not an install or upgrade verdict",
}
print(json.dumps(report, ensure_ascii=False, indent=2, sort_keys=True))

发布结论必须绑定真实候选、历史包和渠道责任

NIST SP 800-218 SSDF 强调来源、构建、验证和变更证据。证书连续性证据包包含最终 APK 摘要、apksigner 输出、允许 signer、证书日期、密钥角色、lineage、历史包、SDK 与设备矩阵、渠道后台回执、失败归因和回滚路径。

公开结论只能覆盖实际测试。例如可以登记某历史包在某设备升级到某候选成功，不能写成证书过期完全无影响、全部用户可升级或密钥永不丢失。没有项目回执时，不提供客户、性能、兼容、攻击阻断、排名或收录数字。

证书角色盘点可结合[调试证书发布门禁](/zh-cn/articles/debug-certificate-release-gate/)，避免把测试 signer 混入连续性评审。需要提交候选和历史包，可从[御盾中央平台申请加固服务](https://www.leonadev.com/console/)。登录、注册、价格、购买和控制台统一由中央平台承接，私钥与口令不得上传。

• 最终 APK 与所有历史基线均记录不可变 SHA-256
• 证书摘要、NotBefore、NotAfter 和签名方案来自实际候选
• 应用签名密钥、上传密钥和证书角色明确分开
• 允许 signer 与轮换 lineage 有审批和完整摘要
• 新安装与原位升级分别覆盖 SDK 和渠道边界
• 任何测试都不重新构建或重签历史基线
• apksigner、平台后台和设备结果保持不同证据等级
• 到期、丢失、泄露与轮换失败使用不同应急流程