Apple Push Notification service 证书有效期为一年，必须每年在 Apple Developer Portal 进行续期，以避免中断设备通信。如果你负责 Capacitor 应用，凭证过期或被撤销会导致即使应用运行正常，推送也无法送达。
这种故障往往在最糟糕的时机出现：新版本发布了，营销活动也排期了，推送却突然中断。你的应用服务器可能仍在接收任务，但 APNs 可能在消息到达设备前就拒绝了 TLS 连接。实际的解决方案不仅仅是重新创建一个证书，你还需要了解系统使用的是哪种 APNs 凭证，妥善保存私钥，规划续期流程，并将合适的业务负载迁移到基于 token 的身份验证。
目录
为什么推送通知会失效
APNs 位于您的服务端与用户的 Apple 设备之间。您的服务器向 Apple 进行身份验证并提交通知，然后依靠 APNs 将其路由到已注册的应用和设备。如果凭证过期、被撤销、身份关联错误或安装不当，请求可能会在开始投递前就失败。
Apple 表示，APNs 维护着一份已撤销证书列表，并会拒绝使用该列表中证书的服务器发起的 TLS 连接。这意味着证书管理不仅是管理偏好，更是确保投递成功的必要条件。即使服务器在本地继续处理通知任务，Apple 也会拒绝该服务端的连接。
将 App 推送与 MDM 推送分离
第一个诊断问题很简单： 您正尝试操作哪项服务？
| 凭证路径 | 其作用 | 典型所有者 |
|---|---|---|
| App 推送 | 向终端用户设备发送警报及其他应用通知 | 移动端或后端工程 |
| MDM 推送 | 让设备管理平台能够与受管理的 Apple 设备通信 | IT、终端或企业移动管理 |
这些凭据不可互换。MDM push 凭据过期后，MDM 平台可能会与已注册设备失联；而 App Push 凭据无效时，应用后端可能无法送达通知。把两者都当成同一个“Apple push certificate”问题，会让排查方向跑偏。
对于 Capacitor 和 Ionic 团队，面向用户的通知通常走 App 推送。应用仍需具备 Push Notifications 能力、正确的签名、设备注册，以及通过合适的 APNs 环境发送通知的后端。如果你的团队还要发布 OTA Web 资源，请把该发布工作流与 push 身份验证分开。该 Capacitor notifications plugin 文档 涵盖应用侧集成，而 APNs 凭据应放在服务商配置中。
从拒绝原因入手，而非 UI
在修改通知文案或重新构建应用之前，先检查服务商服务器返回的 APNs 响应。然后验证 bundle identifier、凭据身份、环境和证书状态。通知权限问题会影响用户能否看到通知，但解释不了 APNs 返回的 TLS 拒绝。
如果故障是在发布后出现的，请对比新 build 与上一 build 的签名和 entitlements。如果未改动应用就出现，请先检查证书过期、吊销、trust-store 变更和 deployment secrets。如需更完整的实施路径，请参阅这份指南： Expo push notification 设置.
创建并下载您的 APNs 证书
如果证书颁发给了错误的 App ID，或者私钥留在另一台 Mac 上，推送任务可能会在发送第一条通知前就失败。Apple 的工作流分为两部分：你的机器会创建一个 证书签名请求 (CSR)（即 CSR），然后 Apple 会针对所选的 App ID 对其进行签名。CSR 并不是服务器凭据，它的作用是将颁发的证书与本地创建的私钥关联起来。
准备 App ID
登录 Apple Developer 门户并打开 Certificates、Identifiers 与 Profiles。选择 Identifiers，选择应用的 bundle identifier，然后打开其配置。确认 推送通知 在签发任何内容之前必须启用。
APNs 凭据与应用身份绑定。请勿选择名称相似的相邻 bundle identifier。请为每个独立的应用程序进行独立配置，并签发匹配的凭据。
在保留密钥的 Mac 上，打开 钥匙串访问 并创建 CSR，或使用组织认可的证书工具。请确保请求文件和私钥由同一受控所有者保管。如果由另一位管理员创建 CSR，该管理员可能会持有后续生成可用服务器 bundle 所需的私钥。
签发已签名的证书
在 证书，选择 Apple Push Notification service certificate 选项。选择 App ID，上传 CSR 并提交请求。下载 Apple 签发的证书。
在拥有私钥的 Mac 上双击下载的文件。它应当安装在 钥匙串访问，在这里你可以验证证书及其匹配的私钥。如果导入证书时缺少该私钥，则无法提供后端所需的完整凭据。
建议使用包含应用身份、环境、所有者及过期详情的命名规范。将原始证书、CSR 所有权信息和 Portal 账户详情存储在团队的凭据管理系统中。开发者的 Downloads 文件夹或个人笔记本电脑不应作为运维备份。
该证书仅支持推送流程中的一部分。App 必须注册远程通知，服务器必须保留生成的 device token，且推送服务商必须使用匹配的 topic 和环境进行发送。请将这些依赖项记录在同一个 runbook 中。关于客户端配置，请参阅 Capacitor 通知集成指南。请将此证书视为受管理的凭据，而非一次性下载的文件，因为后续的导出、token 迁移、续期和恢复都取决于是否掌握其密钥控制权。
将证书导出为私钥
下载的 Apple 证书无法直接用于 Node.js 服务或托管推送服务商。服务器需要证书及其对应的私钥，通常以以下格式打包： PKCS#12 .p12 文件.
打开 钥匙串访问 在安装证书的 Mac 上。搜索 APNs 证书，展开或检查它，并找到具有匹配身份和过期信息的私钥。同时选中证书和私钥，然后使用导出操作保存一个 .p12 文件中设置。
部署前验证 bundle
为导出的文件设置一个强密码。该密码用于保护 bundle 内的私钥，因此切勿将其放入代码仓库、工单、聊天消息或 build log 中。请通过您的密钥管理系统上传文件和密码，并仅授予发送通知的服务访问权限。
实用原则： 一个
.p12文件（若缺少匹配的私钥）并不是完整的服务商凭据。
在正式上线前，请在受控环境中测试该 bundle。确认您的后端能够加载文件、建立 APNs 连接，并在 Apple 拒绝请求时返回结构化错误。如果 Capgo 等服务商需要 iOS 推送凭据，请通过 .p12 指定的密钥配置上传文件及其密码，而不是将这两个值硬编码在应用 code 中。
这种格式也暴露了旧版工作流的弱点。您必须保留原始私钥、重复手动导出操作、保护文件，并在续期时更换部署密钥。管理多个 App 的团队很容易搞混哪个 bundle 对应哪个 App ID。
使用 在 CI/CD pipeline 中实现安全的密钥管理 以控制谁可以读取或替换凭据。请保留上传和轮换的审计日志，但切勿记录私钥或 .p12 密码。
对于新的后端开发，请评估证书认证是否仍然适用。现有集成可能需要 .p12，但 Token 认证通常可以让提供商连接不再需要每年更换证书。这并不会消除凭据治理，只是改变了你需要保护和轮换的内容。
迁移至全新的 Token 认证方式
Apple 已将 APNs 认证转向 提供商 Token，通常称为 p8 工作流。你的提供商不再需要为长期 TLS 身份出示证书和私钥，而是使用 Apple Push Notification service Authentication Key 对认证 Token 进行签名。
请在 Apple Developer 门户的以下位置创建该密钥： Certificates、Identifiers 与 Profiles，然后打开 密钥 并注册一个 APNs 身份验证密钥。下载该 .p8 文件，并将关联的 Key ID 和 Team ID 记录到密钥存储中。将下载的文件视为高价值签名密钥。
有计划地进行迁移
切勿通过在未经测试的环境中替换文件来切换生产流量。应与现有证书路径并行构建 token 身份验证，验证 sandbox 和 production 环境中的行为，并对比 APNs 响应。然后在受控部署期间更改 provider 配置。
此次迁移移除了发送路径中的证书续期和 Keychain 导出步骤，但团队仍需明确权责模型。确定谁可以创建、撤销和部署密钥。限制对签发 provider token 的后端服务的访问，并确保在当前密钥不可用前已有应急更换流程。
对于 Capacitor 应用，客户端仍需正确的通知注册和 entitlements。此次迁移主要改变的是 服务器到 APNs 的身份验证，而非设备 token 注册 code。你的后端必须继续将 token 与正确的应用和环境关联。
了解何时仍需使用证书
一些企业级工具和成熟的集成方案仍在使用基于证书的配置。在接收端系统支持 p8 且你的团队已完成全链路测试之前，不要强行迁移。在过渡期间请妥善保护旧凭据，但如果可以使用 token 认证，请避免产生新的依赖。
如果你需要了解相关的应用流程，请查看 Ionic 与 Capacitor 使用 Firebase 的推送通知。Firebase 可以提供应用交付层，但 Apple 凭据、entitlements、注册以及 APNs 响应仍需要进行精细配置。
续订和管理证书生命周期
从创建 APNs 证书的那天起，就应将其视为具有时效性的生产环境依赖。Apple 表示这些证书的有效期为 创建之日起一年 且必须在过期前续期以维持设备通信。Apple 还警告称，未能及时续期可能导致用户需要重新在 APNs 上注册 iOS、iPadOS 和 Mac 设备，并可能引发服务中断。请参阅 Apple 的 推送通知证书续期文档.
续期流程如下：
- 生成新的 CSR： 通过你批准的工作流创建请求，并妥善保存关联的密钥材料。
- 使用原有的 Apple ID： 请使用创建现有证书时所用的同一个 Apple ID 进行登录。
- 选择即将过期的证书： 在选择之前，请核对 App ID、Subject DN、UID 及过期详情是否匹配 续期.
- 上传 CSR： 在 Apple Push Certificates Portal 中提交新的请求。
- 下载并重新安装： 获取续期后的
.pem，在私钥所在位置进行安装，并导出替换文件.p12（如果您的服务商有此要求）。 - 部署与测试： 更新服务器密钥，发送一条受控通知，并检查 APNs 响应。
对比各供应商的格式
| 要求 | 证书工作流 | Token 工作流 |
|---|---|---|
| 主密钥 | 证书 + 私钥 | .p8 认证密钥 |
| 续期问题 | 证书过期需定期更换 | 无需每年更换证书 |
| 部署工作 | 安装、配对、导出与上传 | 存储签名密钥并配置 Token 生成 |
| 主要失败风险 | 证书错误、缺失私钥、过期或被吊销 | 身份验证密钥丢失、泄露或被吊销 |
Apple 的证书生态系统也需要定期进行信任链维护。Apple 宣布针对 Sandbox 环境的 APNs 服务器证书更新将于 2025 年 1 月 20 日 生效，而针对 Production 环境的更新将于 2025 年 2 月 24 日生效，这要求信任库必须包含 SHA-2 Root USERTrust RSA Certification Authority 证书。阅读 Apple APNs 服务器证书公告 并将信任库所有权纳入平台检查清单。
使用共享的续期日历、指定负责人和部署 Runbook。 Capgo 证书管理文档 可以与那份 Runbook 放在一起，供在移动发布流程中管理 iOS 交付凭证的团队参考。
故障排查与凭证丢失处理
最棘手的事故并不总是过期警告，而是某天早上发现：创建证书的管理员已经离职、私钥只存在一台旧 Mac 上，或者证书在尝试清理时被撤销。标准续期流程依赖原始 Apple ID 和正确的证书身份，因此访问权限和来源追溯与文件本身同样重要。
首先对故障进行分类：
- 证书过期： 通过原始账号生成替代证书，用匹配的私钥重新安装，更新推送提供商并测试推送。如果设备通信已经中断，请遵循 Apple 的恢复指南，不要以为在服务端替换证书就能立即恢复所有设备。
- 证书撤销： 不要再把旧凭证当作可恢复的。Apple 会拒绝使用已撤销证书的服务器建立 TLS 连接，因此请创建有效的替代证书，并将已撤销的密钥从当前部署中移除。查明是谁撤销的，以及其他系统是否复制了同一凭证。
- 丢失
.p12密码： 如果证书文件缺少可用的密码，可能会导致业务中断。请获取已批准的备份或直接签发新证书，切勿降低生产环境的密钥控制强度。 - 丢失私钥： 重新下载公钥证书无法找回私钥。请在受控机器上创建新的 CSR，并签发新的凭据。
- 丢失 Apple ID 访问权限： 请确认组织是否可以通过其身份验证和部署流程找回账号。对于通过相关门户创建的 APNs 证书，Apple 将支持请求引导至 部署计划支持.
找回账号需要身份验证，而不仅仅是一个文件名。 在事故发生前，请记录 Apple ID 所有者、App ID、证书身份、私钥位置、供应商配置以及更换流程。
构建运维安全网
管理证书与 .p8 存储在受访问控制的共享保险库中。将 .p12 密码与文件分开存储，限制生产环境的访问权限，并记录用于续期的确切门户账号。您的 CI/CD 系统应在部署时注入 secrets，并运行健康检查，以便在用户报告推送缺失之前检测到身份验证失败。
在平台允许的情况下，进行受控更换时请保留旧凭据，但不要无限期地启用过时的 secrets。在生产环境使用的相同后端路径中测试更换方案，包括提供商环境、bundle identifier 和 device-token 存储。
当故障已经发生时，请保留 APNs 响应体和时间戳，识别第一个被拒绝的请求，并对比事故前后部署的 secret。不要针对无效凭据进行无限重试。先修复身份或身份验证问题，然后向已知的测试设备发送一条小的验证通知。
Capgo 可以将 iOS 推送凭据作为 Capacitor 通知工作流的一部分进行存储和配置，而您的团队仍需负责 Apple 账号访问、secret 管理及续期决策。请访问 Capgo 以了解其移动端交付工具如何配合您的 APNs 凭据生命周期和发布流程。
