■ 概要

Apple Developer Program（以下、ADP）における、iOSアプリの証明書関連の仕組みは、
出てくる登場人物や用語も多く複雑で理解するのにも一苦労です。

当記事はそれらの概要や相関をまとめて、少しでも理解を深めることが目的です。

■ とりあえず覚えたい証明書関連

大枠として覚えておきたいのは、こちらの2つになります。

① 証明書【 Development / Distribution Certificate 】
② プロファイル【 Provisioning Profile 】

■ ① 証明書【 Certificate 】

1. なぜ必要？

信用に値するアプリであることを担保するための仕組みとして必要。
開発中においてもXcodeで実機端末（iPhone,iPad）にアプリをビルドする際には必要。

↓

「信用に値する」 というのは具体的には、

・ADPに登録されている正規の開発者により発行された証明書を使用してアプリが作成されたこと。
・またアプリが第三者によって改竄されていないこと。

これらが担保されているものです。

2. 証明書の種類　

【Development Certificate（開発用証明書）】

Mac(PC)から実機端末（iPhone,iPad）にアプリをビルドする動作確認用
ユーザーのアカウント単位で作成が可能
有効期限は発行から1年

【Distribution Certificate（配布用証明書）】

Ad Hoc配布やApp Storeでのリリース配布用
各種別3つまでしか作成できない
有効期限は発行から1年

３.　証明書作成の流れ

証明書の作成の具体的な手順は公式にも記載があるし、調べれば分かりやすい記事が
いくつも出てくるので、こちらでは「大まかな流れ」のみを説明。

❶ CSRの作成

・まずCSR（Certificate Signing Request）を作成します。
文字通り、証明書発行を要求するためのファイルを作成するわけです。
・このCSRの作成時に秘密鍵・公開鍵のペア（RSA公開鍵暗号方式）が生成される。
・そしてCSRには、秘密鍵で暗号化した「開発者署名」と、「公開鍵」が含まれます。

RSA公開鍵暗号方式についてはこちらの「デジタル署名の仕組み」の記事が
分かりやすいです。

❷ Certificate（証明書）の発行

・Apple Developer上で作成したCSRファイルを読み込む。
・開発者署名が公開鍵で復号可能であることが検証されると、
Apple側の署名が付与されてCertificate（証明書）が発行される。
・発行された証明書をダウンロードして、キーチェーンアクセスに取り込んでおく。

❸ 「.p12」ファイルを書き出す

・企業などで複数の開発者のPC（Mac）でビルドを行う場合には、Certificateと秘密鍵を
合わせた「.p12」ファイルを書き出し、それぞれのPC端末に取り込む必要がある。

■ ② プロファイル【 Provisioning Profile 】

1. なぜ必要？

・使用する証明書の情報
・App ID（※後述要はアプリの識別子）の情報
・アプリを実行できるUDID（※後述要はデバイス識別子）の情報

などなど、アプリケーションに関する情報が一纏めになっているファイル。

↓

つまりADPに登録されている既知のデベロッパーがそのアプリを開発、
アップロード、配信していることを保証するものです。

こちらも開発中においてXcodeで実機端末（iPhone,iPad）にアプリを
ビルドする際にも必要。

2. プロファイルの種類　

【Development (iOS App Development)】

Mac(PC)から実機端末（iPhone,iPad）にアプリをビルドする動作確認用
App IDと証明書(Development)を選択する
利用可能とするUDID（デバイス識別子）を選択

【Distribution （Ad Hoc）】

私設サーバーなどから、特定の実機端末へのアプリ配信用
App IDと証明書(Distribution)を選択する
利用可能とするUDID（デバイス識別子）を選択

【Distribution （App Store）】

製品リリースに使用
App IDと証明書(Distribution)を選択する
UDID（デバイス）は選択不要

３.　プロファイル作成の流れ

プロファイルの作成の具体的な手順についても公式にも記載があります。こちらも調べれば
分かりやすい記事がいくつも出てくるので、「大まかな流れ」のみを説明。

今回は↑2つ目の「Ad Hoc」でのアプリ配布を例に説明します。

❶ App IDを選択

→ App IDはApple Developer上で、事前に登録する必要がある。

App IDとは

・アプリを特定する識別子 (Team ID + Bundle ID)
・一度登録したBundle IDは変更できず、仮に削除しても同じBundle IDは再作成不可能。
・アプリで有効にするサービス機能を選択可能。（Push通知や位置情報の取得など）
・有効期限はなし

❷ 配布用証明書を選択

→ 事前に作成した、配布用証明書を選択する。

❸ UDID（デバイス識別子）を選択

→ UDIDについても、事前にApple Developerに登録する必要がある。

UDIDとは

・実機端末を特定する識別子。
・PC(Mac)からの実機確認や、Ad Hoc配布での実機確認に使用。
・100台が登録上限（iOS, iPadなど、デバイスタイプ毎に）
・1度登録すると、年に1度の契約更新時しか登録解除できない（無効化は適宜実行可能）

■ ③ まとめ

これまで説明した流れのまとめとして、こちらの記事の図がわかりやすかったです。

そして証明書やProfileを使って行われる「コード署名」で
何が行われているかを説明すると、

1. 公開鍵と秘密鍵のペアを用意（図①~④）

アプリの開発者は、公開鍵と秘密鍵のペアを作成。

・公開鍵は作成したデジタル証明書に含まれている。
・秘密鍵は「.p12」ファイルに含まれており、開発者のPCに保持され、署名に使用される。

2. アプリをアーカイブ（図⑩）

アプリをアーカイブする際、あらかじめ決められた手順でアプリからハッシュ値が
計算され、これを秘密鍵で暗号化してアプリに含めます。
このプロセスは「署名」と呼ばれる。

公開鍵はプロファイル作成時（図⑦）に設定した証明書の中に含まれている。この証明書
情報を保持したプロファイルはアプリと共にパッケージ化され（.ipaファイル）、
インストール先の端末に渡される。

3. アプリをインストール

アプリをインストールした端末は、同じ手順でアプリからハッシュ値を計算します。
同時に、アーカイブ時に計算されて暗号化されたハッシュ値を証明書に含まれている
公開鍵で復号する。そしてこれら２つの方法で得られたハッシュ値が一致するかどうかが
検証されます。

↓

①「ADPに登録されている正規の開発者により発行された」ことが担保される。

まず暗号化されたハッシュ値を公開鍵で復号できたということは、それを暗号化したのは開発者の秘密鍵であり、秘密鍵を持っているのは開発者本人しかいないため「ADPに登録されている正規の開発者により発行された」ことが担保されます。

②「アプリが第三者によって改竄されていないこと」が担保される。

さらにハッシュ値が一致したことで「アプリが第三者によって改竄されていないこと」が担保されます。もし第三者がアプリの中身の改竄を行った場合、iOSで計算されるハッシュ値が変更され一致しなくなります。仮にハッシュ値自体を書き換えたとしても、第三者は開発者の秘密鍵を持っていないため、そもそもそのハッシュ値の暗号化ができず、改変したハッシュ値をばれないように差し替えることができません。またこれも仮に、適当な秘密鍵で暗号化することは可能ですが、そうなると開発者の公開鍵では復号できないため、検証をパスできません。

■ 最後に（感想）

iOSの証明書関連は、書こうと思うといくらでも書く内容があるぐらい
要素も多いし複雑ですが、この記事を読んでざっくり大枠だけでも
理解が深まれば幸いです。最後までご覧いただき、ありがとうございました。