Engineering guide

Developer ID G2 证书怎么迁移？2026 Mac 签名验收

CI/CD 实践 ·约 9 分钟阅读

Developer ID G2 证书怎么迁移？2026 Mac 签名验收

Apple 于 2026 年 10 月 1 日公告：旧 Developer ID Certification Authority（Sub-CA）将于 2027 年 2 月 1 日到期，届时该机构签发的证书不能继续用于签名。Apple 到期公告

症状：证书列表里有 Developer ID Application 或 Developer ID Installer，却无法确定签发机构。
最快解法：核验签发机构，再按交付物分别处理：受影响的 .pkg 在截止日期前换证重签；带安全时间戳且已公证的既有 Mac 应用，不因 Sub-CA 到期而一律重签。

谁该看：Mac 独立开发者，需要确认对外分发应用的签名证书是否受影响。
Mac 软件发布团队：交付 .pkg 安装包，需要安排换证、重签和用户侧安装验收。
CI/CD 工程师：在 macOS 流水线使用 Developer ID 证书，需要更新钥匙串引用和签名任务。

最后更新于 2026 年 10 月 28 日，日期与迁移范围核对自 Apple 的 2026 年 10 月 1 日公告。

Developer ID G2 证书迁移的影响范围

到期的是旧的中间证书机构，不是所有 Developer ID 证书都在同一天失效。受旧机构签发的证书届时不能继续用于签名；G2 证书也有自己的有效期，需要按期续期。替换证书的申请方式和识别指引见 Apple Developer ID 证书替换说明。

因此，不能只看证书名称或到期日就决定是否迁移。同一团队可能持有名称相同、但由不同 Sub-CA 签发的证书；而且，Developer ID Application 用于签署应用，Developer ID Installer 用于签署安装包，两者不能互相替代。Apple 对 Developer ID 证书类型的说明

交付物 受旧 Sub-CA 到期影响时的处理 迁移紧迫度
已签名、已公证且带安全时间戳的既有 Mac 应用 Apple 表示这类既有软件可继续工作；无需仅因 Sub-CA 到期而全部重签。后续版本改用 G2 签名，并按发布流程处理公证。 后续发布切换
使用受影响证书签名的 .pkg 在截止日期前使用新的 Developer ID Installer 证书重新签名；之后要以实际交付的安装包做用户侧验证。 截止日期前完成
尚未公证、无安全时间戳或状态不明的应用 不要直接套用“既有公证应用可继续工作”的结论；检查具体签名、公证和分发产物，再决定处置。 先核验再发布

符合条件的既有应用与受影响证书签署的安装包，处理要求并不相同；不能将安装包重签期限扩大成所有既有 Mac 应用的统一重签期限。

独立开发者：证书签发机构核验

签发机构识别方法

先登录开发者账户，在证书列表中分别查看 Developer ID Application 和 Developer ID Installer。到期日在截止日期或更早的证书是排查线索，但不是单独的判定依据；还需核对签发者。

在 macOS“钥匙串访问”中打开用于签名的 Developer ID 证书，展开“签发者名称”，检查“组织单位”字段：

这里容易踩的坑是只按列表名称挑证书：Developer ID Application、Developer ID Installer 的显示名称描述用途，不足以识别 Sub-CA。创建替代证书时，也要分别申请对应类型；如果界面要求选择中间机构，选 G2 Sub-CA。Apple 说明新签发的 G2 开发者证书需要按期续期，不能把中间机构的有效期误当成开发者证书有效期。

Mac 软件发布团队：按交付物验收

应用与安装包的重签范围

不需要一概重签。已经签名、公证并带安全时间戳的既有 Mac 软件，Apple 说明可继续工作；未来版本应使用新证书。相反，受影响证书签过的 .pkg 必须在截止日期前用替代证书重新签名。没有安全时间戳或公证状态不清楚的应用，应单独验证，不能把它当成已确认的例外。

Mac 安装包签名的验收不应止于“构建成功”。证书换好后，先确认签名身份匹配，再检查最终 .pkg 的签名，并在干净的测试环境执行安装；如果包内应用或分发形式要求公证，也要沿用原发布流程检查公证结果。Apple 对应用与安装包使用的证书类型及签名检查方式有分别说明，详见签名与公证问题排查文档。

