先画清证书、私钥与描述文件的依赖链
收到证书即将到期的提醒时，先不要把问题简化成“应用还能不能打开”。一个发布构建至少涉及团队中的签名证书、本机或受控构建环境中的私钥、App ID，以及为具体分发目的生成的 provisioning profile。证书负责证明签名身份，描述文件则把 App ID、可用证书、设备或分发条件组合到一起。
建议为每条发布链建立一行资产记录：证书类型与序列号、到期日、私钥保管位置、关联 App ID、描述文件名称与到期日、对应构建用途。这样在替换证书时，可以准确找到需要重新生成的描述文件，也能避免误删仍由其他发布任务使用的资产。
- 记录证书类型、序列号、到期日与私钥保管责任人。
- 列出每个描述文件关联的 App ID、证书和分发用途。
确认分发证书的团队归属与操作权限
Apple 官方说明区分开发证书和分发证书：前者属于个人，后者属于团队。处理 Apple Distribution 证书时，不能只看某台 Mac 的钥匙串中是否存在证书，还要确认当前账号所在团队、证书创建人以及哪些构建机持有配套私钥。证书文件存在但缺少私钥，仍不能完成签名。
在多人团队里，把创建、导出和撤销权限纳入变更记录尤其重要。Apple Developer 账号中的 Account Holder 或 Admin 可以创建分发证书；撤销前也应确认操作者角色与影响清单。若只是准备换证，可以先创建并验证新资产，再决定旧证书何时退出具体发布流程。
- 核对当前登录团队，避免在同名证书之间选错。
- 确认有效证书与对应私钥同时存在于受控构建环境。
把到期和撤销作为两种不同事件处理
证书到达有效期终点与成员主动撤销证书，都可能使该证书不能继续承担新的签名任务，但处置步骤和发生时点不同。到期通常可以提前排期，撤销则可能源于私钥泄露怀疑、人员交接或资产清理。任何情况下，都应先确认 Apple Developer 后台显示的证书类型与状态，再评估关联描述文件。
不要用“撤销后所有安装都立刻失效”作为统一结论。Apple 对 App Store、企业内部 App、Developer ID、推送和 Wallet 等证书分别说明后果。本文聚焦 iOS 分发，仍需要按实际分发路径判断：新构建能否继续签名、待提交构建是否需要重做、已分发版本是否受到影响。
- 记录事件是计划到期、主动撤销还是异常处置。
- 按分发渠道分别确认新构建、待提交构建和已安装版本。
撤销证书后先定位变为无效的描述文件
Apple 明确指出，包含已撤销证书的 provisioning profile 会变为无效。此时重点不是反复下载同一个旧文件，而是打开相关 profile，替换为有效证书并重新生成。团队应从证书反向查找所有关联 profile，包括 Ad Hoc、App Store Connect 以及其他仍在使用的分发配置。
重新生成后，要让构建环境实际使用新文件。手动签名项目可以检查 profile 名称、UUID 与到期日；自动签名项目则应确认 Xcode 获取到满足当前 Bundle ID、entitlements、设备与证书要求的最新配置。完成一次归档或真机验证后，再把旧 profile 从构建缓存和交付说明中移除。
- 从已撤销证书反查全部关联 provisioning profiles。
- 重新生成后核对构建实际选择的 profile，而不只确认下载成功。
按 App Store 与内部 App 区分后续影响
对于 App Store 分发，Apple 的证书概述说明：在开发者计划会员资格有效的前提下，商店中已有 App 不会仅因 iOS Distribution 证书到期或撤销而受到影响；但团队不能再用该证书上传新的 App 或更新。已上传但尚未提交审核的构建，如果使用了被撤销的证书，可能被标记为无效二进制文件。
企业内部使用的 iOS Distribution 证书则有不同说明：使用该证书签名的内部 App 可能无法继续运行，需要分发以新证书签名的版本。因此，资产台账必须写明分发类型，不能只记“Distribution”。如果现场条件与官方文档描述不完全一致，应以账号状态、具体证书类型和 Apple 当前说明为准。
- App Store 已上架版本与新上传任务分别核对。
- 内部 App 要安排新证书签名版本的交付与验证。
在到期前完成新证书与新描述文件的并行验证
到期前检查的目标不是单纯把日期抄进日历，而是验证替代链路可用。建议在发布窗口之外创建或取得新的有效分发证书，确认私钥被安全保存，再为目标 App ID 编辑或重新生成所需描述文件。随后用与生产一致的构建配置完成归档，并记录归档所用证书和 profile。
并行验证期间不要急于撤销旧证书。先确认新构建能完成签名、安装或上传前检查，并让另一名团队成员复核资产标识。若团队同时维护多个 App，可按最近发布日和 profile 到期日排序迁移，减少一次性变更多条发布链造成的混淆。
- 新证书、私钥、新 profile 和新归档需要形成完整闭环。
- 用证书序列号或 SHA-1 标识记录实际签名资产，避免只看显示名称。
App 服务变更后同步重新生成描述文件
证书没有到期并不代表描述文件始终有效。Apple 说明，在 App ID 上启用或停用 App 服务会使相关 provisioning profile 需要重新生成；profile 自身到期时也要重新生成，并用新 profile 重新签名 App。Push Notifications、iCloud、App Groups 等能力还可能包含额外配置对象，变更时要一并核对。
因此，发布前检查应同时比较 App ID 当前允许的 capabilities、Xcode target 中启用的 capabilities 与 profile 中的 entitlements。若最近改过功能开关、团队证书或设备列表，应把“重新生成 profile”列为明确步骤，而不是等到安装或提交阶段出现错误后再处理。
- 记录近期 App ID capabilities 与服务配置变更。
- profile 到期或相关服务变更后重新生成并重新签名。
用一份可复核的发布前清单收尾
正式发布前，由未执行换证的人复核一次：开发者计划会员资格是否有效，选中的证书是否为目标团队且未过期，构建机是否持有私钥，profile 是否有效并包含正确 App ID 与证书，归档使用的签名方式是否符合当前分发路径。复核结论应附上时间和资产标识。
最后保留新旧资产切换记录、一次成功构建的归档信息以及 Apple 官方文档链接。旧证书或旧 profile 是否删除，应依据团队保留策略和当前依赖决定；不要为了让列表看起来整洁而提前清理。这样下一次到期提醒到来时，团队可以直接沿用已验证的检查顺序。
- 由第二人复核证书、私钥、App ID、profile 与分发路径。
- 保存一次成功归档的签名摘要和变更时间。