我正在创建一个应用程序，它就像一个模板，每个服务提供者都可以在网络上的设置中输入他们的详细信息，只需更改应用程序名称、应用程序图标、新包标识符并将应用程序上传到应用程序商店。到这里为止都很好，但对我来说问题是我在这个应用程序中有一个推送通知服务。
我在苹果文档上读到每个包标识符都应该包含一个唯一的推送证书。然后我们从那里创建一个 .pem 文件，这意味着每个应用程序都会有一个不同的 pem 文件。
但我想要一个适用于所有应用程序的 pem 文件。任何人都可以建议我该怎么做，或者正确的方法是什么？
不幸的是，Apple Push Notifications Service 目前无法满足您的要求。尽管您可以在概念上使用 openssl 中的几个可选参数来使用完全相同的密钥对生成证书签名请求 (CSR)，但根本问题来自于创建证书的第一步中的“证书、标识符和配置文件”工具新的 APNS 证书：
正如补充说明文本所述：“请注意，只有具有特定捆绑标识符的显式应用程序 ID 才能用于创建 [原文如此] 推送 SSL 证书”，这意味着我们既不能为推送通知提供通配符应用程序 ID，也不能我们指定“所有应用程序 ID”。
如果我们短暂地进入一个假设的世界，其中“你想使用哪个 App ID？” 问题不存在，而是直接进入我们上传 CSR 的步骤，我们将从 Apple 取回的证书将完全符合您的要求——它将验证您用于构建 APNS 有效负载的服务器是否合法属于您并被授权向 APNS 网关发送推送。但是，它确实引发了一个重要的安全问题——如果您可以使用这台服务器（或 APNS 术语中的“提供者”）向您的任何应用程序发送推送（只要您知道设备的 APNS 令牌），是什么阻止您使用您的提供商向我的应用程序发送推送？或者，如果我们转而关注——什么会阻止我使用我的授权 APNS 提供商来发送您的应用程序推送通知？或者向您的客户发送带有错误信息的推送（例如，“很遗憾，MyApp 正在关门并退出 App Store。MyApp 建议客户购买 CompetitorApp 以维持您的服务！”）。幸好我们没有生活在这个黏糊糊、容易被骗的世界……
相反，Apple 要求第 3 方开发人员选择 AppId，将接受来自特定 APNS 证书的有效负载。然后，即使我以某种方式设法获取了您客户的应用程序的设备令牌，我也不会拥有您的服务器的私钥，因此无法成功地向您的客户发送诈骗、垃圾邮件或其他流氓 APNS 有效负载。
好的，我已经知道了！由于我不能为多个 App ID 使用一个证书，我该怎么办？
鉴于您问题中的一些背景，听起来您已经努力使您的应用程序具有高度可配置性。用您自己的话说“[it] 就像一个模板” - 这表明在您的应用程序的服务器端，您有一些机制能够识别哪些应用程序正在发出数据请求以及哪个提供商的要发回的数据。您的 APNS Provider 逻辑需要内置类似的智能。根据您当前在服务器端进行这些区分的方式，您可能能够重用一些现有逻辑；你是那个必须打这个电话的人。由于 APNS 强加的每个应用程序一个 pem 的要求，此答案的其余部分将提供一种高级方法来说明您如何选择设置您的提供商。一般来说：
对于您从模板制作的每个应用程序，您已经必须生成一个唯一的 App ID 和 App Store Distribution 配置文件。在执行此初始设置时，您还可以请求 APNS 证书并将所有三段数据视为特定于应用程序的设置。将 APNS 证书与其他应用程序的 .pem 文件一起安装到您的提供商中，以便您可以在需要向 Apple 发送 APNS 有效负载时获取它。
如果您以前做过 APNS 工作，那么您知道您的提供商负责跟踪特定于应用程序的设备推送令牌、生成 APNS 有效负载并将其传输给 Apple，并可选择使用来自 APNS 反馈 API 的信息。当您的应用程序连接到您的提供商以注册其令牌时，您还需要知道该令牌对哪个应用程序有效，以便您可以选择正确的 .pem 来发送 APNS 有效负载。这是关键；如果您无法知道哪些令牌与哪些 App ID 一起使用，那么您将无法在有效负载生成和调度期间选择正确的 .pem 文件。
更新和淘汰软件是所有软件的关键部分，但它并不总是得到应有的关注。确保您已经考虑过如何刷新 .pem 文件（您必须在当前文件过期之前每年都这样做）以及如何在不中断其他应用程序的情况下停用应用程序您的提供商服务。
这些问题的答案在很大程度上取决于您如何构建应用程序的各种组件、Xcode 项目配置、服务器端技术和服务器端逻辑。只有您或您的团队才能根据构成您的软件的详细信息做出正确的决定。祝你好运，让我们知道事情的进展。