Developer ID 证书 2027 到期怎么办？2026 迁移清单
签名检查突然发现证书来自旧 Sub-CA？先别把所有已发布 App 都排进重签计划。
最快判断：先核对 Developer ID 证书签发链，再按产物处理。受影响证书签署的 .pkg 应在 2027 年 2 月 1 日前换新证书重签；已签名、公证且带安全时间戳的 Mac App，不必仅因这次到期立即重签，后续更新则应使用新证书。Apple 于 2026 年 10 月 1 日公布了到期安排，具体是否受影响仍要以开发者账号中的证书记录为准。(Apple 到期公告)
适合分发独立 macOS App、需要确认 Developer ID Application 身份的开发者。
也适合维护 .pkg 安装器、要安排截止日前重签验收的团队。
如果发布任务跑在远程 Mac 上，还要核对实际构建账户能否访问新证书及对应私钥。
对比已发布 Mac App 与待安装的 .pkg
Developer ID 到期事件影响的不是所有产物，也不是所有证书。判断重点是：证书由哪个中间机构签发、产物使用哪种签名身份，以及它是 App 还是安装包。
| 检查对象 | 应使用的身份 | 到期影响与处置 |
|---|---|---|
| 直接分发的 Mac App | Developer ID Application | 已签名、公证且带安全时间戳的既有软件可继续工作；后续更新改用新证书。 |
.pkg 安装包 |
Developer ID Installer | 若由受影响证书签名，应在 2027 年 2 月 1 日前用新证书重签，并验证安装器和发布渠道。 |
| 本地或远程构建账户 | 与目标产物匹配的证书及私钥 | 检查实际执行构建的账户是否能找到并使用新签名身份，不能只确认账号里已创建证书。 |
Apple 明确区分这两类身份：Developer ID Application 用来签 App，Developer ID Installer 用来签安装包。创建新证书时，按 Apple 的 Developer ID 证书创建说明选择对应类型；不要把创建成功当作发布迁移已完成。
签发链核验：账号记录比证书名称可靠
旧中间证书到期不等于每张 Developer ID 证书都自动受影响。Apple 的公告针对由原 Developer ID Certification Authority（Sub-CA）签发的证书，并要求开发者在 Certificates, Identifiers & Profiles 中核对证书到期日和签发机构。公告还指出，新证书应来自当前的 Developer ID Certification Authority（G2）；创建时要选择 G2 Sub-CA。
按以下方式建立可复核的证据链：
- 登录开发者账号，打开 Certificates, Identifiers & Profiles，分别筛选 Developer ID Application 和 Developer ID Installer。
- 对照证书的到期日与签发机构。记录证书类型、序列号或指纹、到期日和团队标识；不确定签发链时，不要仅凭显示名称判断。
- 在发布用 Mac 的“钥匙串访问”中找到相应证书，查看证书详情，确认本机证书与账号记录相符。
- 新建证书时确认签发机构为 G2 Sub-CA，并检查创建页面提供的中间证书选项。
- 若构建环境仍使用 Xcode 11.4 或更早版本，先依照 Apple 公告核实兼容性并评估升级；不要假定旧工具链会自动识别新链。Apple 的中间证书说明记录了旧版 Xcode 的兼容边界。
证书有效期与中间证书有效期不是一回事。Apple 公告指出，G2 机构有效期延续至 2031 年，但其签发的 Developer ID 证书仍按年度到期，需要逐年更新。这个期限描述的是签发机构，不是手上某张叶证书可以使用到的日期。
产物验收：签名、时间戳和公证分别检查
证书是签名身份的一部分；私钥负责实际签名。公证则是另一项检查流程，不能用“新证书已经创建”替代。安全时间戳也不是公证票据的别名：它记录签名时间，关系到 macOS 如何判断签名时证书是否有效。Apple 的代码签名证书说明解释了安全时间戳的作用；Developer ID 签名指南说明了签名与公证各自的分工。
先检查实际交付产物，而不是只看钥匙串：
# 查看 App 的签名身份、证书链及签名详情
codesign -dv --verbose=4 "/path/to/MyApp.app"
# 检查 App 的 Gatekeeper 接受情况
spctl -a -vv "/path/to/MyApp.app"
# 验证已装订的公证票据
xcrun stapler validate "/path/to/MyApp.app"
# 查看 .pkg 的签名与时间戳信息
pkgutil --check-signature "/path/to/Installer.pkg"
这些命令检查的对象不同。codesign 用于查看 App 签名详情；spctl 检查系统策略下的接受结果；stapler validate 检查装订票据；pkgutil 检查安装包签名。Apple 的公证问题排查文档也建议用 pkgutil --check-signature 检查 .pkg，并确认签名身份是 Developer ID Installer。
输出至少应能回答三个问题：产物使用了预期签名身份吗？签名和时间戳验证通过吗？公证状态及安装验证是否符合当前发布流程？保存脱敏后的命令输出、证书指纹和构建记录即可；不要把私钥、证书密码或可复用凭据放进日志。
容易漏掉的边界：若 App 使用 Developer ID provisioning profile 来支持特定能力，该 profile 有自己的有效期与检查要求。证书迁移通过，不代表 profile 一并更新或永久有效。Apple 的证书影响说明区分了 App 与安装器证书到期后的影响，也说明了 profile 的独立检查条件。
发布决策：按证据选择保留、迁移或补签
目前已经完成的证书记录和产物检查，应转成明确的处理结论。下面的判断以证书签发链和交付物实测结果为准，不以开发机上“看起来能构建”为准：
- 证书不在受影响范围：留存账号证书记录与签名检查结果，按其实际到期时间维护；不要因为公告而给所有版本安排重签。
- 受影响证书签过 Mac App：保留符合公告条件的既有版本；未来更新使用新 Developer ID Application 身份，并对新产物执行签名、公证和分发验收。
- 受影响证书签过
.pkg：列出公开下载页、自动更新器、镜像和客户交付中仍在使用的安装包，在截止日前用新 Developer ID Installer 身份重签，并逐项验证。 - 远程构建账户找不到新身份：检查该账户的钥匙串、私钥可用性和 CI 执行上下文；修复后用真实发布任务重新构建、签名和验收，而不是只在管理员账户里测试。
新证书迁移后的验收记录
要完成迁移，至少应依次通过以下检查。每一项都留下可追溯证据，失败时暂停对应产物发布：
- 证书匹配：账号中的类型、签发机构、序列号与发布 Mac 上的证书一致。
- 私钥可用：实际构建账户能使用该身份签名；只导入
.cer、没有对应私钥，并不能完成签名。 - 身份正确：Mac App 使用 Developer ID Application，
.pkg使用 Developer ID Installer。 - 产物签名通过：对准备分发的 App 和安装包运行对应检查命令，确认结果对应新身份。
- 公证与安装验证通过：按原发布流程核实新 App 的公证状态，并在干净环境中验证安装器可用。
- 渠道已更新：更新下载地址、自动更新源或客户交付包，确认不会继续发出未重签的受影响
.pkg。 - 记录可追溯：保存证书标识、构建任务、产物校验结果和发布时间；移除记录中的私钥内容与凭据。
若需要在独立环境中维护发布任务，可以先比较远程 Mac 方案与费用信息，再判断远程构建账户是否适合持有发布所需的证书与私钥。远程环境不会自动解决钥匙串权限、凭据交接或产物验收问题，这些仍需按团队的访问控制方式配置。
常见问题：旧证书会影响哪些交付物？
已公证且带安全时间戳的 Mac App 会失效吗？
按 Apple 公告，符合条件的既有 Mac 软件可继续工作；不要仅因这次到期就把全部历史 App 纳入重签。后续更新应改用新证书。若 App 另有 provisioning profile，则另行检查其状态。
怎样识别旧 Sub-CA 签发的证书？
在开发者账号中核对实际证书记录及签发机构，再用本机证书详情和指纹匹配。只凭证书名称或团队名称无法充分证明签发链；有疑问时，以账号记录和 Apple 说明为准。
为什么 Developer ID Application 和 Developer ID Installer 不能互换？
前者用于签署 Mac App，后者用于签署 Mac Installer Package。迁移时应按产物类型分别盘点、创建证书和验收，不要只更新一种身份就认为所有发布物都已覆盖。
证书更新是否代表旧版本也要重新公证？
不代表。公证是针对提交的软件产物进行的流程；证书替换本身不能证明历史产物需要重新公证。对未来更新，按新产物的签名、公证和分发要求完成检查，并保存对应记录。
为发布迁移选择合适的 Mac 环境
如果现有方案是让个人开发机兼任签名机，常见代价是本地钥匙串与发布任务互相牵连、机器离线时构建中断、团队成员难以独立复现签名环境。长期稳定运行的重负载流程，或必须连接特定物理设备的场景，更适合评估自购设备；临时迁移、验收或搭建独立发布环境时，远程 Mac 则提供了另一种可控选项。
选择 SFTPMAC 前，应先确认团队能否按自身安全策略配置证书、私钥与构建账户，并核实所需交付方式是否适用。可从 SFTPMAC 的 Mac 环境方案了解远程使用方式；最终仍以真实发布任务的签名、公证和安装验收结果决定是否迁移。本文数据核实自 Apple 于 2026 年 10 月 1 日发布的到期公告及文中所列 Developer ID 官方说明；计划于 2026 年 11 月复核相关要求。