多个产品的证书和配置文件组织

Question

在我的工作场所,我们已经完成了一个iOS应用程序的开发,并即将开始一秒钟.

在此之前,我想澄清一些有关证书和配置文件以及构建环境的内容:

问题1:我认为Apple帐户只能拥有一个分发证书,这是否正确,因此这将在两个应用程序中使用？(通过它出现在配置文件中,我将创建一组新的配置文件,其中包含新应用程序的新应用程序ID).

Q2:由于它是证书而不是安装在钥匙串中的配置文件,我假设新应用程序应该构建在当前为当前应用程序设置的构建机器上.

Q3:与Q2相关,我想知道是否有必要或者好主意将当前应用程序和新应用程序的构建通过将它们放在不同的物理构建机器上(或将构建机器分区为虚拟机)来分离.如果两个应用程序使用不同的证书,我认为这是必要的(或至少分区钥匙串).我担心会出现证书和钥匙串问题.但是,如果对Q1的答案是只有一个分发证书,那么理论上应该不需要为每个应用程序分别构建机器吗？

问题4:两个应用程序都使用推送通知,是否可以为两者使用相同的推送证书(当然在不同的配置文件中)？

TIA

Answer 1

证书和配置可能是一个棘手的话题，因此在无意中给自己带来一些痛苦之前先询问一下无疑是个好主意！

Q1：每个账户只能有一张分发证书吗？

是的，个人和公司帐户每个会员年度仅限于一个有效的分发证书，但是如果个人或公司认为有必要，可以随时撤销并重新颁发该证书（公钥/私钥泄露、解雇员工可以访问私钥等）。我最近回答了一个问题“什么是代码签名身份？” 这可能有助于提供一些有关编码到配置文件中的信息以及 Xcode 在执行设备构建时如何查找此信息的额外上下文。请记住，根据所使用的配置文件类型（开发与分发），将改变配置配置文件中编码的证书和测试设备的数量和类型。

您也是绝对正确的，因为您将使用一组全新的配置文件重用现有的分发证书，这些配置文件是使用您准备/正在编写的第二个应用程序的应用程序 ID/捆绑包 ID 进行编码的。

问题 2：在钥匙串中安装的是证书而不是配置文件，对吧？构建机器会受到什么影响？

是的，这是正确的。您的开发证书和分发证书都会安装到钥匙串中，而配置文件则安装到 Xcode 中的特殊目录中以用于代码签名操作。

假设您已经设置了构建机器并正在为您的第一个应用程序工作，那么您已经完成了很多艰苦的工作。您仍然需要做的事情的高级列表：

• 使用现有证书为新 AppId 生成一组配置文件
• 在构建环境中安装配置文件
• 确保 Xcode 项目的“代码签名身份”构建设置配置为使用新创建的配置文件，或者更理想的是使用“自动配置文件选择器”（如果您的项目配置允许）。
• 配置您的构建系统以实际创建新应用程序。

这些高级任务的具体 HOWTO 在某种程度上取决于您如何设置项目和构建系统，但通常应遵循构建第一个应用程序时使用的相同工作流程。

问题 3：将构建环境分区到不同的机器上是否有必要/好主意？

至于这个问题的“必要”部分，不，您不需要物理或虚拟地分离构建环境以便能够并行构建这些应用程序，但是如果您的业务需要，您可以选择这样做需求使得您需要基于每个应用程序的专用构建环境。

从技术角度来看，配置文件提供了并行构建所需的 99% 的分区。唯一一次您遇到可能需要物理或虚拟分区的情况是，如果您是两个或多个 iOS 开发计划的成员，并且每个团队颁发的证书上的“通用名称”相匹配（例如， “iPhone Distribution: MyCompany”是 Team1 颁发的证书的通用名称，与 Team2 颁发的证书完全相同。如果出现这种情况，您会在 Xcode 中看到如下警告和错误：

代码签名错误：证书身份“iPhone Distribution: MyName”在钥匙串中出现多次。协同设计工具只需要一个。

在所有其他情况下，假设您安装了证书和配置文件，并且正确设置了代码签名身份值，则代码签名可以自行处理。

Q4：两个应用程序可以重复使用相同的推送证书吗？

这是一个坚定的“不”。每个应用程序 ID 都有自己的一组配置文件，并附有一组权利，其中一个是推送通知。使用推送通知权利构建新的配置文件时，系统会要求您生成新的推送证书 - 没有机会向 Apple 提供现有证书。这样做是为了确保推送通知“提供程序”（创建发送到 Apple 推送网关的推送通知有效负载的服务器）以类似于 iOS 生态系统中的方式进行沙箱处理 - 每个 AppId 一个提供程序...一个每个 AppId 的沙箱。

从安全角度来看，这可以防止攻击者只需在 Apple 的推送网关上提供有效的推送令牌和有效负载即可向您的用户发送垃圾推送通知。设置提供商代码的第二个实例并使用在创建新的配置文件时生成的推送证书，或者更新现有提供商以跟踪每个应用程序级别的推送通知令牌，并在发送推送通知负载时使用正确的证书到苹果。不幸的是，只有您（或您的同事）可以做出此决定，因为该决定将取决于您现有提供商的技术能力以及您/您的公司愿意在同一提供商实例上采取统一推送通知的风险程度。

其他人可能会在这里提出一些关于他们如何设置自己的提供程序的额外见解，但我使用了完全独立的实例，以防止出现一个应用程序的推送通知更新可能会破坏另一个完全不同的应用程序的推送通知的情况。