Developer ID 证书到期，Mac CI 迁移应先核对证书颁发机构，再为受影响的 Developer ID Application 和 Developer ID Installer 准备 G2 替代证书，在隔离流水线分别验证应用与 pkg 后分批切换。Apple 说明，2027 年 2 月 1 日起，受影响证书签署的 pkg 将无法安装；带安全时间戳且已公证的既有 Mac 软件仍可继续工作。 Apple 的公告给出了日期与处理边界。
适合负责 macOS 应用或安装包签名发布、企业 Mac CI 与发布基础设施的工程负责人。
管理 Apple Developer 团队证书与私钥的账号负责人，也可据此安排核验、替换和验收。
最后更新于 2026 年 10 月 4 日；到期日期、证书识别和处理边界核对自 Apple 公告及 Developer ID 证书替换指引。
盘点节点与签名资产
先做一次可复核的资产盘点，不要只在 Apple Developer 账号页面查看证书名称。旧、新颁发机构可能存在名称相同的证书；CI 中还可能有多个 Keychain、不同服务账号和独立签名脚本，导致控制台上已准备替代证书，生产作业却仍在使用旧身份。
在每个 Mac CI 节点和签名流水线记录以下内容：
- [ ] 节点、构建作业与责任团队；标出生产、测试及临时签名环境。
- [ ] Keychain 名称、证书身份、对应私钥的存放位置和访问控制方式。
- [ ] 应用产物、安装包产物，以及分别执行签名的流水线步骤。
- [ ] 每份证书关联的 Team、类型、到期日和颁发机构证据。
- [ ] 哪些作业执行公证提交、票据装订和最终分发。
这里要分清三类容易混淆的对象：Developer ID Application 用于签署 Mac 应用代码；Developer ID Installer 用于签署 Mac Installer Package；Apple Distribution 属于另一种分发证书，不可因为名称里有 “Distribution” 就拿来替代 Developer ID Installer。 Apple 的证书说明区分了前两者的用途；Apple 的证书类型概览则说明不同证书类型对应不同分发场景。
核实旧 Sub-CA 的影响
怎么判断 Developer ID Application 或 Installer 是否来自旧 Sub-CA？先把证书导入的 Mac 上“钥匙串访问”作为核验入口，在证书详情中展开颁发者的名称，检查 Organizational Unit。Apple 的替换说明指出：受影响的证书会显示 Apple Certification Authority，当前 G2 颁发的证书会显示 G2。不要只凭证书名称或到期日下结论；Apple 提醒，到期日在 2027 年 2 月 1 日或之前的证书“很可能”受影响，但应核对颁发机构确认。
还要确认检查的是团队自己的 Developer ID 证书，不是钥匙串里名为 Developer ID Certification Authority 的中间证书。特别是多个证书名称相同时，应把证书类型、序列信息和颁发机构一起留档，避免只按名称删除或替换。
应用与安装包也必须分别判断：
- 既有应用：Apple 说明，已签名、已公证并带安全时间戳的软件继续有效，不需仅因这次 Sub-CA 到期而重签。未来更新则要改用新证书，并在签名与公证流程中包含安全时间戳。
- pkg 安装任务：受影响的 Developer ID Installer 证书签署的 pkg，在 2027 年 2 月 1 日之后将无法安装。因此，不能把“应用已经公证”当成安装包证书无需更换的依据。
- 证书与签名不是一回事：替换证书不会自动重签历史产物，也不会自动修改流水线中的签名身份。需要确认实际交付的 pkg 和未来构建任务已切换。
带安全时间戳并已公证的既有 Mac 应用要重新签名吗？按 Apple 对这次到期的说明，既有软件继续工作，无需仅为 Sub-CA 到期而重签；但未来发布的新版本或更新，应使用替代证书，并按公证要求保留安全时间戳。遇到撤销证书、配置文件或应用本身问题时，应单独排查，不能把它们与此次到期影响混为一谈。
申请替代证书并准备并行环境
替代证书应按原任务类型分别准备：原本签应用的流水线申请 Developer ID Application，原本签 pkg 的流水线申请 Developer ID Installer。两种证书互不替代，存在两类签名任务时就要分别规划。Apple 的账户帮助说明，每个团队最多可创建 5 个 Developer ID Application 和 5 个 Developer ID Installer 证书；申请前应先核对现有数量及账号权限。申请步骤与证书数量限制见 Apple 账户帮助。
按这个顺序准备：
- 由有权限的账号负责人确认团队账号状态、需要替换的证书类型及可用证书名额。
- 按 Apple 流程生成证书签名请求并申请替代证书；若出现中间证书选项，明确选择 G2 Sub-CA。
- 导入证书后检查证书链和私钥是否成对存在，不要仅以证书文件已下载作为准备完成。
- 遵循团队既有凭证管理规则，控制私钥的访问主体与存放位置；不把私钥提交到源代码仓库、构建产物或普通日志中。
- 在隔离的 Mac CI 节点或不影响生产的流水线中配置新身份，保留当前生产身份，避免测试误覆盖正式签名配置。
Apple 指出，创建新证书时应选 G2 Sub-CA；若使用 Xcode 11.4 或更早版本，申请前需升级。其公告还说明，G2 颁发机构有效至 2031 年，但由其签发的证书按年到期、需要每年续期。机构到期日与单张证书有效期不是同一件事，因此切换完成后仍要纳入常规续期日历。
隔离验证应用与 pkg 签名
验证应按产物类型拆开做，并用真实的 CI 服务账号运行。管理员在交互式登录会话中看到证书，不代表无界面的构建服务也能访问对应私钥；Keychain 解锁方式、访问控制或账号不同，都可能使本地手工签名成功、自动任务却失败。这类权限差异是迁移中常见的隐藏风险，验收记录应注明执行账号和所用 Keychain。
Developer ID Application 测试线应从应用签名开始，核对实际身份、签名验证、时间戳、公证结果和最终交付流程。Apple 的公证准备文档列出 Developer ID 签名、Hardened Runtime 和安全时间戳等要求。自定义签名流程尤其要检查时间戳：Apple 的常见公证问题说明指出，获取安全时间戳需要网络连通；因此隔离环境的出口策略可能成为签名失败的原因。
Developer ID Installer 测试线应使用新证书重签 pkg，检查包签名并在干净的验证环境中实际执行安装。Apple 的同一份公证排障说明建议使用 pkgutil --check-signature 检查安装包签名；日志需保留证书身份和可信时间戳等结果。应用通过公证，不等于外层 pkg 的签名和安装行为已通过验收。
如何在 Mac CI 并行替换证书并验证发布链路？隔离测试新身份，按应用与 pkg 两条产物线分别运行从构建到交付的完整任务；保存流水线日志、签名检查结果、公证记录和安装验证结果，再让发布负责人复核。只完成一次成功构建不足以证明生产准入：还需要确认自动化服务账号可持续访问身份，并由测试作业明确使用替代证书，而非悄悄回退到旧证书。
分批切换与发布准入
满足这些条件时，先切换对应作业的小范围试点；任一项不满足，就继续留在隔离验证阶段，而不是直接全量放行：
- 若证书详情已确认颁发机构为旧 Sub-CA，则为对应类型申请 G2 替代证书；否则先记录核验依据，不按名称猜测。
- 若应用和 pkg 两条签名任务都分别通过，且 CI 服务账号可以读取相应私钥，则按作业批次更新签名配置；否则修复权限或流水线配置后重测。
- 若公证、时间戳、pkg 签名与实际安装验证均有可复核记录，则进入生产放量；否则不把一次构建成功视为发布准入。
- 若生产作业已切换、旧证书仍可能被其他作业调用，则先锁定使用范围与责任人；无法确认时，暂停清理旧身份，继续盘点。
- 若新签名链路出现失败，则回退到已验证的流水线版本并停止发布；回退方案不得依赖已失效证书继续签名。
切换记录应包括作业名称、变更责任人、替代证书类型、构建与签名日志、公证或安装验证结果，以及旧证书仍在使用的任务清单。旧身份保留多久、何时清理，应由团队凭证管理流程决定；不要为了“清爽”而在应用和 pkg 均完成核验前撤掉回退所需配置。另需注意，Developer ID 证书若因其他原因被撤销，影响不同于单纯到期；Apple 的证书说明分别列明了过期与撤销的后果，处置时应依据具体状态判断。
这次迁移的准入证据，最终要能回答三件事：受影响证书是否已识别、每类产物是否用替代证书完成真实流水线验证、生产作业与回退边界是否清楚。证书清单、私钥访问记录、签名日志和发布负责人确认应集中归档，供后续审计及年度续期复核。
如果现有做法是让每名开发者各自持有签名环境，或把签名任务挤在已有生产构建节点上，常见代价是私钥权限难统一、节点共享边界不清、迁移测试容易干扰正常发布。对于只在证书迁移窗口或发布高峰需要额外隔离 Mac 环境的团队，可以先比较自购设备的持续持有与维护成本，和按需使用远程真实 Mac 的周期成本，再决定是否租用；长期稳定重负载或必须连接特定物理设备的团队，不一定适合租赁。RUVCLOUD 提供按周、月或季度使用托管 Mac 的方式，可先从RUVCLOUD 的 Mac 环境信息了解服务形态，再结合费用与套餐信息判断是否适合迁移试点；具体环境能否满足隔离与访问要求，应在采购前按团队实际需求核实。