发布验收项 应用（.app） 安装包（.pkg）
应使用的身份 Developer ID Application Developer ID Installer
主要核验点 签名有效、嵌套代码未被签名后改动；检查安全时间戳与公证状态 安装包签名有效，且签名身份来自替代证书
可执行验证 用 codesign 检查签名；在测试 Mac 上打开并检查 Gatekeeper 行为 用 pkgutil --check-signature 检查签名，再实际安装
迁移判定 已公证且带安全时间戳的既有版本无需仅因本次到期一律重签 受影响证书签署的包须在 2027 年 2 月 1 日前重签

Apple 的排查文档建议用 codesign 检查应用、用 pkgutil --check-signature 检查安装包；安装包的检查结果应显示可信时间戳和 Developer ID Installer 身份。对需要公证的分发物，应按 Apple 的 macOS 软件公证指南检查相应流程。

CI/CD 工程师：流水线切换与回退

macOS CI 签名故障常常不是“证书文件没装”这么简单：构建机可能只装了证书、没有对应私钥；流水线的签名身份仍指向旧证书；隔离钥匙串或自动签名设置也可能与本地开发机不同。只在开发者电脑上签成功，不能证明正式发布任务已经迁移。

建议先在隔离发布任务中接入新证书及对应私钥，使用试发布产物走完签名、公证（如适用）和安装验收，再切换正式任务。检查钥匙串引用、签名身份名称、构建脚本与交付物，不要只改一处配置后就删除旧身份。Apple 的自定义公证工作流说明涵盖脚本化提交和凭据引用；CI 凭据应按官方流程设置，避免把口令明文写进脚本。

下面这份清单适合由发布负责人逐项指定执行人；任何一项无法复现，都先暂停正式切换，保留原任务作为回退路径。

Apple 的代码签名技术说明指出，Developer ID 签名需要安全时间戳；直接使用 codesign 时，应按官方说明处理时间戳，并确认构建网络可访问时间戳服务。证书与时间戳说明若自建流水线还需要验证公证流程，应按前述 Apple 文档配置；不要把某一台构建机上的偶然成功当作所有 CI 环境的保证。

负责人：用责任划分控制迁移风险

建议把任务拆给证书管理员、发布工程师和验收负责人，而不是等到临近截止日才集中改流水线。尤其要避免三种延误：证书身份未核实就批量重签，遗漏独立的 Installer 证书，以及替换了密钥却没有用用户实际下载的最终产物验证。

责任角色 交付任务 通过标准 评分
证书管理员 核验签发者并申请 G2 替代证书 证书类型、签发者与私钥匹配 迁移基础
发布工程师 更新签名配置并试签 应用与 .pkg 均使用正确身份 发布就绪
验收负责人 测试最终下载物、公证状态和安装 结果可复现、有记录，失败可回退 用户侧把关

G2 中间证书机构有效期延续至 2031 年，但其签发的开发者证书仍需定期续期；因此，当前迁移完成后，还要把证书续期纳入 CI 运维日历。Apple Developer ID 中间证书说明

远程 Mac 是否适合签名验收

如果团队现有环境只有 Windows 或 Linux，直接验证 macOS 签名、Gatekeeper 行为和 .pkg 安装会遇到环境缺口；临时借用个人 Mac 则容易造成钥匙串、私钥权限和验收记录分散。远程 Mac 可以提供 macOS 测试环境，但它不自动替代安全的证书管理：私钥访问、CI 凭据保护和发布审批仍需由团队负责。

若只是短期迁移验证，且缺少可用 Mac，ArmMacs 的远程 Mac 可作为测试环境选项；可以先了解远程 Mac 支持信息，再按实际使用周期查看租赁方案。若签名任务长期稳定、高频运行，或需要专用物理接口，购买并自行管理 Mac 可能更合适；租赁也有网络访问、环境维护和凭据隔离等管理成本。

先完成证书签发机构盘点，再用真实分发物分别验收应用与 .pkg，并为正式流水线设定回退条件。2027 年 2 月 1 日不是所有既有 Mac 应用的统一重签期限，但受影响证书签署的安装包必须在此之前完成替换与验证；缺少 macOS 验收环境时，再评估 ArmMacs 是否符合团队的安全与运维要求。

ArmMacs Cloud Mac

用 ArmMacs 专用 Mac，完成证书迁移与签名验收

租用独享物理 Mac，使用 VNC 或 SSH 接入，按你的项目要求配置签名环境。

选择机型并订购