AIR ファイルへの電子署名

認定されている証明機関(CA)が発行した証明書を使用して AIR インストールファイルに電子署名すると、インストールしているアプリケーションが誤ってまたは悪意をもって変更されていないことをユーザーに確実に保証することができ、署名したユーザーは署名者(発行者)と見なされます。AIR のインストール中に発行者名が表示されるのは、信頼できる証明書、またはインストールされているコンピューターで信頼されている証明書に チェーン化 されている証明書を使用して AIR アプリケーションに署名している場合です。

信頼できる証明書によって署名されたアプリケーションのインストールの確認ダイアログ

自己署名証明書(または信頼できる証明書にチェーン化されていない証明書)でアプリケーションに署名する場合、ユーザーは、より大きなセキュリティリスクがアプリケーションのインストールに伴うことを認識しておく必要があります。インストールダイアログにはこの追加のリスクが示されます。

フルサイズのグラフィックを表示
自己署名証明書によって署名されたアプリケーションのインストールの確認ダイアログ
重要: 悪意のあるエンティティは、なんらかの方法で署名されているキーストアファイルを取得するか、秘密キーを見つけ出し、署名者の ID で AIR ファイルを偽造する可能性があります。

コード署名証明書

コード署名証明書の使用に関連するセキュリティの保証、制限、および法的義務の概要については、証明機関運用規定(CPS)および発行側の証明機関が発行する利用規約に記載されています。AIR コードサイニング証明書を現在発行している証明機関の規約について詳しくは、次のサイトを参照してください。

