Developer ID G1 到期，Mac 安装包签名怎么迁移？2026

Developer ID G1 到期后的 Mac 安装包签名迁移，先核对签名证书链，再区分 PKG 与应用的处理方式：若 PKG 使用受影响证书签名，应在截止日期前换用正确的 G2 身份重签并验证安装；带安全时间戳的既有公证应用则不能直接套用 PKG 的处理规则。这个判断适用于管理 macOS 发布、签名资产和 CI 流水线的团队。

macOS 应用发布负责人：确认现有 Developer ID 签名资产是否受 G1 中间证书到期影响。
CI/CD 平台工程师：更新签名身份、钥匙串与产物验收步骤。
企业 IT 环境管理员：安排可隔离的 Mac 构建环境，避免在生产发布中首次验证新链。

Developer ID G1 到期的 Mac 安装包签名迁移，先确认哪张证书受影响

截止日期是 2027 年 2 月 1 日，但不能只凭证书名称或到期日判断某个产物必然失效。Apple 的公告指出，原 Developer ID Certification Authority（G1）将在该日到期；更具体的证书识别方法，是查看待检查的 Developer ID 证书颁发者信息，而不是只看钥匙串里的中间证书名称。(Apple 关于 G1 到期的公告)

在钥匙串访问中选中 Developer ID Application 或 Developer ID Installer 证书，展开颁发者名称并检查 Organizational Unit。显示 “Apple Certification Authority” 的旧 Sub-CA 证书需要替换；显示 “G2” 的证书来自当前 Sub-CA。团队可能同时持有名称相同、颁发链不同的证书，因此不要仅按证书名称选签名身份。(Apple 替换旧 Sub-CA 证书的指引)

Apple 也提醒，证书到期日可用于初步筛查：在账户证书列表中，查看到期日不晚于截止日期的 Developer ID Application 与 Developer ID Installer 证书；但这只是线索，最终仍要核对颁发者。不要把“到期日符合筛查条件”误当作“已确认由 G1 签发”。

PKG、已公证应用与后续更新：处理规则不能混用

Apple 已明确：从 2027 年 2 月 1 日起，使用受影响证书签署的安装包将无法安装；带安全时间戳的既有公证 Mac 软件继续工作，不需要仅因 G1 到期而重新签名。后续应用更新则应改用新证书签名，并在公证签名中包含安全时间戳。这里的边界只适用于 Apple 明确说明的产物类型，不应把 PKG 的规则扩大到所有应用或其他分发形式。(Apple 关于 G1 到期的公告)

Developer ID Installer 与 Developer ID Application 不是可互换的证书类型：前者用于签署安装包，后者用于签署应用等软件。对安装包，可用 pkgutil --check-signature 检查签名；对应用，可用 codesign 验证代码签名。Apple 的签名问题排查文档也列出了这些检查方式，并说明应根据产物类型选用正确的证书和验证工具。(Apple 签名与公证问题排查文档)

怎样确认 Developer ID Installer 证书由哪个中间证书签发？

以钥匙串中的实际 Developer ID Installer 证书为检查对象，展开颁发者字段并核对 Organizational Unit。若团队在证书列表中看到多个同名条目，应逐个确认颁发链和到期信息，并将结果对应到流水线实际使用的签名身份；不要误查仅代表颁发机构本身的中间证书。Apple 的证书替换指引给出了区分 G1 与 G2 的方法。

这一步也能避免一种常见误判：CI 仍能完成构建，不代表实际签名已经切换。构建节点可能还在使用旧钥匙串、旧私钥或相同显示名称的旧证书；应从产物验收结果反向确认流水线选中的身份，而不是只看项目设置或构建是否成功。

G2 证书选错时，为什么“签名成功”仍不够？

创建替代证书时，要选择 Developer ID Certification Authority（G2）。Apple 指出，如果创建时选了其他中间证书，签发出的证书也可能在 2027 年到期；公告还要求使用 Xcode 11.4 或更早版本的团队先更新工具链。G2 中间证书有效期至 2031 年，但由它签发的 Developer ID 证书需要按年度续期。年度续期是证书维护事项，不代表团队可以忽略每个产物的签名验证。上述版本与日期要求均来自 Apple 的公告及证书替换说明。

