Apple Push Notification Serviceの証明書は1年間有効で、Apple Developer Portalで年次更新しないと、デバイス間の通信を中断する可能性があります。Capacitorアプリの責任者なら、有効期限切れまたは取り消された資格情報は、通知が送信されないままアプリ自体が正常に動作しているように見える場合があります。
最悪の時期に失敗が表面化することがよくあります。リリースが行われ、キャンペーンが計画され、通知の配信が突然沈黙することがあります。アプリケーションサーバーはまだジョブを受け付けるかもしれませんが、APNsはTLS接続を拒否し、メッセージがデバイスに到達する前に、通知が送信されないようになります。実際の解決策は、単に別の証明書を作成するだけではありません。システムが使用するAPNs資格情報を理解し、プライベートキーを保存し、更新を計画し、トークンベースの認証に適したワークロードを移行する必要があります。
目次
- Push通知が停止する理由
- APNs証明書の作成とダウンロード
- 証明書をプライベートキーの形式でエクスポートする
- トークンベースの認証に移行する
- 証明書の更新と管理
- トラブルシューティングと失われた資格情報の処理
プッシュ通知が機能しない理由
APNsは、プロバイダーのサーバーとユーザーのAppleデバイスの間にある。サーバーはAppleに認証し、通知を提出し、APNsに依存して登録されたアプリケーションとデバイスに通知をルーティングする。資格情報が期限切れ、削除された、不正確なIDに関連付けられた、または不正にインストールされた場合、リクエストは配信開始前に失敗する可能性があります。
Appleは、APNsが削除された証明書のリストを保持し、リストに記載されている証明書を使用するサーバーからのTLS接続を拒否することを述べています。これにより、証明書の管理は配信の要件となり、管理上の好みではなくなります。サーバーは、Appleがプロバイダーの接続を拒否した場合でも、通知ジョブをローカルに処理できます。
アプリプッシュとMDMプッシュを分離
最初の診断質問は簡単です: どのサービスを操作しようとしているのですか?
| 資格情報のパス | 機能すること | 一般的な所有者 |
|---|---|---|
| App Push | エンドユーザー機器に警告や他のアプリケーション通知を送信します。 | モバイルまたはバックエンドエンジニアリング |
| MDM Push | 管理されているAppleデバイスと通信することをデバイス管理プラットフォームに許可します。 | IT、エンドポイント、またはエンタープライズモビリティ管理 |
これらの資格情報は入れ替えられません。MDMプラットフォームはMDM Push資格情報が期限切れになったときに登録済みデバイスから連絡を断ち切ることがあります。一方、Application BackendはApp Push資格情報が無効なので、通知の配信を失うことになります。両方を「Apple Push Certificate」として扱うことは、トラブルシューティングを誤った方向に導くことになります。
For Capacitor and Ionic teams, the relevant path for user-facing alerts is generally App Pushです。アプリはPush Notifications機能、正しい署名、デバイスの登録、およびAPNs環境を通じて適切なバックエンドが送信する必要があります。チームがオーバー・ザ・エアのWebアセットを配信する場合、リリースフローを別々に保つ必要があります。 Capacitor の通知プラグインドキュメント アプリケーション側の統合については、ドキュメントを参照してください。APNsのクレデンシャルは、プロバイダーの設定に含まれます。
拒否から始めましょう。UIではなく。
APNsのレスポンスを確認する前に、通知コピーを変更したりアプリを再構築したりするのをやめましょう。次に、バンドルID、クレデンシャルID、環境、証明書のステータスを確認してください。通知許可の問題は、ユーザーがアラートを表示できないようにしますが、APNsからTLSの拒否を説明するものではありません。
リリース後に失敗が発生した場合は、新しいビルドの署名と特権を元のビルドと比較してください。アプリの変更なしで失敗した場合は、証明書の有効期限、削除、信頼ストアの変更、デプロイシークレットを最初に調べる必要があります。より広い実装方法については、このガイドを参照してください。 Expoのプッシュ通知設定.
APNs証明書の作成とダウンロード
プッシュロールアウトは、最初の通知が送信される前に失敗する可能性があります。証明書が間違ったApp IDに発行されている場合、またはプライベートキーが別のMacに残っている場合です。Appleのワークフローには2つの部分があります。マシンは、選択したApp IDに署名されたCSRを作成し、Appleはそれを署名します。CSRはサーバークレデンシャルではありません。発行された証明書をプライベートキーと紐付けます。 App IDの準備Apple Developer ポータルにサインインし、
証明書署名要求
、またはCSRを作成します。Appleは選択したApp IDに署名します。CSRはサーバークレデンシャルではありません。発行された証明書をプライベートキーと紐付けます。 証明書、識別子、プロファイル. 選択 識別子, アプリのバンドル識別子を選択し、その設定を開きます。確認する Push Notifications は有効になっていることを確認してください。
APNs の資格情報はアプリケーションのアイデンティティに紐づけられています。近くのバンドル識別子に似た名前のものを選択しないでください。各アプリケーションごとに独立して設定し、対応する資格情報を発行してください。
Mac でキーの保持するコンピューターを開き、 Keychain Access を開き、CSR を作成し、または組織の承認された証明書ツールを使用してください。要求ファイルと秘密鍵は同じ管理下で保管してください。別の管理者が CSR を作成した場合、その管理者は後で使用可能なサーバー バンドルに必要な秘密鍵を保持する可能性があります。
Issue the signed certificate
In 証明書を選択し、App IDを選択し、CSRをアップロードし、申請を送信してください。Appleが発行した証明書をダウンロードしてください。
ダウンロードしたファイルをMacでダブルクリックしてください。プライベートキーを所有するMacでインストールしてください。 Keychain Accessで、証明書とマッチングするプライベートキーを検証してください。プライベートキーが存在しない証明書をインポートすると、バックエンドが必要とする完全な資格情報を提供できません。
アプリケーションID、環境、オーナー、有効期限を記録する命名規則を使用してください。元の証明書、CSRの所有権情報、ポータルアカウントの詳細をチームの資格情報システムに保存してください。開発者のダウンロードフォルダや個人のラップトップは、運用上のバックアップではありません。
証明書は、配信の1つの部分のみをサポートします。アプリはリモート通知の登録を行い、サーバーは結果のデバイストークンを保持し、プロバイダーはマッチングしたトピックと環境で送信する必要があります。依存関係を同じランブックに保管してください。クライアント側の設定については、 Capacitorの通知統合ガイドを参照してください。
証明書をプライベートキーのエクスポート
A downloaded Apple certificate isn’t automatically ready for a Node.js service or a managed push provider. The server needs the certificate and its corresponding private key, commonly packaged as a PKCS#12 .p12 file.
Open Keychain Access on the Mac where you installed the certificate. Search for the APNs certificate, expand or inspect it, and locate the private key with the matching identity and expiration information. Select the certificate and private key together, then use the export action to save a .p12 file.
Validate the bundle before deployment
Give the export a strong password. The password protects the private key inside the bundle, so don’t place it in a repository, ticket, chat message, or build log. Upload the file and password through your secret-management system, then grant access only to the service that sends notifications.
Practical rule: A
.p12file without its matching private key is not a complete provider credential.
生産環境での使用前に、制御された環境でバンドルをテストしてください。 バックエンドがファイルを読み込むことができ、APNs接続を確立し、Appleがリクエストを拒否した場合に構造化されたエラーを返すことを確認してください。 例えば、CapgoのようなプロバイダーがiOSプッシュ認証情報を要求した場合、 .p12 and its password through the designated secret configuration rather than embedding either value in application code.
このフォーマットは、古いワークフローの弱点も明らかにしています。 元のプライベートキーを保存し、手動のエクスポートを繰り返し、ファイルを保護し、更新時にはデプロイシークレットを置き換える必要があります。 複数のアプリを運営するチームは、どのバンドルがどのApp IDに属しているかを簡単に追跡できません。
を使用してください。 CI/CD Pipelinesでセキュアなシークレット管理を使用して、誰が認証情報を読み取ったり置き換えたりできるかを制御します。 アップロードとローテーションのアドビュートトレイルを維持してくださいが、プライベートキーまたは のパスワードをログに記録してください。 .p12 新しいバックエンドワークの場合、証明書認証がまだ適切かどうかを評価してください。 既存の統合では
が必要かもしれませんが、トークン認証は通常、プロバイダー接続から年間の証明書置き換えを排除します。 しかし、それは認証情報の管理を排除しません。 それが何を保護し、何をローテーションするかが変わります。 .p12New Token-Based Authenticationへの移行
AppleはAPNs認証を
プロバイダー用トークン toward、一般に p8ワークフロー。長期間のTLSのアイデンティティの証明書と秘密鍵の代わりに、サービスプロバイダーはApple Push Notificationサービス認証キーで認証トークンを署名します。
Apple Developerポータルで 証明書、識別子、& プロファイルの下でキーを作成し、 キー を開き、APNs認証キーを登録します。ダウンロードしたファイルを秘密鍵として扱い、高価な署名シークレットとして扱います。 .p8 変更を意図的に行う
生産トラフィックを置き換えるファイルをテストされていない環境に置き換えるのではなく、既存の証明書パスにトークン認証を組み込んで、サンドボックスと生産の動作を検証し、APNsのレスポンスを比較し、制御されたデプロイメント中にプロバイダー構成を変更します。
変更は証明書の更新とキーチェーンのエクスポートのステップを送信パスから削除しますが、チームは明確な所有権モデルを持つ必要があります。キーを作成、削除、展開する権限を持つ人を決定し、トークンを署名するバックエンドサービスへのアクセスを制限し、現在のキーが利用不能になる前に緊急の置き換えプロセスを確立する必要があります。
The migration removes the certificate renewal and Keychain export steps from the sending path, but your team still needs a clear ownership model. Decide who can create, revoke, and deploy keys. Limit access to the backend service that signs provider tokens, and make sure an emergency replacement process exists before the current key becomes unavailable.
For a Capacitor app, the client still needs correct notification registration and entitlements. The migration primarily changes APNsへのサーバー認証, not the device token registration code. Your backend must continue associating tokens with the correct application and environment.
開発者がノートパソコンのデスクにコーヒーカップと植物が近くにある状態でコードを書いている。
証明書が必要な場合を知っておく
いくつかの企業ツールや既存の統合は、証明書ベースの構成を公開しています。受信システムがサポートし、チームが完全なパスをテストするまで、p8マイグレーションを強制しないでください。トークン認証が適切な場合、レガシーキレデンシャルを保護しながら、新しい依存性を作成しないでください。 Ionic and Capacitor push notifications with FirebaseIonicとCapgoのプッシュ通知をFirebaseで
を確認してください。Firebaseはアプリケーション配信層を提供できますが、Appleの資格、特権、登録、APNsの応答は、意図的に構成する必要があります。
証明書の有効期限の更新と管理 APNs証明書を有効期限のあるプロダクション依存性として扱いましょう。Appleは、これらの証明書は作成から1年間有効であると言っています。 と更新しなければならないのは、有効期限前にデバイス間の通信を維持するためです。Appleは、更新しないと、iOS、iPadOS、MacデバイスのAPNsの再登録が必要になり、サービスが中断される可能性があることを警告しています。Appleの プッシュ通知証明書更新ドキュメント.
更新のパスは次のとおりです:
- 新しいCSRを生成する: 承認されたワークフローを通じてリクエストを作成し、関連するキー材料を保存する。
- 元のApple IDを使用する: 同じApple IDで既存の証明書を作成したときに使用したApple IDでサインインする。
- 有効期限切れの証明書を選択する: App ID、Subject DN、UID、有効期限の詳細を照合し、選択する。 更新.
- CSRをアップロードする: Apple Push Certificates Portalに新しいリクエストを提出する。
- ダウンロードして再インストール: 更新されたものを取得し、
.pemプライベートキーが利用可能な場所にインストールし、置き換えの.p12プロバイダーがそれを必要とする場合に使用します。 - デプロイしてテスト: サーバーキーを更新し、制御された通知を送信し、APNsの応答を検査します。
プロバイダー形式を比較します。
| 要件 | 証明書ワークフロー | トークン ワークフロー |
|---|---|---|
| プライマリーキー | 証明書とプライベートキー | .p8 認証キー |
| 更新の懸念 | 証明書の有効期限が切れるため、繰り返し置き換えが必要です。 | 年間の証明書置き換えなし |
| 展開作業 | インストール、ペアリング、エクスポート、アップロード | 署名キーを保存し、トークン生成を設定 |
| 主な障害リスク | 誤った証明書、プライベートキーが欠落している、有効期限切れ、または削除された認証キー | 認証キーが失われた、公開された、または削除された |
Appleの証明書エコシステムも、定期的な信頼チェーン作業が必要でした。Appleはサンドボックス用のAPNsサーバーセertificateの更新を2025年1月20日に発表しました。 2025年1月20日 と生産 2025年2月24日, SHA-2 Root USERTrust RSA 証明書認定機関 を含む Apple APNsサーバー証明書アナウンス を読んで、プラットフォームチェックリストに所有権を含める
共有更新カレンダー、名前の付いたオーナー、デプロイメントランブックを使用します。 Capgo証明書管理ドキュメント は、iOS配信資格情報を管理するチームがモバイルリリースプロセスと共に置くことができます。
トラブルシューティングと失われた資格情報の処理
失われた資格情報のトラブルシューティングは、期限切れの警告だけではありません。管理者が証明書を作成した人を失った、プライベートキーが古いMacにしか存在しない、または証明書が削除しようとしたときに却下された場合など、難しい出来事です。標準的な更新フローは、元のApple IDと正しい証明書のアイデンティティに依存するため、ファイル自体にアクセスすることと証明書の起源が同じくらい重要です。
失敗の分類を開始してください:
- 有効期限切れの証明書: 元のアカウントから置き換え証明書を生成し、対応する秘密鍵とともに再インストールし、プロバイダーを更新し、配信テストを実行してください。デバイスの通信がすでに中断されている場合、サーバー側の置き換えがすべてのデバイスに即座に復元されることを仮定するのではなく、Appleの復旧ガイドラインに従ってください。
- 取り消された証明書: 古い資格情報を復旧可能として扱わないでください。Appleは、取り消された証明書を使用するサーバーからTLS接続を拒否するため、有効な置き換え証明書を作成し、取り消されたシークレットをアクティブなデプロイメントから削除してください。どのシステムが取り消したか、他のシステムが同じ資格情報をコピーしたかを確認してください。
- 失われた:
.p12パスワード: パスワードが使用可能な証明書ファイルが存在しない場合、運用上利用できない可能性があります。承認されたバックアップを取得するか、生産性の秘密制御を弱めるのではなく、置き換え証明書を発行してください。 - 失われた秘密鍵: パブリック証明書を再ダウンロードしても秘密鍵を再作成することはできません。制御されたマシンで新しいCSRを作成し、置き換え資格情報を発行してください。
- 失われたApple IDアクセス: 組織がアカウントを復旧できるかどうかを確認し、AppleがAPNs証明書を作成した関連するポータルからサポートを指示することを確認してください。 展開プログラムのサポート.
復旧には、ファイル名だけでは不十分です。 Apple IDの所有者、App ID、証明書の識別、秘密鍵の場所、プロバイダーの構成、および置き換え手順を事前にインシデントが発生する前に記録してください。
運用上の安全ネットを構築する
証明書と .p8 キーを共有アクセス制御されたセキュアストレージに格納してください。ファイルとは別にパスワードを保存し、生産環境へのアクセスを制限し、更新に使用した精確なポータルアカウントをドキュメント化してください。CI/CDシステムは、デプロイ時にシークレットをインジェクトし、認証失敗を検出するヘルスチェックを実行し、ユーザーが欠落しているアラートを報告する前に、認証に失敗したことを検出する必要があります。 .p12 古い資格情報を保持して、制御された置き換えを実行できるようにしますが、無制限に古いシークレットを有効にしないでください。テスト環境と生産環境で同じバックエンドパスを使用し、プロバイダーの環境、バンドルID、デバイストークンストアを含めて、置き換えをテストしてください。
既にインシデントが発生している場合、APNsのレスポンスボディとタイムスタンプを保存し、最初の拒否された要求を特定し、デプロイシークレットの前後でインシデントが発生したことを比較してください。無効な資格情報に対しては、無制限にリトライしないでください。まず、正しい資格情報または認証問題を修正し、知られているテストデバイスに小さな検証通知を送信してください。
__CAPGO_KEEP_0__は、__CAPGO_KEEP_1__通知ワークフローの一部としてiOSプッシュ資格情報を格納および構成できます。ただし、Appleアカウントへのアクセス、シークレットの保管、および更新決定は、チームが責任を持って管理する必要があります。__CAPGO_KEEP_0__を参照してください。
Capgo can store and configure iOS push credentials as part of a Capacitor notification workflow, while your team retains responsibility for Apple account access, secret custody, and renewal decisions. Visit Capgo APNsの資格情報ライフサイクルとリリースプロセスと合わせて、Capgoのモバイル配信ツールを確認する方法について説明します。