ChosenSecurity (http://www.chosensecurity.com/products/tc_publisher_id_adobe_air.htm)

ChosenSecurity CPS (http://www.chosensecurity.com/resource_center/repository.htm)

GlobalSign (http://www.globalsign.com/code-signing/index.html)

GlobalSign CPS (http://www.globalsign.com/repository/index.htm)

Thawte CPS (http://www.thawte.com/cps/index.html)

日本ベリサイン CPS(VeriSign Japan CPS) (http://www.verisign.co.jp/repository/CPS/)

クライアント ID 利用規約(Digital ID 利用規約) (https://www.verisign.co.jp/repository/SUBAGR.html)

AIR コード署名について

AIR ファイルに署名が行われると、電子署名がインストールファイルに含まれます。署名には、署名後に AIR ファイルが変更されていないことを検証するために使用されるパッケージのダイジェストと、発行者 ID を検証するために使用する署名証明書に関する情報が含まれます。

AIR では、証明書が信頼できるかどうかを確認するために、オペレーティングシステムの証明書ストアを通じてサポートされる公開キーインフラストラクチャ(PKI)を使用します。AIR アプリケーションがインストールされているコンピューターでは、発行側の情報を検証するために、AIR アプリケーションの署名に使用されている証明書そのものを信頼するか、信頼できる証明機関の証明書にリンクしている証明書のチェーンを信頼する必要があります。

AIR ファイルが、信頼できるルート証明書(およびこれには通常すべての自己署名入り証明書が含まれる)のいずれにもチェーン化されていない証明書で署名されている場合、発行者側の情報は検証できません。AIR は、AIR パッケージが署名後に変更されていないか確認できますが、ファイルの実際の作成者および署名者を知ることはできません。

注意: ユーザーは自己署名入り証明書を信頼することができ、その証明書で署名された AIR アプリケーションには、発行者名として証明書の共通名フィールドの値が表示されます。AIR では、ユーザーが信頼済みの証明書を指定することはできません。証明書(秘密キーを含まない)はユーザーに個別に提供する必要があります。ユーザーはオペレーティングシステムが提供するメカニズムのいずれかを使用するか、適切なツールを使用してシステムの証明書ストア内の適切な場所に証明書を読み込む必要があります。

AIR 発行者 ID について

重要: AIR 1.5.3 で発行者 ID は非推奨となり、コードサイニング証明書に基づいて算出されなくなりました。新しいアプリケーションに発行者 ID は不要なので、使用しないでください。既存のアプリケーションを更新する場合は、アプリケーション記述ファイルに元の発行者 ID を指定する必要があります。

AIR 1.5.3 よりも前のバージョンでは、AIR ファイルのインストール時に、AIR アプリケーションのインストーラーによって発行者 ID が生成されました。これは、AIR ファイルの署名に使用される証明書に固有の ID です。複数の AIR アプリケーションに対して同じ証明書を再利用する場合は、それらのアプリケーションの発行者 ID は同じになります。別の証明書や場合によっては元の証明書の更新されたインスタンスを使用してアプリケーションのアップデートに署名すると、発行者 ID が変更されます。

AIR 1.5.3 以降では、AIR によって発行者 ID が割り当てられることはありません。AIR 1.5.3 を使用して発行するアプリケーションでは、アプリケーション記述子に発行者 ID を指定できます。AIR 1.5.3 よりも前のバージョンで発行されているアプリケーションに対してアップデートを発行するときにのみ、発行者 ID を指定します。アプリケーション記述子に元の ID を指定しないと、新しい AIR パッケージは既存のアプリケーションに対するアップデートとして扱われません。

元の発行者 ID を確認するには、META-INF/AIR サブディレクトリにある publisherid ファイルを探します。このディレクトリには、元のアプリケーションがインストールされています。このファイル内のストリングが 発行者 ID です。発行者 ID を手動で指定するには、アプリケーション記述ファイル内で、アプリケーション記述子の名前空間宣言に AIR 1.5.3(またはそれ以降の)ランタイムが指定されている必要があります。

発行者 ID が指定されている場合は、次の目的で使用します。

  • 暗号化されたローカルストアの暗号化キーの一部として

  • アプリケーション記憶域ディレクトリのパスの一部として

  • ローカル接続の接続ストリングの一部として

  • AIR ブラウザー API でアプリケーションを呼び出すときに使用する識別ストリングの一部として

  • OSID(カスタムインストール / アンインストールプログラムの作成時に使用)の一部として

発行者 ID が変更されると、ID に依存している AIR の機能の動作も変わります。例えば、既存の暗号化されたローカルストアにあるデータにはアクセスできなくなります。また、Flash または AIR インスタンスでアプリケーションへのローカル接続を確立するには、接続ストリングに新しい ID を使用する必要があります。インストール済みアプリケーションの発行者 ID は、AIR 1.5.3 以降では変更できません。AIR パッケージの発行時に別の発行者 ID を使用すると、インストーラーは新しいパッケージをアップデートではなく別のアプリケーションとして扱います。

証明書の形式について

AIR 署名ツールは、Java Cryptography Architecture(JCA)を通じてアクセスできるすべてのキーストアを受け入れます。これには、PKCS12 形式のファイル(通常 .pfx または .p12 ファイル拡張子が付いている)などのファイルベースのキーストア、Java .keystore ファイル、PKCS11 ハードウェアキーストア、およびシステムキーストアが含まれます。ADT がアクセスできるキーストア形式は、ADT の実行に使用される Java ランタイムのバージョンと設定によって異なります。PKCS11 ハードウェアトークンなど一部の種類のキーストアにアクセスするには、追加のソフトウェアドライバーや JCA プラグインのインストールと設定が必要になる場合があります。

AIR ファイルに署名する際は、既にあるコードサイニング証明書をほとんどの場合使用できます。また、AIR アプリケーションの署名用であることを明示して発行された新しい証明書を取得することもできます。例えば、VeriSign、Thawte、GlobalSign または ChosenSecurity の次の種類の証明書はどれでも使用できます。

  • ChosenSecurity

    • Adobe AIR 用の TC Publisher ID

  • GlobalSign

    • ObjectSign Code Signing Certificate

  • Thawte

    • AIR Developer Certificate

    • Apple Developer Certificate

    • JavaSoft Developer Certificate

    • Microsoft Authenticode Certificate

  • VeriSign

    • Adobe AIR Digital ID

    • Microsoft Authenticode Digital ID

    • Sun Java Signing Digital ID

注意: 証明書は、コード署名用に作成されたものである必要があります。SSL やその他の種類の証明書を使用して AIR ファイルに署名することはできません。

タイムスタンプ

AIR ファイルに署名するときは、パッケージングツールで、タイムスタンプ局のサーバーを照会して、単独で検証可能な署名の日時を取得します。取得したタイムスタンプは AIR ファイルに埋め込まれます。署名した証明書が署名時に有効である限り、AIR ファイルは証明書の期限が切れた後もインストールできます。一方、タイムスタンプを取得していない場合は、証明書の期限が切れたり証明書が取り消されたりすると、AIR ファイルはインストールできなくなります。

デフォルトでは、AIR パッケージングツールでタイムスタンプを取得します。ただし、タイムスタンプサービスが使用できないときにアプリケーションをパッケージ化できるようにするには、タイムスタンプ機能をオフにします。公開配布されているすべての AIR ファイルにはタイムスタンプを含めることをお勧めします。

AIR パッケージングツールで使用されるデフォルトのタイムスタンプ局は、Geotrust です。

証明書の取得

証明書を取得するには、通常は証明機関の Web サイトにアクセスし、その会社の取得プロセスに従います。AIR ツールに必要なキーストアファイルを生成するツールは、購入した証明書の種類、受信側コンピューターでの証明書の格納方法、および場合によっては証明書の取得に使用するブラウザーによって異なります。例えば、Adobe Developer Certificate を Thawte から取得して書き出すには、Mozilla Firefox を使用する必要があります。これにより、Firefox ユーザーインターフェイスから証明書を .p12 または .pfx ファイルとして直接書き出せます。

注意: Java バージョン 1.5 以上では、PKCS12 証明書ファイルを保護するパスワードに high-ASCII(拡張 ASCII)文字を使用できません。AIR 開発ツールでは、署名された AIR パッケージの作成に Java を使用します。証明書を .p12 または .pfx ファイルとして書き出す場合、パスワードには正規の ASCII 文字のみを使用してください。

AIR インストールファイルのパッケージ化に使用する AIR 開発ツール(ADT)を使用して自己署名入り証明書を生成できます。一部のサードパーティツールも使用できます。

自己署名入り証明書の生成手順、および AIR ファイルの署名手順については、 AIR 開発ツール(ADT) を参照してください。また、Flash Builder、Dreamweaver、および AIR update for Flash を使用して AIR ファイルを書き出し、署名することもできます。

次の例で、Thawte 証明機関から AIR Developer Certificate を取得し、それを ADT で使用できるように準備する方法を説明します。

例:Thawte からの AIR Developer Certificate の取得

注意: コードサイニング証明書を取得して準備する方法は他にも多数あり、この例は単にその 1 つに過ぎません。ポリシーや手続きは証明機関ごとに異なります。

AIR Developer Certificate を購入するには、Thawte Web サイトへのアクセスに Mozilla Firefox ブラウザーを使用する必要があります。証明書の秘密キーは、ブラウザーのキーストアに格納されます。Firefox キーストアがマスタパスワードで保護されていること、およびコンピューターそのものが物理的に安全であることを確認してください(取得プロセスが完了すると、ブラウザーのキーストアから証明書と秘密キーを書き出して削除できます)。

証明書登録プロセス中に、秘密キーと公開キーのぺアが生成されます。秘密キーは自動的に Firefox キーストア内に格納されます。Thawte の Web サイトに証明書を要求する場合も証明書を取得する場合にも同じコンピューターとブラウザーを使用する必要があります。

  1. Thawte の Web サイトにアクセスし、 コードサイニング証明書の製品ページ を参照してください。

  2. コードサイニング証明書の一覧から、「Adobe AIR Developer Certificate」を選択します。

  3. 3 つのステップの登録プロセスを完了します。組織および連絡先の情報を指定する必要があります。これで、Thawte は、ID 検証プロセスを実行し、追加の情報を要求できます。検証の完了後、Thawte から証明書の取得手順に関する電子メールが送られてきます。

    注意: 必要なドキュメントの種類について詳しくは、 https://www.thawte.com/ssl-digital-certificates/free-guides-whitepapers/pdf/enroll_codesign_eng.pdf を参照してください。
  4. 発行された証明書を Thawte サイトから取得します。証明書は、自動的に Firefox キーストアに保存されます。

  5. 次の手順を実行して、秘密キーと証明書を含むキーストアファイルを Firefox キーストアから書き出します。

    注意: Firefox から秘密キーと証明書を書き出す場合、そのファイルは、ADT、Flex、Flash および Dreamweaver で使用できる .p12(pfx)形式で書き出されます。
    1. Firefox の 証明書マネージャー ダイアログを開きます。

    2. Windows の場合は、ツール/オプション/詳細/暗号化/証明書を表示を開きます。

    3. Mac OS の場合は、Firefox/環境設定/詳細/暗号化/証明書を表示を開きます。

    4. Linux の場合は、編集/設定/詳細/暗号化/証明書を表示を開きます。

    5. 証明書の一覧から「Adobe AIR Code Signing Certificate」を選択し、「 バックアップ 」ボタンをクリックします。

    6. キーストアファイルを書き出すファイル名と場所を入力し、「 保存 」をクリックします。

    7. Firefox のマスタパスワードを使用している場合は、ファイルを書き出すためにソフトウェアセキュリティデバイスのパスワードの入力が要求されます(このパスワードは Firefox のみで使用されます)。

    8. 証明書バックアップパスワードの選択 ダイアログボックスで、キーストアファイルのパスワードを作成します。

      重要: このパスワードによってキーストアファイルは保護されます。このパスワードは、AIR アプリケーションへの署名にファイルが使用される際に必要になります。安全なパスワードを選択してください。
    9. 「OK」をクリックします。パスワードのバックアップが成功したことを示すメッセージが表示されます。秘密キーを含むキーストアファイルは、.p12 ファイル拡張子(PKCS12 形式)で保存されます。

  6. 書き出したキーストアファイルを ADT、Flash Builder、Flash Professional または Dreamweaver で使用します。ファイルに対して作成されたパスワードは、AIR アプリケーションが署名されるたびに必要になります。

重要: 秘密キーと証明書は Firefox キーストアにも格納されます。これにより証明書ファイルの追加のコピーを書き出せますが、証明書と秘密キーのセキュリティを維持するために保護する必要がある別のアクセスポイントも提供されます。

証明書の変更

場合によっては、AIR アプリケーションのアップデートの署名に使用する証明書を変更する必要があります。これが必要になるのは、次のような場合です。

  • 元の署名証明書を更新する

  • 自己署名入り証明書を証明機関から発行された証明書にアップグレードする

  • 有効期限が近い自己署名入り証明書を別の証明書に変更する

  • ある商用証明書を別の商用証明書に変更する(企業の ID が変更された場合など)

AIR で AIR ファイルをアップデートとして認識できるようにするには、元の AIR ファイルとアップデートの AIR ファイルに同じ証明書を使用して署名するか、アップデートに証明書の移行署名を適用します。移行署名は、アップデートの AIR パッケージに適用される 2 つ目の署名です。これには元の証明書が使用されます。移行署名では元の証明書を使用して、署名者がアプリケーションの元の発行者であることを証明します。

移行署名が適用された AIR ファイルがインストールされると、新しい証明書がプライマリ証明書になります。後続のアップデートに移行署名を適用する必要はありません。ただし、移行署名はできるだけ長い期間にわたって適用し、アップデートを実行していないユーザーに対応する必要があります。

重要: 証明書の期限が切れる前に、証明書を変更し、元の証明書を使用してアップデートに移行署名を適用する必要があります。これを行わない場合は、新しいバージョンをインストールする前に、アプリケーションの既存のバージョンをアンインストールする必要があります。AIR 1.5.3 以降では、期限切れ後 365 日の猶予期間以内であれば、期限切れの証明書を使用して移行署名を適用できます。ただし、期限切れの証明書を使用してメインアプリケーションに署名を適用することはできません。

証明書を変更するには:

  1. アプリケーションのアップデートを作成します。

  2. アップデートの AIR ファイルをパッケージ化し、 新しい 証明書で署名します。

  3. 元の 証明書を使用して(ADT の -migrate コマンドを使用して)AIR ファイルにもう一度署名します。

移行署名を含む AIR ファイルは、別の意味では通常の AIR ファイルです。元のバージョンがないシステムにアプリケーションをインストールした場合、AIR では通常の方法で新しいバージョンをインストールします。

注意: AIR 1.5.3 よりも前のバージョンでは、更新された証明書を使用して AIR アプリケーションに署名する場合、必ずしも移行署名は必要ありませんでした。AIR 1.5.3 以降、更新された証明書には必ず移行署名が必要です。

移行署名を適用するには、 ADT migrate コマンド を使用します。詳しくは、 AIR アプリケーションのアップデートバージョンの署名 を参照してください。

注意: ADT migrate コマンドは、ネイティブ拡張を含む AIR デスクトップアプリケーションでは使用できません。これらのアプリケーションは、.air ファイルではなくネイティブインストーラーとしてパッケージ化されているからです。ネイティブ拡張を含む AIR デスクトップアプリケーション向けの証明書を変更するには、 ADT package コマンド を -migrate フラグ付きで使用してアプリケーションをパッケージ化してください。

アプリケーション ID の変更

AIR 1.5.3 よりも前のバージョンでは、移行署名を使用して署名されたアップデートがインストールされると、AIR アプリケーションの ID が変更されていました。アプリケーションの ID の変更には、次のような影響があります。

  • 新しいバージョンのアプリケーションでは、既存の暗号化されたローカルストアにあるデータにアクセスできません。

  • アプリケーション記憶域ディレクトリの場所が変更されます。以前の場所にあるデータが新しいディレクトリにコピーされません(ただし、新しいアプリケーションは、以前の発行者 ID に基づく元のディレクトリには配置できません)。

  • アプリケーションは、以前の発行者 ID を使用してローカル接続を開くことができなくなります。

  • Web ページからのアプリケーションへのアクセスに使用する識別ストリングが変更されます。

  • アプリケーションの OSID が変更されます(OSID はカスタムインストール / アンインストールプログラムの記述時に使用します)。

AIR 1.5.3 以降を使用してアップデートを発行する場合、アプリケーション ID は変更できません。元のアプリケーションと発行者 ID は、アップデートの AIR ファイルのアプリケーション記述子に指定されている必要があります。指定されていない場合、新しいパッケージはアップデートとして認識されません。

注意: AIR 1.5.3 以降を使用して新しい AIR アプリケーションを発行する場合、発行者 ID は指定しないでください。

用語集

ここでは、公開配布するアプリケーションへの署名方法を決定する際に理解しておく必要があるいくつかの用語を示します。

用語

説明

証明機関(CA)

信頼できるサードパーティの役割を果たし、最終的に公開キーの所有者の ID を認定する公開キーインフラストラクチャネットワーク内のエンティティ。CA は一般的に、所有している秘密キーで署名した電子証明書を発行し、証明書の所有者の ID が検証済みであることを証明します。

Certificate Practice Statement(CPS)

証明書を発行および検証する証明機関の運用とポリシーを規定します。CPS は、CA とその加入者およびその関係者間で結ばれる契約の一部です。また、証明機関が提供する証明書の ID 検証のポリシーおよび保証のレベルについても記載されています。

Certificate Revocation List(CRL)

発行済み証明書の中で、取り消され、信頼されなくなった証明書のリスト。AIR は、AIR アプリケーションの署名時に CRL をチェックし、タイムスタンプがない場合は、もう一度アプリケーションをインストールします。

証明書チェーン

証明書チェーンは一連の証明書のことで、チェーン内の各証明書はその次の証明書で署名されています。

電子証明書

所有者の ID、所有者の公開キー、および証明書自体の ID で構成されている電子ドキュメント。証明機関で発行された証明書自体は、発行側の CA に属する証明書で署名されます。

電子署名

公開キーと秘密キーのペアの公開キーでのみ解読できる暗号化されたメッセージまたはダイジェスト。PKI では、電子署名には、最終的に証明機関で追跡可能な 1 つ以上の電子証明書が含まれます。電子署名は、署名後に(使用されている暗号化アルゴリズムが提供する保証の制限内で)改ざんされていないメッセージ(またはコンピューターファイル)の検証に使用でき、発行側の証明機関、署名者の ID が信頼できることが前提になります。

キーストア

電子証明書、および関連の秘密キーが含まれる場合もあるデータベース。

Java Cryptography Architecture(JCA)

キーストアを管理したり、キーストアにアクセスするための拡張可能なアーキテクチャ。詳しくは、『 Java Cryptography Architecture Reference Guide 』(英語)を参照してください。

PKCS #11

RSA Laboratories が策定した暗号化トークンインターフェイス標準。ハードウェアトークンベースのキーストアです。

PKCS #12

RSA Laboratories が策定した個人情報交換シンタックス標準。通常秘密キーと関連の電子証明書を含むファイルベースのキーストアです。

秘密キー

2 つの部分から構成される公開キーと秘密キーの非対称暗号化システムの秘密の部分。秘密キーは、秘密を保持する必要があり、ネットワーク上で転送されません。電子署名されたメッセージは、署名者によって秘密キーで暗号化されます。

公開キー

2 つの部分から構成される公開キーと秘密キーの非対称暗号化システムの公開の部分。公開キーは自由に利用でき、秘密キーで暗号化されたメッセージの解読に使用されます。

公開キーインフラストラクチャ(PKI)

証明機関が公開キーの所有者の ID を証明するための信頼性のシステム。ネットワークのクライアントは、信頼できる CA が発行した電子証明書を信頼して、電子メッセージ(またはファイル)の署名者の ID を検証します。

タイムスタンプ

イベントの発生日時を含む電子署名されたデータ。ADT には、AIR パッケージ内の RFC 3161 準拠のタイムサーバーからのタイムスタンプを含めることができます。タイムスタンプがある場合、AIR はそのタイムスタンプを使用して、署名時に証明書の有効性を立証します。これにより、AIR アプリケーションは、署名された証明書の期限が切れてもインストールできます。

タイムスタンプ局

タイムスタンプを発行する局。AIR でタイムスタンプを認識するために、タイムスタンプは RFC 3161 に準拠し、タイムスタンプ署名はインストールマシンの信頼できるルート証明書にチェーン化されている必要があります。

iOS 証明書

Apple が発行するコードサイニング証明書は、Adobe AIR を使用して開発されたアプリケーションなどの iOS アプリケーションの署名に使用されます。テストデバイスにアプリケーションをインストールするには、Apple 開発用証明書を使用して署名を適用する必要があります。完成したアプリケーションを配布するには、配布用証明書を使用して署名を適用する必要があります。

アプリケーションに署名するには、ADT がコードサイニング証明書と関連する秘密キーの両方にアクセスできる必要があります。証明書ファイル自体には秘密キーは含まれません。証明書と秘密キーの両方を含む Personal Information Exchange ファイル(.p12 または .pfx)の形式でキーストアを作成する必要があります。 P12 キーストアファイルへの開発用証明書の変換 を参照してください。

証明書署名要求の生成

開発用証明書を取得するには、証明書署名要求を生成して、Apple iOS Provisioning Portal に送信する必要があります。

証明書署名要求の処理によって、公開キーと秘密キーのペアが生成されます。秘密キーはユーザーのコンピューター上に残ります。証明機関の役割を担う Apple に、公開キーとユーザーの識別情報を含む署名要求を送信します。Apple は独自の World Wide Developer Relations 証明書を使用して、ユーザーの証明書に署名します。

Mac OS での証明書署名要求の生成

Mac OS では、キーチェーンアクセスアプリケーションを使用して、コード署名要求を作成できます。キーチェーンアクセスアプリケーションは、アプリケーションディレクトリのユーティリティサブディレクトリあります。証明書署名要求の生成方法の説明については、Apple iOS Provisioning Portal を参照してください。

Windows での証明書署名要求の生成

Windows での開発者にとっては、Mac コンピューターで iPhone 開発用証明書を入手するほうが簡単です。しかし、Windows コンピューターで証明書を入手することもできます。最初に、OpenSSL を使用して証明書の署名リクエスト(CSR ファイル)を作成します。

  1. Windows コンピューターに OpenSSL をインストールします( http://www.openssl.org/related/binaries.html に移動します)。

    また、Visual C++ 2008 再頒布可能ファイルもインストールする必要があります。このファイルは Open SSL のダウンロードページにリストされています(コンピューターに Visual C++ をインストールする必要はありません)。

  2. Windows コマンドセッションを開き、OpenSSL の bin ディレクトリ(c:¥OpenSSL¥bin¥ など)に移動します。

  3. コマンドラインで次のように入力して秘密鍵を作成します。

    openssl genrsa -out mykey.key 2048

    この秘密鍵ファイルを保存します。このファイルは後で使用します。

    OpenSSL を使用するときは、エラーメッセージを無視しないようにしてください。OpenSSL でエラーメッセージが生成されても、引き続きファイルが出力される場合があります。ただし、それらのファイルは使用できません。エラーが表示されたら、シンタックスを確認して、コマンドを再実行してください。

  4. コマンドラインで次のように入力して CSR ファイルを作成します。

    openssl req -new -key mykey.key -out CertificateSigningRequest.certSigningRequest  -subj "/emailAddress=yourAddress@example.com, CN=John Doe, C=US"

    電子メールアドレス、CN(証明書名)、C(国)を、ユーザー独自の値に置き換えます。

  5. iPhone デベロッパーサイト で、Apple に CSR ファイルをアップロードします(「iPhone 開発用証明書の申請およびプロビジョニングプロファイルの作成」を参照してください)。

P12 キーストアファイルへの開発用証明書の変換

P12 キーストアファイルを作成するには、Apple 開発用証明書および関連する秘密キーを、単一のファイルに組み合わせる必要があります。キーストアファイルの作成手順は、元の証明書署名要求の生成方法および秘密キーの保存先によって異なります。

Mac OS での iPhone 開発用証明書の P12 ファイルへの変換

Apple iPhone 証明書を Apple からダウンロードしたら、P12 キーストア形式に書き出します。Mac® OS でこれを行う手順は次のとおりです。

  1. アプリケーション/ユーティリティフォルダー内にあるキーチェーンアクセスアプリケーションを開きます。

  2. 証明書をキーチェーンにまだ追加していない場合は、ファイル/読み込みを選択します。次に、Apple から取得した証明書ファイル(.cer ファイル)に移動します。

  3. キーチェーンアクセスの「分類」で「鍵」を選択します。

  4. 使用している iPhone 開発用証明書に関連付けられている秘密鍵を選択します。

    秘密鍵は、ペアになっている iPhone Developer: <First Name> <Last Name> 公開証明書によって識別されます。

  5. iPhone Developer 証明書を Command キーを押しながらクリックし、 「iPhone Developer: Name...」の書き出し を選択します。

  6. Personal Information Exchange(.p12)ファイル形式でキーストアを保存します。

  7. パスワードを作成するようメッセージが表示されます。このパスワードは、キーストアを使用してアプリケーションを署名するときや、キーストア内のキーと証明書を他のキーストアに転送するときに使用します。

Windows における P12 ファイルへの Apple 開発用証明書の変換

AIR for iOS アプリケーションを開発するには、P12 証明書ファイルを使用する必要があります。この証明書は、Apple から入手する Apple iPhone 開発用証明書ファイルに基づいて生成します。

  1. Apple から入手した開発用証明書ファイルを PEM 証明書ファイルに変換します。OpenSSL の bin ディレクトリから、次のコマンドラインステートメントを実行します。

    openssl x509 -in developer_identity.cer -inform DER -out developer_identity.pem -outform PEM
  2. Mac コンピューターで、キーチェーンから秘密鍵を使用している場合は、秘密鍵を PEM キーに変換します。

    openssl pkcs12 -nocerts -in mykey.p12 -out mykey.pem
  3. これで、キーと PEM 版の iPhone 開発用証明書に基づいて、有効な P12 ファイルを生成できます。

    openssl pkcs12 -export -inkey mykey.key -in developer_identity.pem -out iphone_dev.p12

    Mac OS キーチェーンからキーを使用している場合は、前の手順で生成した PEM 版を使用します。それ以外の場合は、前に(Windows で)作成した OpenSSL キーを使用します。