iOS发布证书怎么申请

一、先理解三个核心对象

发布证书用于确认发布者身份；Bundle ID 用于唯一标识 App；描述文件把证书、Bundle ID 和发布方式关联在一起。

• Bundle ID：决定 App 在 Apple 体系中的唯一身份。
• Apple Distribution 证书：用于正式发布签名。
• Provisioning Profile：把证书、Bundle ID 和发布用途绑定起来。

只要其中任意一个对象错了，就很容易在归档、导出或上传阶段报错。

二、iOS 发布证书申请顺序

更稳妥的顺序通常是：

1. 先确认 App 的 Bundle ID。
2. 生成 CSR 并创建有效的 Apple Distribution 发布证书。
3. 下载证书并导出 P12。
4. 创建 App Store 类型的 Provisioning Profile。
5. 把证书和描述文件安装到构建环境，再做归档。

顺序看起来简单，但很多问题恰恰出现在“先做了证书，后面又改了 Bundle ID”或者“换了证书却忘了重做描述文件”。

三、配置时要重点检查什么

• 证书是否有效、是否被撤销、是否属于正确团队。
• Bundle ID 是否与工程、Target 和 App Store Connect 完全一致。
• 描述文件是否包含当前发布证书。
• 导出配置是否使用正式发布签名，而不是开发或测试签名。

多人协作时，还要额外确认自己拿到的是最新证书，而不是别人历史遗留的旧文件。

四、为什么证书更新后常常还要重做描述文件

证书更新后通常需要重新生成描述文件。原因很简单：描述文件里关联的是“某一批可用证书”，不是一个永远自动同步的逻辑关系。

如果旧证书过期、被撤销，或者你换成了新的 Distribution 证书，那么对应的 Provisioning Profile 也应该重新生成和下载。否则最常见的结果就是：工程看起来配好了，但归档或上传还是报签名错误。

五、P12 文件和密码怎么保管更稳妥

P12 文件和密码本身就是发布能力的一部分，建议：

• 按团队、项目和用途分开保存。
• 限制访问范围，不要随意群发。
• 不要把密码写进公开截图、文档链接或代码仓库。
• 证书更新、人员变更或项目交接时，及时做替换与回收。

如果团队长期维护多个项目，更适合使用统一的证书管理流程或工具，而不是每个人各自保存在本机桌面。

六、常见问题

1. 发布证书、Bundle ID 和描述文件是什么关系？

发布证书用于确认发布者身份，Bundle ID 唯一标识应用，描述文件会把证书、Bundle ID 和发布方式关联在一起。三者都要匹配，签名才会正确。

2. 为什么证书更新后还要重做描述文件？

因为描述文件内部会关联可用证书。当旧证书失效、被撤销或换成新证书时，对应的 Provisioning Profile 也应重新生成。

3. P12 文件和密码应该怎么保管？

建议按团队和项目分开保存，限制访问范围，并避免把密码写进公开文档、聊天截图或代码仓库。多人协作时更适合放进受控的证书管理流程中。