Apple Push Notification serviceの証明書は1年間有効で、Apple Developer Portalで毎年更新しなければ、デバイス間の通信を中断することなく、通知を送信することができます。 Capacitor アプリの責任者であれば、有効期限切れまたは取り消された資格情報は、通知が停止することさえあります。アプリ自体は正常に動作しているように見えます。
失敗は最悪の時期に表面化することがよくあります。リリースが行われ、キャンペーンが計画され、通知の配信が突然沈黙することがあります。アプリケーションサーバーはまだジョブを受け付けるかもしれませんが、APNsはTLS接続を拒否し、メッセージがデバイスに到達する前に、実際の解決策は単に別の証明書を作成するだけではありません。システムが使用しているAPNs資格情報を理解する必要があります、プライベートキーを保存する必要があります、更新を計画する必要があります、適切なワークロードをトークン認証に移行する必要があります。
目次
- Push通知が停止する理由
- APNs証明書を作成してダウンロードする
- 証明書をプライベートキーよりエクスポートする
- Apple Push Notification Service証明書の移行
- 証明書のライフサイクルを更新および管理する
- 失われた資格情報を処理およびトラブルシューティングする
プッシュ通知が機能しない理由
APNsは、プロバイダーサーバーとユーザーのAppleデバイスの間にある。サーバーはAppleに認証し、通知を提出し、APNsに依存して登録済みのアプリケーションとデバイスに通知をルーティングする。資格情報が期限切れ、削除された、不正確なアイデンティティに関連付けられた、または不正にインストールされた場合、リクエストは配信が始まる前に失敗する可能性がある。
Appleは、APNsが削除された証明書のリストを保持し、サーバーがそのリストに含まれる証明書を使用するTLS接続を拒否することを述べている。したがって、証明書の清潔さは配信の要件であり、管理上の好みではなくなった。サーバーは、Appleがプロバイダーコネクションを拒否するまで、通知ジョブをローカルに処理し続ける可能性がある。
アプリプッシュとMDMプッシュを分離する
初期診断の質問は単純です: どのサービスを操作しようとしていますか?
| 資格情報のパス | 機能 | 通常の所有者 |
|---|---|---|
| App Push | エンドユーザー機器に警告やその他のアプリケーション通知を送信します | モバイルまたはバックエンドエンジニアリング |
| MDMプッシュ | Appleデバイスを管理するプラットフォームが管理対象のAppleデバイスと連絡を取り続けるようにします | IT、エンドポイント、またはエンタープライズモビリティ管理 |
これらの資格情報は入れ替えられません。MDMプラットフォームがMDM Push資格情報の期限切れの場合、エンロールされたデバイスと連絡を取り続けることができなくなります。一方、App Push資格情報が無効の場合、エンドユーザーに通知を送信することができなくなります。両方を「Apple Push証明書」として扱うことは、トラブルシューティングを誤った方向に進めることになります。
CapacitorとIonicチームの場合、ユーザーフェイス用のアラートのパスは一般的に App Push. アプリはPush Notificationsの機能、正しい署名、デバイスの登録、APNs環境に適切なものを送信するバックエンドが必要です。チームがオーバー・ザ・エアのWebアセットを配信する場合、リリースフローをPush認証から分離してください。 __CAPGO_KEEP_0__の通知プラグインドキュメント Capacitor 通知プラグインドキュメント 開始はUIではなく拒否にしましょう
UIから始めるのではなく、却下から始めましょう。
リリース後に失敗が発生した場合、署名と特権を新しいビルドと前のビルドと比較してください。アプリの変更なしで失敗が発生した場合、証明書の有効期限、失効、トラストストアの変更、デプロイシークレットを最初に検査してください。より広い実装パスについては、このガイドを参照してください。
Expoのプッシュ通知設定 APNs証明書の作成とダウンロード.
APNs 証明書の作成とダウンロード
証明書署名要求 __CAPGO_KEEP_0__、またはCSR、そしてAppleが選択されたApp IDのために署名します。 CSRはサーバークレデンシャルではありません。発行された証明書をローカルに作成されたプライベートキーと結び付けます。
App IDの準備
Apple Developer ポータルにサインインし、 証明書、識別子、& プロファイル. Select 識別子を選択し、 アプリのバンドルIDを選択し、その設定を開きます。発行する前に Push Notifications
context
Macでキーを保持する機器を開きます。 が有効になっていることを確認します。 とCSRを作成するか、組織の承認された証明書ツールを使用します。要求ファイルと秘密鍵を同じコントロールされた所有権下に保管してください。別の管理者がCSRを作成した場合、その管理者は後で使用可能なサーバー バンドル用の秘密鍵を保持する可能性があります。
署名された証明書を発行する
在 証明書、Apple Push Notificationサービス証明書オプションを選択します。App IDを選択し、CSRをアップロードし、リクエストを送信します。Appleが発行した証明書をダウンロードします。
Mac上でダウンロードしたファイルを二度クリックしてください。 それがプライベートキーを所有するMacでなければなりません。 アプリケーションID、環境、所有者、有効期限の詳細を記録する命名規則を使用してください。元の証明書、CSR所有権情報、ポータルアカウントの詳細をチームの資格情報システムに保存してください。開発者のダウンロードフォルダや個人のノートパソコンは、運用上のバックアップではありません。証明書は配信の1つの部分のみをサポートします。アプリはリモート通知の登録を行い、サーバーは結果のデバイストークンを保持し、プロバイダーは一致するトピックと環境を含めて送信する必要があります。依存関係を同じランブックに保管してください。クライアント側の設定については、
https://capgo.io/docs/guides/notifications/apple-push-notifications#apple-push-notification-service-certificates
https://capgo.io/docs/guides/notifications/apple-push-notifications#apple-push-notification-service-certificates Capacitor の通知統合ガイド. この証明書を管理された資格情報として扱い、ダウンロードのみのものとして扱うのではなく、後でエクスポート、トークン移行、更新、回復がキー管理者の情報に依存するためです。
証明書をプライベートキーにエクスポートする
ダウンロードしたApple証明書は、Node.jsサービスまたは管理されたプッシュプロバイダーに自動的に準備されていません。サーバーには証明書と対応するプライベートキーが必要であり、これらは一般にパッケージ化された PKCS#12 .p12 ファイル.
Open キーキャッシュアクセス Macで証明書をインストールした場所でKeychain Accessを開きます。APNs証明書を検索し、展開または検査し、同期情報と有効期限情報が一致するプライベートキーを探します。証明書とプライベートキーを選択し、エクスポートアクションを使用して保存ファイルを作成します。 .p12 配布前にバンドルを検証する
バンドルを展開前に検証する
__CAPGO_KEEP_0__
実践ルール: A
.p12ファイルとその対応する秘密鍵が揃っていない場合、完全なプロバイダークレデンシャルではありません。
生産環境での使用前に、制御された環境でバンドルをテストしてください。バックエンドがファイルを読み込むことができ、APNs接続を確立し、Appleがリクエストを拒否した場合に構造化されたエラーを返すことを確認してください。プロバイダであるCapgoがiOSプッシュ認証情報を要求した場合、指定されたシークレット構成を通じてファイルとパスワードをアップロードし、Capgoのアプリケーションに埋め込まないようにしてください。 .p12 アプリケーションに値を埋め込むのではなく、指定されたシークレット設定を通じてアプリケーションcodeのパスワードを設定します。
CI/CD Pipelinesで
Use 新しいバックエンドワークの場合、証明書認証がまだ適切かどうかを評価してください。既存の統合では が必要かもしれませんが、トークン認証はプロバイダーコネクションから毎年証明書の置き換えを排除します。ただし、クレデンシャル管理は排除されません。保護対象とローテーション対象が変わります。 .p12 Use
secure secret management in CI/CD pipelines .p12to control who can read or replace the credential.
トークンベースの認証に移行する
AppleはAPNs認証をトークンベースの認証に移行しました サービスポリシートークンp8ワークフロー パスワークフローApple Developer Portalで
Certificates, Identifiers & Profiles の下でキーを作成し、Keys Keys APNs認証キーを登録します。APNs認証キーをダウンロードしてください。 .p8 provider tokens
マイグレーションを意図的に行う
生産トラフィックを切り替えるのではなく、未テストの環境でファイルを置き換えるのではなく、既存の証明書パスにトークン認証を組み込み、サンドボックスと生産の動作を検証し、APNsの応答を比較してから、制御されたデプロイメント中にプロバイダーの構成変更を行う。
マイグレーションは、送信パスから証明書の更新とキーチェーンのエクスポートのステップを削除しますが、チームには明確な所有権モデルが必要です。キーを作成、削除、展開することができる人を決定し、プロバイダータークンを署名するバックエンドサービスへのアクセスを制限し、現在のキーが利用不能になる前に緊急の置き換えプロセスを確立する必要があります。
アプリケーションCapacitorの場合、クライアントは正しい通知登録と特権が必要です。マイグレーションは主に サーバーからAPNsへの認証を変更し、デバイストークンの登録codeは変更されません。バックエンドは正しいアプリケーションと環境に関連付けられたトークンを続けて関連付けなければなりません。
証明書が必要なときを知る
いくつかのエンタープライズツールや既存の統合はまだ証明書ベースの構成を公開しています。p8マイグレーションを強制するのではなく、受信システムがそれをサポートし、チームが完全なパスをテストするまで待ってください。トークン認証が適している場合、トークン認証を使用してくださいが、既存の資格情報を保護する必要があります。
周辺のアプリケーションフローの理解が必要な場合は、 イオニクとCapacitorのプッシュ通知. Firebaseはアプリケーションの配信層を提供できますが、Appleの資格情報、特権、登録、APNsの応答は、意図的な構成が必要です。
証明書の有効期限の更新と管理
APNs証明書を有効期限の切れたプロダクション依存性として扱いましょう。Appleによると、これらの証明書は 1年間の有効期限があります 有効期限前に更新しないと、デバイス間の通信を維持するために、ユーザーがiOS、iPadOS、MacデバイスをAPNsに再登録する必要があり、サービスが中断される可能性があります。Appleは、更新しないと、APNsの再登録が必要になる可能性があることを警告しています。Appleの プッシュ通知証明書の更新に関するドキュメント.
更新のパスは次のとおりです:
- 新しいCSRを生成する: 承認されたワークフローを通じてリクエストを作成し、関連するキー材料を保存する。
- 元の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年2月24日に生産用に実施することを発表しました。 2025年1月20日 2025年2月24日 、信頼ストアに含める必要があるSHA-2 Root USERTrust RSA 証明書認定機関の証明書を含める必要があります。Apple APNsサーバーセertificateの発表を読んで、信頼ストアの所有権をプラットフォームチェックリストに追加してください。Apple APNsサーバーセertificateの発表 信頼ストアの所有権 プラットフォームチェックリスト SHA-2 Root USERTrust RSA 証明書認定機関 Apple APNsサーバーセertificateの発表
Apple Push Notification Serviceの証明書を使用するには、共有更新カレンダー、名前の付いたオーナー、デプロイメントの実行書を使用してください。 Capgo証明書管理ドキュメント iOSの配信クレデンシャルを管理するチームがモバイルリリースプロセスと共に使用することができます。
トラブルシューティングと失われたクレデンシャルを取り扱う
失われたクレデンシャルは、期限切れの警告だけではありません。管理者が証明書を作成したときに退職した、プライベートキーが古いMac上にしか存在しない、またはクレデンシャルが削除しようとしたときに削除された証明書など、難しい事例もあります。Apple IDと正しい証明書のIDが必要なため、ファイル自体よりもアクセスと証明が重要です。
失敗を分類してください:
- 期限切れの証明書: 元のアカウントで置き換えを生成し、対応するプライベートキーと共に再インストールし、プロバイダーを更新し、配信テストを実行してください。デバイスの通信がすでに中断されている場合は、サーバー側の置き換えがデバイス全てに即座に復元されるのではなく、Appleの復元ガイドに従ってください。
- 削除された証明書: 古いクレデンシャルを復元できるものと考えるのをやめましょう。Appleは削除された証明書を使用したサーバーからTLS接続を拒否するため、有効な置き換えを作成し、削除されたシークレットをアクティブなデプロイメントから削除し、削除したのは誰かを確認し、他のシステムが同じクレデンシャルをコピーしたかどうかを確認してください。
- 失われた
.p12パスワード: 有効なパスワードが付与されていない証明書ファイルは、運用上利用できない可能性があります。承認されたバックアップを取得したり、生産性の低下を招くプロダクションシークレットの制御を弱めるのではなく、代替証明書を発行する必要があります。 - ロスト プライベート キー: パブリック証明書を再ダウンロードしてもプライベートキーは再作成されません。管理されたマシンで新しいCSRを作成し、代替の資格証明書を発行してください。
- Apple ID のアクセス権が失われた Apple Push Notification Serviceの証明書のサポートは、Appleが管理するPortalで作成されたAPNs証明書に関連するPortalに指示します。 Deploymentsサポート.
復元には、ファイル名だけではありません。 Apple ID の所有者、App ID、証明書の特性、秘密鍵の場所、プロバイダーの設定、および置き換え手順を事前にインシデントが発生する前に記録しておきましょう。
安全対策の基盤を構築
Put certificates and .p8 キーの共有、アクセス制御されたセキュアなストレージに格納する。 .p12 パスワードはファイルから分離し、プロダクションへのアクセスを制限し、更新の際に使用したポータルアカウントを正確に記録する。CI/CDシステムは、デプロイ時にはシークレットをインジェクトし、認証エラーを検出するヘルスチェックを実行し、ユーザーが欠落しているアラートを報告する前に実行する必要があります。
古い資格情報を置き換えるときは、プラットフォームが許可する限り資格情報を保持しておくが、古いシークレットを無制限に有効にしないようにする。同じバックエンドパスでテストするには、プロバイダーの環境、バンドル識別子、デバイストークンストアを含めて、生産環境と同じ設定を使用する。
既に発生している障害の場合、APNsのレスポンスボディとタイムスタンプを保存し、最初の拒否された要求を特定し、インシデントの前後でデプロイシークレットを比較する。無効な資格情報に対しては、無制限にリトライしない。まず、アイデンティティまたは認証問題を修正し、知られているテストデバイスに小さな検証通知を送信する。
CapgoはiOSプッシュ資格情報を含むCapacitor通知フローの設定と管理が可能ですが、チームはAppleアカウントへのアクセス、シークレットの保管、更新の決定を保証する責任を負います。Capgoを参照してください。 Capgo このページを参照してください。
