多个产品的证书和配置文件组织 [英] Certificates and profile organization for multiple products

问题描述

在我的工作场所，我们已经完成了一个 iOS 应用的开发，即将开始.

At my workplace we have completed development on one iOS app and are about to embark upon a second.

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

Before doing so I wanted to clarify a few things regarding certificates and profiles and build environments:

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

Q1: Am I correct in thinking that an Apple account can only have one distribution certificate, and that therefore this will be used in both apps? (via it being present in the provisioning profiles, I'll be creating a new set of profiles containing a new app id for the new app).

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

Q2: As it is the certificates and not the profiles that are installed into the keychain, I am assuming the new application should just build on the build machine that is currently set up for the current application.

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

Q3: Related to Q2, I am wondering if it is necessary, or a good idea, to have the builds for the current app and the new app separated by putting them on different physical build machines (or partition the build machine into virtual machines). If the two apps were using different certificates I would think this is necessary (or at least partition the keychain). I'm worried about certificate and keychain issues arising. However if the answer to Q1 is that there is only one distribution certificate then there should in theory be no need to have separate build machines for each application?

Q4:两个应用都使用推送通知，是否可以为两者使用相同的推送证书(当然在不同的配置文件中)?

Q4: Both apps use push notifications, is it ok to use the same push certificate for both (in a different profile of course)?

TIA

推荐答案

证书和供应可能是一个棘手的话题，所以在不经意间给自己造成一些痛苦之前先询问一下当然是个好主意！

Certificates and Provisioning can be a tricky topic, so it is certainly a good idea to ask first before inadvertently causing yourself some pain!

问题 1:每个帐户只有 1 个分发证书?

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

Yes, Individual and Company accounts are limited to a single active Distribution certificate per membership year, however this certificate may be revoked and reissued at any time if the Individual or Company deems it necessary to do so (compromised Public/Private key, termination of employees with access to the private key, etc.). I recently answered a question "What are Code Signing Identities?" that may be helpful in providing some additional context about the information that is encoded into a Provisioning Profile and how Xcode looks up this information when performing Device builds. Do keep in mind that depending on the type of Provisioning Profile used (Development vs. Distribution) will alter the number and type of Certificates and test devices encoded in a Provisioning Profile.

您也完全正确，因为您将使用一组全新的配置文件重用现有的分发证书，这些配置文件使用您准备/正在编写的第二个应用程序的 App Id/Bundle Id 进行编码.

You are also absolutely correct in that you will reuse the existing Distribution Certificate with an entirely new set of Provisioning Profiles that are encoded with the App Id / Bundle Id of the second application you are getting ready to / are writing.

问题 2:在钥匙串中安装的是证书而不是配置文件，对吗?构建机器会受到怎样的影响?

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

Yes, this is correct. Both your Development Certificate and Distribution Certificate are what get installed into Keychain while Provisioning Profiles are installed into a special directory within Xcode for use with Code Sign operations.

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

Assuming you've got your build machine setup and working for your first app, you've got a lot of the hard work done. A high level list of things you'll still need to do:

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

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

Specific HOWTOs for these high-level tasks will be somewhat dependent on how you've setup your project and build system, but generally should follow the same workflow as was used when constructing the first app.

Q3:将构建环境分区到不同的机器上是否必要/好主意?

就这个问题的必要"部分而言，不，不需要您在物理上或虚拟上将构建环境分开以能够并排构建这些应用程序，但是您可以 如果您的业务需要需要基于每个应用程序的专用构建环境，请选择这样做.

As far as the 'necessary' part of this question, No, it is not required that you physically or virtually separate the build environments to be able to build these apps side-by-side, however you could elect to do so if your business needs are such that you required dedicated build environments on a per-application basis.

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

From a technical perspective, the Provisioning Profiles provide 99% of the partitioning necessary to be able to build side-by-side. The only time you would run into a situation where physical or virtual partitioning may be required would be if you were a member of two or more iOS Development Programs and the 'Common Names' on the certificates issued by each of these teams matched (ex. "iPhone Distribution: MyCompany" was the Common Name of the certificate from Team1 and was absolutely identical to a certificate issued by Team2). If this were ever the case you'd see warnings and errors in Xcode like the following:

代码签名错误:证书身份iPhone 分发:MyName"在钥匙串中出现不止一次.协同设计工具只需要一个.

Code Sign error: Certificate identity 'iPhone Distribution: MyName' appears more than once in the keychain. The codesign tool requires there only be one.

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

In all other cases, assuming you have both your Certificates and Provisioning Profiles installed and the Code Signing Identity value set correctly, then Code Sign can take care of itself.

Q4:是否可以为两个应用重复使用相同的推送证书?

这是一个坚实的不".每个 App Id 都有自己的一组供应配置文件，这些配置文件伴随着一组权利，其中一个是推送通知.在构建具有推送通知权利的新配置文件时，系统会要求您生成新的推送证书——没有机会向 Apple 提供您现有的证书.这样做是为了确保推送通知提供者"(创建发送到 Apple 推送网关的推送通知有效负载的服务器)以类似于 iOS 生态系统中的方式进行沙箱化——每个 AppId 一个提供者......每个 AppId 的沙箱.

This one is a solid 'No'. Each App Id has its own set of Provisioning Profiles which are accompanied by a set of Entitlements, of which one is Push Notifications. When constructing a new Provisioning Profile with the Push Notification entitlement, you are asked to generate new Push Certificates -- There is no opportunity to provide your existing certificates to Apple. This is done to ensure that a Push Notifications 'Provider' (your server that creates the Push Notification payloads sent to Apple's Push Gateway) is sandboxed in a way similar to that found within the iOS ecosystem -- one provider per AppId...one sandbox per AppId.

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

From a security standpoint, this prevents an attacker from sending spammy push notifications to your user simply by providing a valid Push token and payload at Apple's Push Gateway. Either setup a second instance of your provider code and use the Push Certificates generated while making the new Provisioning Profile or update your existing provider to keep track of Push Notification tokens on a per-application level and use the right certificate when sending a Push Notification payload to Apple. Unfortunately, only you (or your colleagues) can make this determination as that decision will be governed by the technical capabilities of your existing provider and the degree of risk you/your company is willing to take unifying Push Notifications on the same provider instance.

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

Others may pipe up here and provide some additional insight about how they setup their own providers, but I've gone with entirely separate instances to prevent a scenario where updates for one app's Push Notifications could break Push Notifications for an entirely different app.

这篇关于多个产品的证书和配置文件组织的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！