提案された証明書/サーバー/SSL の質問と回答に色を追加するだけです。
Codesign 設定に基づいて選択された本番/サンドボックス APNS
徹底するために、APNS 環境の簡単なレビューから始めましょう。
- iOS 開発証明書でコード署名されたアプリケーションは、サンドボックスAPNS 環境に接続し、プッシュ通知が配信されるのを待ちます
- iOS ディストリビューション証明書 (AppStore またはディストリビューション > アドホック)でコード署名されたアプリケーションは、本番APNS 環境に接続し、プッシュ通知が配信されるのを待ちます。
- この設定は、ビルド プロセス中に Xcode によって自動的に決定され、CodeSign ステップで使用される証明書の種類を選択することによってのみ構成可能です。
質問 1: 開発証明書の署名付きアプリのプッシュ通知をテストするには、サーバーに開発 SSL 証明書をインストールする必要がありますか?
はい、アプリがコード署名されると、その APNS 設定は前のセクションのルールを使用してバイナリに封印されます。デバイスが生成する APNS トークンがサンドボックス APNS 環境に対応し、サーバーがそのプッシュ通知のリクエストを代わりに gateway.sandbox.push.apple.com にルーティングする必要があることを認識するのは、開発者のサーバー コード次第です。
一部の開発者は、これらの区別を行うことができる単一のサーバーをセットアップすることを選択しますが、他の開発者は、1 つのセットを本番環境に送信し、別のセットをサンドボックスに送信するように、サーバーのサイド バイ サイド インスタンスをセットアップすることを選択します。
いずれにせよ、決定は個々の開発者と、そのサーバー側のコードで何ができるか、および 2 番目のサーバーをセットアップすることの相対的な複雑さにかかっています。いずれにせよ、今後の機能をテストしているときに誤って本番プッシュ通知を無効にし、後で再度有効にするのを忘れた場合、ユーザーは動揺する可能性があるため、本番コードをいじる際には十分に注意してください!
質問 2: 開発用 SSL 証明書と本番用 SSL 証明書は競合しますか?
生のSSLの観点からは競合しません。サーバー以外のマシンでこれらの証明書をダウンロードして開いたり調べたりすると、証明書の内容が実際には異なることがわかります。それらを同じサーバー環境にインポートすることは (これも SSL の観点から) まったく問題ありません。それらが異なることを確認するには、証明書を要求するときに、2 つの異なる certificateSigningRequests を作成することを絶対に確認してください。そうすれば、本質的に異なるデータになります。
開発者のサーバー側のプッシュ コードの観点から - それは依存します。サーバー側のコード機能に関する質問 1 の会話を参照してください。サーバーコードがこれを念頭に置いて設計されている場合、理論的には答えは「いいえ、競合しません」ですが、それは個々の開発者が独自のサーバー側コード機能について行う必要がある決定です。