证书创建时若需要选择 Developer ID Certificate Intermediary，应选择 G2 Sub-CA。若团队使用较旧的 Xcode，应先按 Apple 的证书替换指引核对版本要求与 G2 选项，不要未经验证就把签名失败归因于某个工具链缺陷。

切换时重点排查这些环节：

• ✅ 新证书的颁发者确认为 G2，而不是只看证书显示名称。
• ✅ 安装包使用 Developer ID Installer 身份；应用由适用的 Developer ID Application 身份签名。
• ✅ CI 节点能访问对应证书及私钥，且实际调用的钥匙串与预期一致。
• ❌ 不要把证书文件存在某处等同于流水线已经使用它。
• ❌ 不要把私钥、密码或敏感签名凭据打印到构建日志，也不要将其写进示例配置。

macOS CI 签名迁移：从构建成功到安装验收

macOS CI 的验收目标不应止于“任务通过”。代表性流水线要证明：实际使用的是 G2 证书、PKG 的签名身份正确、目标环境可以完成安装。若该分发流程需要公证，也应验证公证结果及安全时间戳；Apple 的自定义公证工作流说明可用于核对脚本化流程的组织方式。(Apple 自定义公证工作流说明)

可以按下面的验收顺序执行：

1. 盘点产物。 列出实际对外分发的应用、PKG、磁盘映像或压缩包，并标记哪些包含安装包。不要把一种产物的结论直接推广到其他格式。
2. 核对证书链。 检查 CI 所用 Developer ID Application 与 Developer ID Installer 证书的颁发者，将 G1、G2 与到期信息记录在发布资产清单中。
3. 确认签名身份。 在构建节点检查可用签名身份，并确认私钥和预期钥匙串可访问。记录证书标识和构建任务，不记录私钥或秘密值。
4. 构建代表性版本。 在隔离的 macOS 构建环境中，对有代表性的应用与 PKG 执行签名；如果该分发流程需要公证，也一并执行并保存结果。
5. 验证产物本身。 对应用运行 codesign -vvv --deep --strict /path/to/App.app；对 PKG 运行 pkgutil --check-signature /path/to/Package.pkg。检查身份和签名链是否符合预期。
6. 在目标安装环境复测。 将生成的 PKG 放到团队实际支持的目标环境中安装，记录系统版本、产物版本、安装结果和相关提示。CI 任务成功不能替代这项检查。
7. 保留可追溯记录。 把迁移前后签名身份、检查输出、公证结果和安装验收结论关联到发布版本，供后续排障与审计复核。

⚠️ 安装失败提示、包内签名身份和证书链要一起留档。单独看到“无法安装”不能证明问题一定来自 G1；先用签名检查结果确认包实际由哪张证书签署。

经验上，最容易遗漏的不是“有没有新证书”，而是签名任务是否切换了钥匙串，以及最终安装包是否真的用预期身份签署。验收证据应来自实际生成的产物；不能用配置截图代替签名链和安装结果。

这篇文章不提供本站 Mac 节点的配置、交付方式或实测结果：目前没有可核验的对应数据，因此不把远程构建环境的能力或测试结论写成事实。团队可以先浏览企业 Mac 环境与相关指南，并结合数据隐私说明评估隔离构建所需的环境与凭据管理要求。

最后的取舍应看团队现有发布方式：继续沿用未经核验的共享构建节点，可能存在旧证书未替换、钥匙串权限过宽、缺少目标安装复测等问题；自行采购 Mac 则要承担硬件采购、维护和闲置期间仍占用资产的成本。若团队需要短期隔离环境来验证 G2 签名链，可先按上述验收项测试，再评估租赁 xcodeops 的远程 Mac 是否适合这类发布前验证；若任务需要长期稳定满负载运行或依赖特定物理接口，则应先比较自购设备与现有机房方案，而不是默认租赁更合适。

最后更新于 2026 年 10 月 26 日；截止日期、受影响证书范围及产物差异核实自 Apple 于 2026 年 10 月 1 日发布的公告与证书替换说明。