Apple 官方文档显示，使用 Xcode Organizer 进行归档与分发时，Xcode 13 或更高版本可以使用云管理证书完成分发签名。云管理证书说明 因此，遇到 Apple Distribution 证书过期 2026 提醒时，第一步不是撤销全部证书，而是先判断项目使用自动签名还是手动签名：自动签名先核对团队和云管理证书权限；手动签名再重建有效证书、描述文件，并完成一次 Archive 与上传验收。
这篇文章适合 3 类人：
- 临近 App 更新窗口，却收到分发证书过期提醒的运营负责人。
- 接手外包项目后，缺少签名私钥、描述文件或原构建 Mac 的项目经理。
- 需要准备稳定 macOS 构建环境，让技术人员远程完成签名恢复和构建上传的跨境团队管理员。
[ SECTION_01 ] 先判断：证书过期，还是整个发布链路失效
Apple Distribution 证书、Apple Developer Program 会员状态、描述文件和 App Store Connect 应用状态不是同一个问题。把它们混在一起处理，最容易出现“重新建了证书，但构建仍然无法上传”的情况。
| 检查对象 | 它影响什么 | 典型处理方式 | 是否应立即重建 |
|---|---|---|---|
| Apple Developer Program 会员状态 | 是否还能使用证书、描述文件及提交更新 | 由 Account Holder 检查会员是否有效 | 否，先确认状态 |
| Apple Distribution 证书 | 对提交到 App Store 的构建进行分发签名 | 自动签名走云管理；手动签名创建新证书 | 视签名方式决定 |
| 描述文件 | 把 App ID、分发证书和授权能力关联起来 | 重新生成并安装到构建 Mac | 证书或能力变化后处理 |
| App Store Connect 应用状态 | 构建是否进入正确应用和版本 | 核对 Bundle ID、版本号、Build 号及处理状态 | 否，不能用重建证书解决 |
Apple 官方说明，Apple Distribution 证书用于分发应用或提交到 App Store；分发证书属于团队资源，通常只有 Account Holder 或 Admin 能创建。证书类型与权限说明
如果只是证书过期，但 Apple Developer Program 会员仍有效，已安装在用户设备上的旧版本通常不会因为这一个证书提醒立即消失。真正受影响的是新的构建、签名和上传链路。若会员本身已过期，则应先由 Account Holder 处理会员恢复。会员续费与恢复说明
⚠️ 需要区分分发方式：App Store 分发、Ad Hoc 测试和 Enterprise 内部分发使用的资产并不相同。本文聚焦 App Store 更新，不把企业内部分发或 Ad Hoc 的过期影响套用过来。
在开始操作前，建议保存 4 项证据：
- 证书到期提醒的脱敏截图。
- Xcode 中 Signing & Capabilities 的签名状态。
- 当前选择的团队名称和 Team ID。
- 最近一次构建错误、Archive 验证结果和上传日志。
这些材料能帮助运营人员把“证书问题”与“权限、版本号或构建处理问题”分开，也方便外包团队交接。
[ SECTION_02 ] Xcode 自动签名：先恢复团队和云管理链路
如果项目开启了 Automatically manage signing，不要因为看到旧的 Apple Distribution 证书已过期，就直接撤销所有证书。Xcode 的自动签名会根据团队、Bundle ID、授权能力和可用签名资源处理分发配置；使用 Organizer 归档与分发流程时，还可能使用云管理证书。云管理证书官方说明
自动签名恢复步骤
- 打开项目，选择需要发布的 App target。
- 进入 Signing & Capabilities，确认已勾选 Automatically manage signing。
- 检查 Team 是否为正确的 Apple Developer 团队。
- 登录负责发版的 Apple Account，确认该账号已经加入对应团队。
- 由 Account Holder 或 Admin 检查相关用户是否拥有 Certificates、Identifiers & Profiles 访问权限，以及云管理分发证书相关权限。
- 在真实设备构建环境中选择正确的 Scheme 和 Generic Device。
- 执行一次 Product > Archive，进入 Organizer 后选择 Distribute App。
- 在分发流程中检查签名证书、描述文件和 Entitlements，再决定是否上传。
Apple 的角色文档显示，App Store Connect 中的用户权限和 Apple Developer Program 团队权限并不完全等价。一个用户能看到 App Store Connect 应用，不代表他一定能管理 Certificates、Identifiers & Profiles。角色与权限表
自动签名场景评分：
- 团队选择正确：★★★★★
- 权限核对完成：★★★★★
- 云管理证书可用：★★★★☆
- 需要手动下载证书：★☆☆☆☆
- 适合运营人员独立处理：★★☆☆☆
如果自动签名状态正常，但上传后构建没有出现在 App Store Connect，不要继续重复创建证书。应转向 Bundle ID、版本号、Build 号、上传账号权限或构建处理状态排查。
[ SECTION_03 ] 手动签名：证书、私钥和描述文件必须成套恢复
手动签名项目的恢复重点不是“下载一个新的 .cer 文件”，而是恢复完整的签名身份。至少需要：
- 有效的 Apple Distribution 证书。
- 与证书匹配的私钥。
- 与 Bundle ID、分发方式和授权能力匹配的 App Store Connect 描述文件。
- 安装并配置正确的构建 Mac。
Apple 官方说明，App Store Connect 描述文件需要关联明确的 App ID 和一个分发证书；手动创建时，还需要由具备权限的角色选择正确的证书并生成文件。创建 App Store Connect 描述文件
手动签名重建顺序
- 在 Apple Developer 账户中确认原证书是否已过期、是否被撤销。
- 记录旧证书对应的项目、负责人和构建流程。
- 在正确的开发者团队下创建新的 Apple Distribution 证书。
- 如果需要生成 CSR，在 Mac 的 Keychain Access 中创建证书签名请求。
- 下载证书并安装到负责构建的 Mac。
- 登录 Certificates、Identifiers & Profiles，确认 App ID 与项目 Bundle ID 完全一致。
- 创建新的 App Store Connect 描述文件。
- 下载描述文件并安装到同一台构建 Mac。
- 在 Xcode 的 Signing 设置中关闭自动管理，重新选择证书和描述文件。
- 先执行 Validate 或签名检查，再创建新的 Archive。
- 从 Organizer 进入 App Store Connect 分发流程，完成一次上传复测。
创建 CSR 时，Keychain Access 会生成密钥对。证书文件只是公钥证书的一部分，不等于完整的签名身份。CSR 创建步骤
| 现象 | 更可能的原因 | 下一步 |
|---|---|---|
| 新证书已下载，但 Xcode 找不到签名身份 | 私钥不在当前钥匙串，或证书装到了错误用户 | 打开钥匙串检查证书下方是否带对应私钥 |
| 新建证书后描述文件仍无效 | 描述文件关联旧证书、错误 App ID 或授权能力不一致 | 重新生成与新证书匹配的描述文件 |
| Xcode 能归档，但上传时签名失败 | Entitlements、团队或分发方式不匹配 | 查看分发流程中的签名检查详情 |
| 上传成功，但 App Store Connect 没有构建 | 构建仍在处理，或版本号、Build 号未匹配 | 查看构建处理状态和上传记录 |
描述文件过期、证书被撤销或 App 服务发生变化时，应重新生成描述文件。新证书不会自动让旧描述文件变得有效。描述文件编辑与重新生成
[ SECTION_04 ] 私钥缺失与更换 Mac：先做安全交接，再建立新身份
“手里有证书文件，但没有私钥怎么办”是外包交接中最常见的误判。证书文件可以被下载和复制，但用于签名的私钥通常保留在创建 CSR 的原 Mac 钥匙串中。将 .cer 文件双击安装，并不能凭空恢复私钥。
原 Mac 或原负责人仍可访问
优先方案是安全交接原签名身份：
- 让原负责人在原 Mac 的钥匙串中确认证书与私钥成对存在。
- 由具备权限的技术负责人制定交接时间和交接范围。
- 使用受保护的密钥导出方式完成迁移。
- 在新构建 Mac 上导入后，检查证书下方是否显示对应私钥。
- 用非生产版本或当前版本的复现构建完成签名检查。
- 删除不再需要的临时导出文件，并更新交接记录。
原 Mac 和私钥都无法恢复
此时不能只下载旧证书解决。应由 Account Holder 或 Admin 创建新的签名资产，再重新生成描述文件，并让项目在新签名身份下完成一次完整 Archive 与上传测试。
禁止以下做法：
- 共享 Apple Account 密码。
- 共享 Mac 管理员账号。
- 把未加密的证书导出文件放进群聊或公开网盘。
- 为了“清理过期证书”而批量撤销仍被其他项目使用的证书。
- 在没有记录项目归属的情况下删除旧描述文件。
经验上，证书恢复失败往往不是证书本身坏了，而是“构建 Mac、钥匙串、项目设置和负责人”没有一起交接。签名资料应按项目和团队权限分层保管，不能只交付一个文件夹。
[ SECTION_05 ] 新证书后仍不能上传：用单变量复测定位
完成证书和描述文件重建后，建议不要同时升级 Xcode、修改 Bundle ID、切换团队和调整授权能力。一次只改一个变量，才能判断错误是否已经从签名问题转移到了构建或 App Store Connect 阶段。
复测分流
结果 A：签名检查未通过
重点看证书、私钥、描述文件和 Entitlements。若证书在钥匙串中没有私钥，优先修复签名身份，而不是重复下载证书。
结果 B：描述文件不匹配
检查 Bundle ID、团队、分发类型和授权能力。一个新证书并不会自动让旧描述文件变得有效。
结果 C：团队选择错误
检查 Xcode 项目中的 Team，以及当前登录账号所属团队。跨境外包项目尤其容易出现个人团队、公司团队和历史团队混用。
结果 D：上传后没有构建
App Store Connect 会根据构建中的 Bundle ID 和版本号关联应用与版本；上传后的构建还需要经过系统处理后才会显示。上传构建官方说明
Xcode 的标准流程是：在 Archives Organizer 选择 Archive，点击 Distribute App，选择 App Store Connect，再选择 Upload，最后复核签名证书、描述文件和 Entitlements。Xcode 上传步骤
如果错误信息已经变成版本号冲突、缺少权限、构建处理失败或出口合规信息缺失，应停止重建证书，转入对应问题排查。继续撤销和新建签名资产，反而会扩大影响范围。
[ SECTION_06 ] 用验收清单确认恢复结果
下面的清单适合由运营负责人、技术人员和项目经理共同完成。每一项都应保存对应截图、日志或页面状态。
- [ ] Apple Developer Program 会员状态有效。
- [ ] 当前 Xcode 登录账号属于正确团队。
- [ ] 已确认项目使用自动签名或手动签名。
- [ ] 自动签名项目已核对云管理证书和团队权限。
- [ ] 手动签名项目已确认 Apple Distribution 证书有效。
- [ ] 构建 Mac 的钥匙串中，证书下方显示匹配的私钥。
- [ ] App ID 与项目 Bundle ID 完全一致。
- [ ] 描述文件使用正确的 App Store Connect 分发类型。
- [ ] 描述文件已安装到实际执行 Archive 的 Mac 用户环境。
- [ ] Xcode 已完成一次新的 Archive。
- [ ] Organizer 中的签名检查显示证书、描述文件和 Entitlements 正确。
- [ ] 已完成一次 App Store Connect 上传。
- [ ] App Store Connect 能识别正确的应用、版本号和 Build 号。
- [ ] 构建处理状态已被记录。
- [ ] 未在共享文档中保存 Apple Account 密码、管理员密码或明文私钥。
- [ ] 已记录签名方式、证书管理角色、资料保管位置和下一次复核条件。
发布链路验收评分：
- 通过签名检查：2 分。
- Archive 成功：2 分。
- 上传完成：2 分。
- App Store Connect 识别正确应用：2 分。
- 团队完成安全交接记录：2 分。
达到 8 分以上，通常可以进入版本发布准备；低于 8 分，应先补齐缺失环节，不建议直接把该环境交给运营团队长期使用。这个评分是团队内部验收工具，不代表审核结果、上传成功率或 Apple 的处理时间。
[ SECTION_07 ] 固定 Mac、短期远程 Mac 与双轨环境的选择
证书恢复后，团队还需要决定构建环境如何持续保留。固定 Mac 适合长期稳定重负载、需要物理接口或必须由内部人员直接管理钥匙串的项目。短期远程 Mac 更适合临近发版、原设备不可用、等待新设备交付，或需要让技术人员临时接入完成 Archive 与上传的场景。
| 方案 | 适合情况 | 优点 | 主要风险 | 建议评分 |
|---|---|---|---|---|
| 固定内部 Mac | 长期持续发布、多人共用同一构建流程 | 设备归属清晰，钥匙串可长期保留 | 设备故障、交接困难，异地团队接入成本较高 | ★★★★☆ |
| 短期远程 Mac | 临时恢复、外包交接、等待设备到位 | 可持续访问 macOS，便于异地协作 | 仍需自行管理账号、钥匙串和权限边界 | ★★★★☆ |
| 双轨环境 | 生产固定 Mac 加临时备用环境 | 主环境故障时有回退路径 | 需要同步项目、证书和构建记录 | ★★★★★ |
| 仅使用 Windows 或普通云主机 | 没有 macOS 构建要求的业务 | 初始设备投入较低 | 无法替代真实 Mac 上的 Xcode 归档与签名流程 | ★★☆☆☆ |
如果团队当前没有可持续访问、能够保留钥匙串和构建记录的 Mac，可以先查看 NOVAKVM 的远程 Mac 环境，再根据团队所在区域了解 美国节点的 Mac 使用方案。这类环境不能绕过 Apple 的权限、审核或地区规则，是否适合项目，仍应以一次真实 Archive 和上传测试为准。
当前方案如果依赖外包人员的个人 Mac，常见缺点是设备不可控、私钥交接不完整、多人共用环境导致权限边界模糊；如果临时改用 Windows 或普通云主机，又无法直接替代 macOS 上的 Xcode 归档与签名链路。对于只需要完成本次 App 更新、等待内部设备交付，或需要给异地技术人员准备隔离构建环境的团队，按周期租用 NOVAKVM 的远程 Mac，再用上述验收清单验证一次，通常比继续追着一台不可访问的旧 Mac 排查更稳妥。