很遗憾，目前苹果推送通知服务无法实现您所要求的功能。虽然您可以在 OpenSSL 中使用多个可选参数来生成一个证书签名请求（CSR），使用完全相同的密钥对，但根本问题来自于创建新的 APNS 证书的第一步中的“证书、标识符和配置文件”工具：
如补充说明文字所述：“请注意，只有具有特定 Bundle Identifier 的显式 App ID 才能用于创建 Push SSL 证书”，这意味着我们既不能为推送通知提供通配符 App ID，也不能指定“所有 App ID”。
如果我们暂时进入一个假设的世界，在那里，“您想使用哪个 App ID？”这个问题不存在，而是直接进入上传 CSR 的步骤，我们从 Apple 得到的证书将会完全满足您的需求——它将验证您用于构建 APNS 负载的服务器是合法属于您并被授权向 APNS 网关发送推送的。然而，它确实开启了一个重要的安全问题——如果您可以使用此服务器（或 APNS 术语中的“提供者”）向任何应用程序发送推送（只要您知道设备的 APNS 令牌），那么什么阻止您使用您的提供者向我的应用程序发送推送？或者如果我们反过来考虑这个问题——什么阻止我使用我的授权 APNS 提供者向您的应用程序发送推送通知？或向您的客户发送错误信息（例如“遗憾的是，MyApp 将关闭其业务并退出 App Store。MyApp 建议客户购买 CompetitorApp 以维护您的服务！”）。这是一个卑鄙、容易受骗的世界，我们幸运地没有生活在这样的世界中……
相反，苹果要求第三方开发人员选择一个 AppID，以便特定 APNS 证书的负载将被接受。即使我设法获得了您客户的应用程序设备令牌，我也没有您服务器的私钥，因此无法成功地向您的客户交付欺诈、垃圾邮件或其他恶意的 APNS 负载。
好的，我已经明白了！既然我不能为多个 App ID 使用单个证书，那么我能做些什么呢？
考虑到您的问题背景，似乎您已经付出了努力，使您的应用程序高度可配置。用你自己的话来说，“它就像一个模板”，这表明在您的应用程序的服务器端，您有一些机制可以识别哪个应用程序正在进行数据请求以及要发送回哪个提供程序的数据。您的APNS提供程序逻辑需要内置类似的智能。根据您当前的服务器端区分方式，您可能能够重用一些现有的逻辑；您是必须做出决定的人。本答案的其余部分将提供一种高层次的方法，介绍如何设置您的提供程序以满足APNS强制实施的每个应用程序一个.pem的要求。总的来说：
- 在您的APNS提供程序上放置已签名的.pem文件的副本
- 更新您的提供程序的“注册设备令牌”API，以接受设备令牌以及某种方式唯一地标识此令牌有效的应用程序（...也许只是App ID本身！）
- 更新iOS应用程序，将其APNS设备令牌和该应用程序标识符传递给您的提供程序上最新更新的“注册设备令牌”API。
- 更新您的提供程序逻辑以在向APNS网关传递有效载荷时使用正确的.pem。
- 为了良好的流程，请确保您有更新或撤销应用程序的.pem、数据和相关令牌的程序。
对于您从模板创建的每个应用程序，您已经必须生成唯一的应用程序ID和应用程序商店分发配置文件。在进行此初始设置时，您还可以请求APNS证书，并将所有三个数据部分视为特定于应用程序的设置。将APNS证书安装到您的提供程序中，与其他应用程序的.pem文件一起，以便在发送APNS有效载荷到Apple时获取它。
如果您以前做过APNS工作，那么您知道您的提供程序负责跟踪特定于应用程序的设备推送令牌，生成和传输APNS有效载荷到Apple，并可选择使用来自APNS反馈API的信息。当您的应用程序连接到您的提供程序以注册其令牌时，您还需要知道该令牌有效的应用程序是哪一个，以便您可以选择正确的.pem文件发送APNS有效载荷。这是关键的；如果您没有一种方法来知道哪些令牌与哪些应用程序ID相关联，则将无法在有效载荷生成和调度期间选择正确的.pem文件。
更新和淘汰软件是所有软件的关键部分，但它并不总是得到应有的关注。确保您考虑了如何刷新.pem文件（每年在当前文件过期之前必须这样做），以及如何淘汰一个应用程序而不会干扰您的提供程序服务的其他应用程序。
每个问题的答案都非常依赖于你是如何设计你的应用程序、Xcode项目配置、服务器端技术和服务器端逻辑的各个组件。只有你或你的团队才能根据构成你的软件的细节做出正确的决策。祝好运，让我们知道进展情况。
