Apple 的 App Store 配置文件只包含一个分发证书，因此企业 iOS CI 证书轮换不能默认新旧证书可以并行使用。Apple 对 App Store 配置文件的说明明确了这一边界。先识别证书类型和账号限制，再更新配置文件并在隔离 Mac CI 节点验收完整签名与交付链路；验收通过后分批切换生产，最后按规则处置旧证书。如果怀疑私钥泄露，应优先启动紧急响应，不为维持轮换窗口拖延撤销。
负责 Apple Developer 账号与签名资产的 IT 管理者，可据此核实操作权限和撤销影响。
负责 iOS CI/CD 的平台团队，可按步骤安排配置文件更新、隔离验收和生产切换。
负责发布与安全的负责人，可用文中的边界判断常规轮换与密钥泄露事件。
[ SECTION_01 ] 盘点阶段：先划清签名资产与发布影响
“证书轮换”不是只替换 Mac 钥匙串中的证书。至少要区分四类资产：证书标识开发者或团队身份；与证书配对的私钥实际用于签名；Provisioning Profile 关联 App ID、证书与授权能力；Apple Developer 账号权限决定谁能创建、管理或撤销资产。Mac CI 节点的本地权限则决定哪些任务能读取私钥、调用签名工具。
先按实际用途分类。Apple Development 用于开发和测试；Apple Distribution 用于 Apple 平台应用的分发或上传 App Store Connect；Developer ID 用于在 Mac App Store 之外分发 Mac 应用。云管理证书由 Apple 远程管理，其签名流程与本地手动签名不同。Apple 的证书类型和用途说明不应被简化成“所有证书都用同一种轮换方式”。
影响也取决于分发渠道。Apple 说明，有效的开发者计划下，App Store 上已发布的应用通常不会因为分发证书到期或撤销而受影响，但新上传可能受阻；企业内部签名的应用则可能需要重新签名并重新分发。Developer ID 撤销也可能影响用户安装已签名应用。遇到不同分发方式，应先对照Apple 的证书到期与撤销影响说明，再确定变更范围，不能把 App Store 上传经验直接套到内部部署。
建立一份团队现状清单，数据来自账号记录、资产存放位置和最近一次成功的流水线记录，而不是估算：
- 关联的 App ID、应用、分发渠道及流水线。
- 证书类别、有效状态、创建与管理责任人。
- 私钥所在的钥匙串或受控存储位置，以及可以读取它的节点和任务。
- Profile 的类型、绑定证书、授权能力、更新时间及获取方式。
- 当前成功构建、归档、导出和交付路径；保留可审计的构建记录。
- 变更负责人、审批人、生产切换顺序、暂停条件和回退条件。
还要核实操作账号有没有对应权限。Apple 将部分证书管理操作限定给 Account Holder 或 Admin；开发团队成员的能力也会受账号角色与单独授权影响。开始操作前，按Apple Developer Program 角色权限表确认由谁创建、更新和撤销资产，避免到了维护窗口才发现执行人没有权限。
[ SECTION_02 ] 准备阶段：选择轮换方式并控制私钥
按已识别的证书类型决定路径，不先假定“新建一张再慢慢切”一定可行。Apple 对团队分发证书的创建数量设有限制；云管理证书另有自动管理与轮换机制。因此，需要在账号中查看证书现状，并核实此类资产是否支持所计划的并行验证。若条件不允许先验证再切换，就要安排受控维护窗口，明确暂停生产任务的时点，而不是承诺无停机切换。
| 资产类型 | 轮换前核实重点 | 配置文件与发布影响 | 方案评分 |
|---|---|---|---|
| Apple Development | 证书所属成员、节点钥匙串和测试用途 | 按实际开发配置检查 Profile；不能代替分发证书 | 测试环境：高；生产发布：低 |
| Apple Distribution | 团队证书状态、创建权限、账号限制及上传渠道 | 手动签名时检查 Profile 是否包含新证书；撤销可能使关联 Profile 失效 | 先隔离验收：高；盲目并行：低 |
| Developer ID | Mac 应用分发方式和 Apple 指定的撤销渠道 | 撤销影响可能涉及已签名应用安装；须按对应场景核实 | 事前影响评估：高；套用 iOS 流程：低 |
| 云管理证书 | App Store Connect 授权、Xcode 签名流程及当前状态 | 由云端流程管理时，不能假设节点本地钥匙串持有同一证书 | 区分云端与本地签名：高 |
表中的“评分”是流程判断，不是性能或恢复时间承诺。判断依据是操作是否符合对应证书机制、是否留有隔离验收路径，以及能否控制撤销影响。
私钥要与证书分开管理。限制可读取私钥的人员与 CI 任务；不要把私钥文件、密码或账号凭证提交到代码仓库，也不要把生产钥匙串无差别复制到测试节点。审批记录应说明新私钥在哪里生成、如何进入构建环境、谁能调用，以及轮换完成后如何回收临时副本。
⚠️ 证书尚未到期，并不代表继续保留可疑私钥是安全选择。若怀疑泄露，转入安全事件流程，尽快限制访问并按证书类型处置；同时准备替换签名资产、修复关联 Profile 和恢复发布的工作。
如果采用云管理证书，不要机械执行本地创建、导入和上传私钥的步骤。Apple 说明，云管理证书可由 Xcode 的归档与分发流程调用；其证书会在到期前按机制创建新证书，手动轮换则受当前证书状态限制。具体可操作条件应以账号页面为准，参考云管理证书的轮换与使用说明。
[ SECTION_03 ] Profile 更新阶段：同步证书、App ID 与授权能力
更换 Apple Distribution 证书后，是否要重新生成 Provisioning Profile，取决于签名方式和 Profile 当前绑定内容。手动签名场景要检查 Profile 对应的 App ID、分发类型、证书和授权能力；如果新证书未被纳入，或旧证书撤销导致 Profile 失效，就要编辑或重新生成。Apple 说明，撤销证书后，包含该证书的配置文件会失效；修复方式是编辑或更新相关 Profile。具体流程见编辑、下载或重新生成配置文件的说明。
自动签名也不能只看 Xcode 项目里是否勾选了自动管理。检查构建日志与导出结果，确认 Xcode 使用的 Profile 和签名资产符合预期。自动管理的配置文件可能不显示在开发者账号的 Profile 列表中；需要结合实际 Xcode 流程验证。Apple 的配置文件更新说明还提示，Profile 承载 App ID 与授权信息，因此只换钥匙串证书、却忽略 Profile 和能力变化，可能留下签名不匹配问题。
推荐按下面的顺序同步：
- 记录旧 Profile 的名称、类型、App ID、授权能力和对应流水线。
- 对照新证书确认目标 Profile 是否包含它；同时确认 App ID 与 Bundle ID 匹配。
- 手动签名时，按需编辑或生成 Profile，下载后部署到指定节点。
- 自动签名时，在隔离任务中触发实际构建或导出，检查 Xcode 选用的签名身份与 Profile。
- 如启用或调整了 App 服务能力，再确认 Profile 已包含相应授权；不要把证书变更与能力变更混为一项。
- 保存变更审批、Profile 文件来源、部署记录和验证结果，避免不同流水线各自缓存不同版本。
[ SECTION_04 ] 隔离验收阶段：验证整条 Mac CI 签名链路
先选一个能代表生产签名条件的应用和流水线，在隔离 Mac CI 节点执行验收；不要直接覆盖正式发布任务。节点要使用受控的签名权限和目标 Profile，避免验收任务误用生产环境中未计划替换的资产。
| 验收环节 | 检查项 | 通过条件 |
|---|---|---|
| 资产识别 | 证书类型、团队标识、有效状态、私钥可用性 | 构建使用目标证书；授权范围符合变更审批 |
| 配置文件 | App ID、分发类型、证书、授权能力 | Profile 与应用和签名方式相匹配 |
| 构建签名 | 归档、签名身份、构建日志 | 无签名失败；日志不再意外指向旧资产 |
| 导出交付 | 导出配置、目标渠道、产物检查 | 产物可沿预期路径交付；结果有记录 |
| 回退准备 | 原任务状态、暂停门槛、回退负责人 | 失败时知道停止哪批任务、恢复哪条已验证路径 |
完成验收后，将日志、签名结果、产物检查记录和审批信息关联到同一变更记录。只要关键环节仍依赖旧证书或旧 Profile，或回退条件还未落实，就不要把测试成功等同于生产准入。验收目标是证明实际发布路径可用，不是只证明某个本地命令能签名。
[ SECTION_05 ] 生产切换阶段：分批启用并关闭旧资产风险
按应用或流水线逐批切换。每批开始前，确认使用的新证书、Profile 和节点权限一致；首批交付完成后再推进下一批。提前约定暂停门槛，例如签名身份错误、Profile 失效、目标渠道拒收，或构建日志仍出现计划退役的资产。出现异常就停止扩批，依据最近一次成功记录执行回退，而不是在生产节点上临时改动多项签名设置。
旧证书不要仅因“已经开始轮换”就立即撤销，也不要因担心发布中断而无限期保留。新资产通过生产链路验收、相关任务已切换后，再按证书类别和团队策略处置旧证书、私钥副本及缓存的 Profile。执行撤销前，先列出依赖该证书的 Profile 与分发渠道。Apple 的撤销说明确认，包含已撤销证书的 Profile 会失效；而 Developer ID 等证书的撤销权限和渠道并不完全相同，应按证书撤销权限说明核对，不能把所有类型都当作网页上可直接撤销的同一种资产。
发布恢复也要按渠道判断。App Store 上传受影响，不等于已上架应用必然停止运行；企业内部部署或 Mac 应用外部分发，则可能面对不同的重新签名和安装影响。应先辨明业务受到的是“无法上传新版本”“已分发应用无法运行”还是“用户无法安装新版本”，再选择恢复动作。上线后检查首批生产交付、任务日志和剩余旧资产访问权限，并更新资产清单，记录实际完成的切换与回收情况。
[ SECTION_06 ] 常见问题 FAQ
证书过期后恢复发布
先查清证书类型、分发渠道及账号权限，再确认受影响的 Profile 是否需要更新。手动签名流程应确保节点持有匹配的证书与私钥；自动签名流程则要检查实际使用的签名身份和配置文件。隔离验收归档、导出和交付链路后再恢复生产，避免只更新证书却遗漏 Profile。
更换 Apple Distribution 证书后的 Profile
手动签名时，如果 Profile 未包含新证书，或旧证书撤销使 Profile 失效，就需要编辑或重新生成，并部署到对应构建环境。自动签名时，应验证 Xcode 在归档或导出时实际采用的 Profile。两种方式都要核对 App ID、授权能力和发布渠道；不要仅凭证书已导入判断配置已完成。
正式发布任务之外的验证方式
保留正式任务配置，另建隔离验收任务，使用代表性应用完成签名、归档、导出和目标交付验证。核对日志里的签名身份与 Profile，确认无意外的旧资产引用。只有构建结果、产物检查、审批记录和回退门槛都可追溯后，才按批次切换生产任务。
私钥疑似泄露的处置优先级
这不是普通维护窗口。立即按组织安全流程限制账号、私钥和构建节点的访问，依据证书类型启动撤销或联系 Apple 的对应处理渠道；不要为等待新旧资产并行而推迟响应。撤销可能令相关 Profile 失效，所以要同步安排 Profile 修复、重新签名和受影响发布任务的恢复。
[ SECTION_07 ] 为轮换试点选择构建环境
企业自购 Mac 适合长期、稳定且需要实体接口或固定本地控制的负载，但会带来采购、维护和闲置成本；通用云主机通常不能替代运行 macOS 的真实 Mac 签名节点。若当前方案是把生产签名长期放在共享开发机上，还要面对钥匙串访问边界不清、任务权限混杂、资产回收难审计等问题。远程 Mac 也不是所有团队的默认答案：需要长期固定重负载或物理接口时，应评估自购设备；短期试点、轮换演练或需要隔离节点时，可先规划远程环境与权限边界。
在申请资源前，可先阅读 NOVAKVM 的 Mac 环境选项，并将具体节点是否符合团队签名流程作为验收条件，而不是预设服务能力。若准备把轮换验证放到隔离的远程 Mac 上，可从 NOVAKVM 的 Mac 节点页面了解可选入口；先用试点任务核对环境、访问权限和实际交付路径，再决定是否承接生产任务。这样做的重点不是把证书托管给节点，而是让私钥访问可控、构建记录可审计，并让生产切换仍由团队按自己的变更门槛执行。
常见问题
企业 iOS CI 签名证书过期后，怎样恢复发布？
先确认过期的是哪类证书、受影响的是 App Store 上传还是企业内部分发，再检查账号权限和现有构建路径。更新或重建匹配的 Provisioning Profile，确保构建节点拥有对应证书与私钥，然后在隔离任务中完成归档、导出和目标交付验证。不要只在钥匙串里换证书就直接恢复生产。
更换 Apple Distribution 证书后，配置文件需要重新生成吗？
手动管理签名时，应检查配置文件绑定的 App ID、证书和授权能力；如果配置文件未包含新证书，或因撤销旧证书而失效，就需要编辑或重新生成并部署更新后的文件。自动签名则应在构建或导出时验证 Xcode 实际使用的配置文件，不能仅凭项目设置判断更新已生效。
怎么验证新证书，又不影响正式发布任务？
保留当前生产流水线不动，单独建立隔离的 Mac CI 验收任务，使用代表性应用和独立归档路径。检查签名身份、配置文件、授权能力、导出结果及目标交付记录，并从日志确认没有继续引用旧资产。测试结果、变更审批与回退条件可审计后，再按应用或流水线分批切换。
签名证书私钥疑似泄露时，应该先撤销还是先切流水线？
把疑似泄露当作安全事件处理，不要为了保留新旧证书并行窗口而延迟响应。先限制相关账号、节点和私钥的访问并启动组织的事件流程；随后按具体证书类型及 Apple 的撤销渠道处理，再修复受影响的配置文件、密钥和发布任务。撤销可能使关联配置文件失效，因此要同步安排恢复与重新签名。