Secure Sockets Layer の入門および iKeyman ユーザーズ・ガ …publib.boulder.ibm.com/tividd/td/ITAME/SC32-1363-00/ja...本書は、Secure Socket Layer (SSL) ベースのシステムをインストール、管理、およ

IBM Global Security Kit

Secure Sockets Layer の入門およびiKeyman ユーザーズ・ガイド

バージョン 7a

SC88-9855-00

(英文原典：SC32-1363-00)

��


Secure Sockets Layer の入門およびiKeyman ユーザーズ・ガイド

バージョン 7a

SC88-9855-00

(英文原典：SC32-1363-00)

��

お願い本書および本書で紹介する製品をご使用になる前に、53 ページの『特記事項』に記載されている情報をお読みください。

本書は、iKeyman バージョン 7a および新しい版で特に明記しない限り、以降のすべてのリリースおよびモディフィケーションに適用されます。

本マニュアルに関するご意見やご感想は、次の URL からお送りください。今後の参考にさせていただきます。

http://www.ibm.com/jp/manuals/main/mail.html

なお、日本 IBM 発行のマニュアルはインターネット経由でもご購入いただけます。詳しくは

http://www.ibm.com/jp/manuals/ の「ご注文について」をご覧ください。

(URL は、変更になる場合があります)

お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。

　原　典： SC32-1363-00


Secure Sockets Layer Introduction and

iKeyman User’s Guide

Version 7a

　発　行：日本アイ・ビー・エム株式会社

　担　当：ナショナル・ランゲージ・サポート

第1刷 2004.1

この文書では、平成明朝体™W3、平成明朝体™W9、平成角ゴシック体™W3、平成角ゴシック体™W5、および平成角ゴシック体™W7を使用しています。この(書体*)は、（財）日本規格協会と使用契約を締結し使用しているものです。フォントとして無断複製することは禁止されています。

　　注* 平成明朝体™W3、平成明朝体™W9、平成角ゴシック体™W3、平成角ゴシック体™W5、平成角ゴシック体™W7

© Copyright International Business Machines Corporation 2004. All rights reserved.

© Copyright IBM Japan 2004

目次図 . . . . . . . . . . . . . . . . . v

まえがき . . . . . . . . . . . . . . vii本書の構成 . . . . . . . . . . . . . . viiソフトウェア・サポートへの連絡 . . . . . . . vii本書の規則 . . . . . . . . . . . . . . vii書体規則 . . . . . . . . . . . . . . viiオペレーティング・システム間の違い . . . . viii

第 1 章 Secure Sockets Layer の概要 . 1ディジタル証明書 . . . . . . . . . . . . . 1ディジタル証明書の形式 . . . . . . . . . 2ディジタル証明書のセキュリティー上の考慮事項 . 3認証局 (CA) と trust 階層 . . . . . . . . . 3インターネット・アプリケーションでディジタル証明書のために使用するもの . . . . . . . . . 4ディジタル証明書と認証要求 . . . . . . . . 6

SSL の仕組み . . . . . . . . . . . . . . 6SSL ハンドシェーク . . . . . . . . . . . 6SSL を使用したディジタル証明書および trust チェーン . . . . . . . . . . . . . . . . 8グローバル・サーバー証明書を備えた SSL . . . 9

第 2 章 iKeyman を使用したディジタル証明書の管理 . . . . . . . . . . . . 11iKeyman の開始 . . . . . . . . . . . . . 11鍵データベース・ファイルの作成 . . . . . . . 12テスト用の自己署名ディジタル証明書の作成 . . . 14CA ルート・ディジタル証明書の追加. . . . . . 15CA ルート・ディジタル証明書の削除. . . . . . 16データベース間の証明書のコピー . . . . . . . 17シナリオ 1: . . . . . . . . . . . . . 17シナリオ 2: . . . . . . . . . . . . . 18

ディジタル証明書の要求 . . . . . . . . . . 20ディジタル証明書の受信 . . . . . . . . . . 21ディジタル証明書の削除 . . . . . . . . . . 22新規デフォルト鍵の設定 (CMS のみ) . . . . . . 23データベース・パスワードの変更 . . . . . . . 24スマート・カード上のディジタル証明書の管理 . . 25

IBM JSSE を使用した暗号トークンのオープン . 27MS CryptoAPI を使用した暗号トークンのオープン . . . . . . . . . . . . . . . . 27

stash ファイルへの暗号化データベース・パスワードの保管 . . . . . . . . . . . . . . . . 28

第 3 章 IKEYCMD コマンド行インターフェースの使用 . . . . . . . . . . . 29

IKEYCMD コマンド行インターフェースの環境設定 29IKEYCMD コマンド行構文 . . . . . . . . . 31ユーザー・インターフェースのタスクの参照先 . . 31パスワードなしでの使用 . . . . . . . . . . 32新規鍵データベースの作成 . . . . . . . . . 33データベース・パスワードの設定 . . . . . . 34データベース・パスワードの変更 . . . . . . 34

新規の鍵ペアと認証要求の作成 . . . . . . . . 35自己署名証明書の作成 . . . . . . . . . . . 35鍵のエクスポート . . . . . . . . . . . . 36鍵のインポート . . . . . . . . . . . . . 37CA のリスト作成 . . . . . . . . . . . . 38鍵データベースのオープン . . . . . . . . . 38CA 署名証明書 . . . . . . . . . . . . . 38鍵データベース内のデフォルト鍵の表示 . . . . . 39証明書の詳細情報の表示 . . . . . . . . . . 39CA 証明書の保管 . . . . . . . . . . . . 40stash ファイルへの暗号化データベース・パスワードの保管 . . . . . . . . . . . . . . . . 40スマート・カードにおけるディジタル証明書の管理 41

Microsoft 証明書ストアの管理 . . . . . . . 43Java 鍵ストアの管理 . . . . . . . . . . 43

IKEYCMD コマンド行パラメーターの概要 . . . . 44IKEYCMD コマンド行オプションの概要 . . . . . 45CMS 鍵データベースのコマンド行呼び出し . . . 46暗号化コマンド行の呼び出し (CMS インプリメンテーション) . . . . . . . . . . . . . . . 47暗号化コマンド行の呼び出し (IBM JSSE インプリメンテーション) . . . . . . . . . . . . . 48PKCS11 暗号化コマンド行の呼び出し (MicrosoftCryptoAPI インプリメンテーション) . . . . . . 48Microsoft 証明書ストアのコマンド行呼び出し . . . 49鍵ストアのすべてのタイプ(CMS、JKS、JCEKS、PKCS12) のコマンド行呼び出し . . . . . . . . . . . . . . . . . 49ユーザー・プロパティー・ファイル . . . . . . 50

第 4 章アクセシビリティーに関するGSKit iKeyman のサポート . . . . . . 51

付録. 特記事項. . . . . . . . . . . . 53商標 . . . . . . . . . . . . . . . . . 54

索引 . . . . . . . . . . . . . . . . 57

© Copyright IBM Corp. 2004 iii

iv IBM Global Security Kit: Secure Sockets Layer の入門および iKeyman ユーザーズ・ガイド

図1. 単純なディレクトリー・ツリー . . . . . . 22. 単純化したディジタル証明書のレイアウト 33. trust チェーン — ルート CA に至るまで CAディジタル証明書に署名する CA. . . . . . 4

4. 「新規」鍵データベース・ファイル・ウィンドウ . . . . . . . . . . . . . . . . 12

5. 「パスワード・プロンプト」ウィンドウ 136. 「新規自己署名証明書の作成」ウィンドウ 157. 「新規の鍵および証明書要求の作成」ウィンドウ . . . . . . . . . . . . . . . . 21

8. 鍵情報ウィンドウ . . . . . . . . . . 249. 「IBM 鍵管理 (IBM Key Management)」ウィンドウ内の暗号トークン . . . . . . . . . 26

10. 「暗号トークンのオープン」ウィンドウ 2611. IBM JSSE を使用した鍵データベース・ファイ

ルのオープン . . . . . . . . . . . . 2712. 暗号トークンのスロット番号の選択 . . . . 27

© Copyright IBM Corp. 2004 v

vi IBM Global Security Kit: Secure Sockets Layer の入門および iKeyman ユーザーズ・ガイド

まえがき

本書は、Secure Socket Layer (SSL) ベースのシステムをインストール、管理、および使用するネットワークまたはシステム・セキュリティー管理者を対象としています。

ご使用のネットワークおよび e-business アプリケーションについて理解している必要があります。

本書の構成本書は、以下の章で構成されています。

v 1ページの『第 1 章 Secure Sockets Layer の概要』には、SSL とディジタル証明書の概要が記載されています。

v 11ページの『第 2 章 iKeyman を使用したディジタル証明書の管理』は、ディジタル証明書の管理に使用できるツールになる iKeyman ユーティリティーについて説明しています。

v 29ページの『第 3 章 IKEYCMD コマンド行インターフェースの使用』は、IKEYCMD コマンド行について説明しています。

v 51ページの『第 4 章アクセシビリティーに関する GSKit iKeyman のサポート』は、アクセシビリティー機能について説明しています。

ソフトウェア・サポートへの連絡IBM 営業担当員にお問い合わせください。

本書の規則本書では、特別な用語とアクションに関して、およびオペレーティング・システムに依存するコマンドおよびパスに関して、いくつかの規則を使用しています。

書体規則本書では、以下の書体規則を使用しています。

太字周囲にあるテキスト、キーワード、パラメーター、オプション、Java クラスやオブジェクトの名前との区別が難しい小文字コマンドまたは大文字小文字混合コマンドは太字で示されます。

イタリック変数、資料のタイトル、および強調される特殊な用語または句はイタリックで示されます。

モノスペースコード例、コマンド行、画面出力、周囲にあるテキストとの区別が難しいフ

© Copyright IBM Corp. 2004 vii

ァイル名およびディレクトリー名、システム・メッセージ、ユーザーの入力が必要なテキスト、引き数またはコマンド・オプションの値はモノスペースで示されます。

オペレーティング・システム間の違い本書では、環境変数の指定およびディレクトリー表記について UNIX 規則を使用します。Windows コマンド行を使用するときは、環境変数の場合は $variable を%variable% に置き換え、ディレクトリー・パスの場合はスラッシュ (/) を円記号(¥) に置き換えてください。Windows システムで bash シェルを使用している場合は、UNIX 規則を使用できます。

viii IBM Global Security Kit: Secure Sockets Layer の入門および iKeyman ユーザーズ・ガイド

第 1 章 Secure Sockets Layer の概要

今日の電子ビジネス環境においてプライバシーとセキュリティーは、従来にも増して重要な概念となっています。

ビジネスの専門家であれば誰もが、インターネットなど、公開された通信ネットワーク上のセキュリティーに関心を持つ必要があります。セキュアな Web サイトを用意するだけでは不十分です。Web サイト間にセキュアな通信、つまり外部の第三者がモニターできない通信を用意することも必要です。ユーザーとその顧客の両方が、セキュアな環境でビジネスを行っていることを確信する必要があります。

このようなセキュア通信には暗号化が必要です。暗号化とは、Secure Sockets Layer

(SSL) によって提供される、データ通信接続のためのセキュリティーです。

SSL は Netscape® Communications と RSA® Data Security が共同で開発しました。世界各地で数多くの会社が SSL 通信プロトコルを採用しています。たとえば、オンライン・バンキングなど、インターネット上で行われる多くの金融取引は SSL を使用して処理されます。

この章は、以下の 2 つの節で構成されています。

v 『ディジタル証明書』

v 6ページの『SSL の仕組み』

ディジタル証明書ディジタル証明書によってエンティティーを固有に識別できます。本質的に、この証明書は信頼された第三者によって発行された電子 ID カードです。ディジタル証明書を使用すると、証明書の発行先および証明書の発行者を確認できます。

ディジタル証明書は SSL が公開鍵暗号方式に使用する媒体です。公開鍵暗号方式では、秘密鍵と公開鍵という 2 つの暗号鍵を使用します。公開鍵暗号方式は非対称暗号方式としても知られます。これは、情報を暗号化するときに 1 つの鍵を使用し、暗号化を解除するときには指定された公開鍵と秘密鍵の鍵ペアによる補完鍵を使用するためです。

公開鍵と秘密鍵のペアは、ユーザーの暗号化方式に対応する鍵として機能する長いデータ・ストリングにすぎません。ユーザーは秘密鍵をセキュアな場所に保持しておき (たとえばコンピューターのハード・ディスク上で暗号化)、通信する任意の相手に公開鍵を提供します。秘密鍵はユーザーによって送信されたすべてのセキュア通信のデジタル署名に使用されます。公開鍵は送信者のシグニチャーを確認するために受信者が使用します。

公開鍵暗号方式は信頼によって成り立っています。つまり、公開鍵の受信者は鍵が本当に送信者のものであり、なりすまし者のものではないことを信頼する必要があります。ディジタル証明書がこの信頼性を提供します。

© Copyright IBM Corp. 2004 1

ディジタル証明書には、所有者の ID 設定と所有者の公開鍵の有効化という 2 つの目的があります。ディジタル証明書は信頼された管轄局、つまり認証局 (CA) が期間を限定して発行します。ディジタル証明書の有効期限が経過すると、取り替える必要があります。

ディジタル証明書の形式ディジタル証明書には、証明書の所有者 ID および認証局 (CA) に関する次の特定の情報が含まれています。

v 所有者の識別名。識別名は、所有者の共通名とそのディレクトリー・ツリー内のコンテキスト (位置) を組み合わせた名前です。図 1 に示す単純なディレクトリー・ツリーの場合、LaurenA が所有者の共通名 (CN)、組織単位 (OU) はEngnring、組織 (O) は XYZCorp なので、識別名は次のようになります。

.CN=LaurenA.OU=Engnring.O=XYZCorp

v 所有者の公開鍵。

v ディジタル証明書が発行された日付。

v ディジタル証明書の有効期限が切れる日付。

v 発行者の識別名。発行 CA の識別名。

v 発行者のデジタル署名。

3ページの図 2 に標準的なディジタル証明書のレイアウトを示します。

図 1. 単純なディレクトリー・ツリー

2 IBM Global Security Kit: Secure Sockets Layer の入門および iKeyman ユーザーズ・ガイド

ディジタル証明書のセキュリティー上の考慮事項送信者の公開鍵を組み込んだディジタル証明書を受信者が、ディジタル証明書を悪用して送信者を装うことを何によって阻止しますか。答えは、送信者の秘密鍵です。

ディジタル証明書だけではどの人物の ID も証明できません。ディジタル証明書で可能なのはディジタル証明書所有者の ID を確認することだけで、これはディジタル証明書所有者のデジタル署名の確認に必要な公開鍵の提供によって行われます。したがって、ディジタル証明書所有者はディジタル証明書内の公開鍵に属する秘密鍵を保護する必要があります。秘密鍵が盗まれると、盗んだ人物はそのディジタル証明書の正当な所有者を装うことができます。秘密鍵がなければ、ディジタル証明書を悪用できません。

認証局 (CA) と trust 階層ディジタル証明書では trust が非常に重要な概念です。各組織またはユーザーは、CA を信頼できる機関として受諾できるかどうか判別する必要があります。

公開鍵の知識が必要なセキュリティー・サービスのユーザーは、通常、必要な公開鍵を含むディジタル証明書を取得して確認する必要があります。相手側からディジタル証明書を受け取っても、そのディジタル証明書の認証性については何の保証もありません。ディジタル証明書が信頼できることを確認するため、受信側にはディジタル証明書を発行した認証局 (CA) の公開鍵が必要です。

ディジタル証明書に署名した認証局 (CA) の公開鍵の確実なコピーを公開鍵のユーザーが保有していない場合、その公開鍵を取得するために追加のディジタル証明書

図 2. 単純化したディジタル証明書のレイアウト

第 1 章 Secure Sockets Layer の概要 3

が必要になることもあります。一般に、複数ディジタル証明書のチェーンが必要になる可能性があります。このチェーンは、1 つの CA が署名した公開鍵所有者 (エンド・エンティティー) のディジタル証明書で構成され、状況に応じて、ほかの CA

が署名した CA の 1 つ以上の追加ディジタル証明書で構成されます。図 3 に trust

チェーンを示します。

対象のディジタル証明書を受信側に送信する多くのアプリケーションでは、そのディジタル証明書だけでなく、最初のディジタル証明書からルート CA までの確認に必要なすべての CA ディジタル証明書も送信することに注意してください。

trust チェーンはルート CA から始まります。ルート CA のディジタル証明書は自己署名です。つまり、認証局 (CA) は自分の秘密鍵を使用してディジタル証明書に署名します。シグニチャーの確認に使用する公開鍵は、ディジタル証明書自体に含まれる公開鍵です。trust チェーンを確立するため、公開鍵ユーザーは以下のいずれかの方法でルート CA のディジタル証明書を受け取っている必要があります。

v 書留郵便で受け取るか、または本人が直接受け取ったディスケット。

v 信頼できる送信元から受信したソフトウェアによるプリロード、または認証済みサーバーからのダウンロード。

インターネット・アプリケーションでディジタル証明書のために使用するもの

鍵交換またはデジタル署名に公開鍵暗号方式を使用するアプリケーションでは、ディジタル証明書を使用して必要な公開鍵を取得する必要があります。このようなイ

図 3. trust チェーン — ルート CA に至るまで CA ディジタル証明書に署名する CA


ンターネット・アプリケーションは多数あります。以下に、公開鍵暗号方式を使用するインターネット・アプリケーションでよく使用されるものを、いくつか簡潔に説明します。

SSL 通信のプライバシーおよび保全性を提供するプロトコル。このプロトコルは以下によって使用されます。

v Web サーバー。Web サーバーと Web ブラウザー間の接続にセキュリティーを提供するために使用します。

v LDAP。LDAP クライアントと LDAP サーバー間の接続にセキュリティーを提供するために使用します。

v Host-on-Demand V2。クライアントとホスト・システム間の接続にセキュリティーを提供するために使用します。

このプロトコルを基にした他のアプリケーションも開発中です。

SSL では鍵交換、サーバー認証、およびオプションのクライアント認証でディジタル証明書を使用します。

クライアント認証クライアント認証は SSL のオプションで、あるリソースへのログオンまたはアクセスをクライアントに許可する前に、そのクライアントのディジタル証明書を認証するようサーバーに要求します。サーバーは SSL ハンドシェーク中にクライアントのディジタル証明書を要求し認証します。この時にサーバーは、クライアントにディジタル証明書を発行した CA を信頼するかどうかも決定できます。

セキュア電子メールセキュア電子メールのために Privacy Enhanced Mail (PEM) やSecure/Multipurpose Internet Mail Extensions (S/MIME) などの規格を使用する多くの電子メール・システムでは、デジタル署名および鍵交換にディジタル証明書を使用してメッセージの暗号化と暗号化解除を行います。

仮想プライベート・ネットワーク (VPN)仮想プライベート・ネットワークはセキュア・トンネルともいい、安全でない通信リンク上でセキュア・ネットワーク間の接続を保護できるようにファイアウォール間にセットアップできます。これらのネットワークに向けられるすべてのトラフィックはファイアウォール間で暗号化されます。

トンネリングで使用されるプロトコルは IP セキュリティー (IPsec) 規格に従います。パートナー・ファイアウォール間の鍵交換には、Internet Key

Exchange (IKE) 規格 (旧名称は ISAKMP/Oakley) が定義されています。

また、この規格によってリモート・クライアント (たとえば、在宅勤務の従業員など) とセキュア・ホストまたはネットワークとの間で、暗号化されたセキュア接続が可能になります。

Secure Electronic Transaction (SET)SET はインターネットなど、安全でないネットワークを使用したクレジット・カードによるセキュア決済用に設計された規格です。カード所有者 (電子クレジット・カード) とマーチャントに、ディジタル証明書が使用されます。ディジタル証明書を SET で使用すると、カード所有者、マーチャント、銀行間で、セキュア・プライベート接続が可能になります。確立されたトランザクションはセキュアで確実なものになり、トランザクションを偽る


ことが不可能になります。マーチャント側では、悪用されたり盗まれる可能性のあるクレジット・カード情報を受け取りません。

ディジタル証明書と認証要求単純化された署名済みディジタル証明書には、所有者の識別名、所有者の公開鍵、認証局 (CA) の (発行者の) 識別名、およびその認証局 (CA) のシグニチャーが含まれます。

自己署名ディジタル証明書には、所有者の識別名、所有者の公開鍵、およびこうしたフィールド上の所有者自身のシグニチャーが含まれます。

ルート CA のディジタル証明書は、自己署名ディジタル証明書の例です。サーバー製品の開発およびテスト時に使用する、自分自身の自己署名ディジタル証明書を作成することもできます。詳細は、 14ページの『テスト用の自己署名ディジタル証明書の作成』を参照してください。

認証局 (CA) に送信されて署名される認証要求には、所有者の (要求側の) 識別名、所有者の公開鍵、および所有者自身のシグニチャーが含まれます。認証局 (CA) は以下の事項を保証するため、ディジタル証明書の公開鍵を使用して所有者のシグニチャーを確認します。

v 要求側と CA 間の転送中に、認証要求が変更されなかったこと。

v 要求側が認証要求内の公開鍵に属する秘密鍵を所有していること。

CA は、ある程度の識別検査も行います。この検査は、所有者の身元についてほとんど証明しない場合から、絶対的な保証になる場合まであります。

SSL の仕組みSSL は TCP/IP を使用する 2 つの通信アプリケーション間のプライバシーおよび保全性を提供するプロトコルです。ワールド・ワイド・ウェブ用の Hypertext Transfer

Protocol (HTTP) はセキュア通信のために SSL を使用します。

クライアントとサーバー間で送受信されるデータは、DES や RC4 などの対称アルゴリズムを使用して暗号化されます。公開鍵アルゴリズム (多くの場合、RSA) は、暗号鍵の交換、およびデジタル署名に使用されます。このアルゴリズムではサーバーのディジタル証明書にある公開鍵を使用します。サーバーのディジタル証明書を使用して、クライアントもサーバーの ID を確認できます。SSL プロトコルのバージョン 1 および 2 では、サーバー認証だけを提供します。バージョン 3 では、クライアントとサーバー両方のディジタル証明書を使用する、クライアント認証が加わります。

SSL ハンドシェークHTTP ベースの SSL 接続は、必ず http:// ではなく、https:// で始まる URL を使用して、クライアントが開始します。SSL セッションの先頭で、SSL ハンドシェークが実行されます。このハンドシェークによって、セッションの暗号パラメーターが作成されます。SSL ハンドシェーク処理の仕組みについて簡略化した概要を以


下の図に示します。

1. クライアントがクライアント「hello」メッセージを送信します。これには、SSL

のバージョンなど、クライアントの暗号能力 (クライアント側の設定順序でソート)、クライアントがサポートする暗号スイート、およびクライアントがサポートするデータ圧縮メソッドが示されています。また、このメッセージには 28 バイトの乱数も含まれます。

2. サーバーがサーバー「hello」メッセージで応答します。これには、サーバー側で選択した暗号メソッド (暗号スイート) とデータ圧縮メソッド、セッション ID、および別の乱数が含まれます。

注: クライアントおよびサーバーでは、共通する暗号スイートを少なくとも 1

つサポートしている必要があります。共通するスイートがない場合、ハンドシェークは失敗します。一般に、サーバーは最も強力な共通暗号スイートを選択します。

3. サーバーがディジタル証明書を送信します (この例でサーバーは SSL を使用した X.509 V3 ディジタル証明書を使用します)。

サーバーが SSL V3 を使用しているときに、サーバー・アプリケーション (Web

サーバーなど) でクライアント認証用にディジタル証明書が必要な場合、サーバーは「digital certificate request」メッセージを送信します。サーバーは「digital

certificate request」メッセージ内に、サポートするディジタル証明書の種類と受け入れ可能な認証局 (CA) の識別名のリストを入れて送信します。


4. サーバーはサーバー「hello done」メッセージを送信し、クライアントの応答を待ちます。

5. クライアント (Web ブラウザー) は、サーバー「hello done」メッセージを受信するとサーバーのディジタル証明書の妥当性を確認し、サーバーの「hello」パラメーターが受け入れ可能なことを検査します。

サーバーがクライアントのディジタル証明書を要求した場合、クライアントはディジタル証明書を送信します。適切なディジタル証明書がなければ、クライアントは「no digital certificate」アラートを送信します。このアラートは警告にすぎませんが、クライアント認証が必須の場合にはサーバー・アプリケーションでセッションが失敗する可能性があります。

6. クライアントは「client key exchange」メッセージを送信します。このメッセージには、サーバーの公開鍵で暗号化されたプレマスター・シークレットが含まれます。これは、対称暗号鍵とメッセージ確認コード (MAC) 鍵の生成で使用される 46 バイトの乱数です。

クライアントがサーバーにディジタル証明書を送信する場合、クライアントの秘密鍵で署名した「digital certificate verify」メッセージを送信します。このメッセージのシグニチャーを確認することにより、サーバーはクライアントのディジタル証明書の所有権を明確に確認できます。

注: サーバーのディジタル証明書を確認する追加の処理は必要ありません。サーバーがディジタル証明書に所属する秘密鍵を所有していない場合は、プレマスター・シークレットの暗号化を解除できず、対称暗号化アルゴリズムで使用する適正な鍵を作成できないため、ハンドシェークは失敗します。

7. クライアントは一連の暗号操作を使用して、プレマスター・シークレットをマスター・シークレットに変換します。ここから、暗号化およびメッセージ認証に必要なすべての鍵の素材が得られます。次に、クライアントは「change cipher

spec」メッセージを送信して、サーバーが新しくネゴシエーションされた暗号スイートに切り替えるようにします。クライアントが送信する次のメッセージ(「finished」メッセージ) は、この暗号メソッドと鍵で暗号化された最初のメッセージです。

8. サーバーが自身の「change cipher spec」および「finished」メッセージで応答します。

9. SSL ハンドシェークが終了し、暗号化されたアプリケーション・データを送信できます。

SSL を使用したディジタル証明書および trust チェーンSecure Sockets Layer V3 では、クライアントのディジタル証明書と同様に、サーバーのディジタル証明書を使用できます。前述したように、クライアントの認証要求に応じて、クライアントのディジタル証明書はオプションですが、サーバーのディジタル証明書は SSL セッションに必須です。

SSL で使用される Public Key Infrastructure (PKI) は任意の数の root 認証局 (CA)

に対応します。組織またはエンド・ユーザーは、信頼する対象として受け入れるCA を自分で決定する必要があります。サーバーのディジタル証明書を確認できるようにするため、クライアントの Web ブラウザーはサーバー側で使用するルートCA ディジタル証明書の所有を要求します。一般的な Web ブラウザーには、通常、


鍵格納ファイルが付属し、ここにはトラステッド・ルートという CA ディジタル証明書が多数インストールされています。このリストは編集可能で、信頼できないCA のディジタル証明書は削除できます。

ルート CA ディジタル証明書が鍵格納ファイルにないディジタル証明書を送信するサーバーによって、SSL セッションが確立されようとしている場合、ブラウザーは警告ウィンドウを表示して、ディジタル証明書のインポートか、セッションの打ち切りかを選択するオプションを示します。この状態を回避するには、Web ページからルート CA ディジタル証明書をインポートするか、またはディジタル証明書をインポートする JavaScript プログラムを使用します。

クライアント認証が使用される場合、Web サーバーはクライアント側で使用するルート CA ディジタル証明書の所有を要求します。ルート CA ディジタル証明書はサーバー・アプリケーションに動的にインポートできないため、こうした CA によってクライアントのディジタル証明書が発行される前に iKeyman ユーティリティーを使用して、送達時にサーバーの鍵格納ファイルに含まれないすべてのルート CA ディジタル証明書をインストールしておく必要があります。iKeyman の詳細については 11ページの『第 2 章 iKeyman を使用したディジタル証明書の管理』を参照してください。

グローバル・サーバー証明書を備えた SSLインターナショナル・バージョンの Netscape Navigator®/Communicator® V4、Microsoft Internet Explorer™ V4、IBM SSL 使用可能クライアント・アプリケーション、またはグローバル・サーバー証明書が装備された SSL ツールキットおよびWeb サーバーを使用して記述されたクライアント・アプリケーションの間で SSL

セッションが確立されると、通常の SSL ハンドシェーク (7 ページで説明) が最初に実行されます。通常は、Web サーバーと Web ブラウザーが、暗号スイートSSL_RSA_EXPORT_WITH_RC4_40_MD5 を決定します。この場合、鍵交換には512 ビット RSA 鍵、暗号化には 40 ビット鍵を使用した RC4、メッセージ認証には MD5 がそれぞれ使用されます。

ハンドシェーク中に、ブラウザーはサーバーのディジタル証明書を受け取って確認し、このディジタル証明書がさらに強い暗号化も認可することを認識します。ブラウザーが「client hello」メッセージを使用してサポートする暗号スイートのリストを送信したあと、サーバーがディジタル証明書を送信することに注意してください。この時点でブラウザー側には、サーバーのグローバル・サーバー証明書に関する情報はありません。

最初のハンドシェークは、クライアントとサーバー両方からの「change cipher

specification」および「finished」メッセージで完了します。この時点でクライアントは別の SSL ハンドシェークを開始します。今度は、「client hello」メッセージの中にクライアントが以下のような強力な暗号スイートを組み込みます。

v SSL_RSA_WITH_RC4_128_MD5 (鍵交換に 1024 ビット RSA 鍵、暗号化に128 ビット鍵を使用した RC4、メッセージ認証には MD5)。

v SSL_RSA_WITH_3DES_EDE_CBC_SHA (鍵交換に 1024 ビット RSA 鍵、暗号化に 168 ビット鍵を使用した Triple-DES、メッセージ認証には SHA-1)。

2 番目のハンドシェークが完了したあと、さらに強固な暗号スイートの 1 つが使用されます。この二重ハンドシェークは SSL ステップアップ・プロトコルともいい


ます。実際に、SSL セッションで交換されるすべてのアプリケーション・データは、さらに強固な暗号化プロトコルで暗号化されます。米国ブラウザーを使用する場合と比べた唯一の欠点は、SSL ハンドシェークを 2 回実行するためにオーバーヘッドが大きくなることです。


第 2 章 iKeyman を使用したディジタル証明書の管理

iKeyman ユーティリティーは、ディジタル証明書の管理に使用できるツールです。iKeyman を使用すると、次の操作が可能になります。

v 新規鍵データベースの作成またはディジタル証明書の検査

v データベースへの CA ルートの追加

v あるデータベースから別のデータベースへの証明書のコピー

v CA に対するディジタル証明書の要求と CA からの証明書の受信

v デフォルト鍵の設定

v パスワードの変更

また、iKeyman ユーティリティーを使用して、スマート・カードのディジタル証明書に対してこれらと同様の機能の多くを実行できます。

iKeyman ユーティリティーは SSL ツールキットと共に自動的にインストールされます。

iKeyman の開始iKeyman バージョン 7 には次のような 3 種類のパッケージがあります。

v GSKit ユーザー向けの GSKit iKeyman

v Java のみのユーザー向けの GSKit Java-only iKeyman

v Java のみのユーザー向けの JDK iKeyman (IBM JDK 1.4.1 に添付)

GSKit を開始するには次の操作を行います。

1. 製品のマニュアルに従って、インストールのステップを完了し環境値を設定します。

2. 次のように iKeyman を起動します。

Windows:スタートアップ・メニューから iKeyman のショートカットをクリックします。

UNIX:

32 ビット・インストールで iKeyman を起動するには、次のように入力します。

gsk7ikm

64 ビットのインストールで iKeyman を起動するには、次のように入力します。

gsk7ikm_64

GSKit Java-only iKeyman を始動するには、次のようにします。

1. 製品のマニュアルに従って、インストールを完了し環境値を設定します。


2. iKeyman クラス・ファイルが抽出された場所にディレクトリーを変更します。次に例を示します。

cd /usr/local/ibm/gsk7/classes

3. 次のコマンドで iKeyman を起動します。

$JAVA_HOME/bin/java -classpath gsk7cls.jar com.ibm.gsk.ikeyman.Ikeyman

JDK iKeyman を始動するには、次の操作を行います。

1. 製品のマニュアルに従って、インストールを完了し環境値を設定します。

2. 次のコマンドで iKeyman を起動します。

$JAVA_HOME/bin/java com.ibm.gsk.ikeyman.Ikeyman

注: インストール・マニュアルに従って、IBM JDK 1.4.1 を使用し「JAVA_HOME/jre/lib/ext/gskikm.jar」を削除していない場合、iKeyman の開始手順と関係なく IBM JDK 1.4.1 iKeyman を実行します。実行中の iKeyman

のバージョンが分からない場合、「ヘルプ」メニューの「情報 (About)」をチェックしてバージョンの詳細を確認してください。バージョン 7.0.0.0 またはバージョン 6.0.0.0 と表示された場合、IBM JDK iKeyman が実行されています。

鍵データベース・ファイルの作成鍵データベースにより、クライアント・アプリケーションは、すでにディジタル証明書に署名した CA による署名付きのディジタル証明書を持つサーバーと接続できます。

CMS 鍵データベース・ファイルを作成するステップは、次のとおりです。

1. iKeyman を開始します。「IBM 鍵管理 (IBM Key Management)」ウィンドウが表示されます。

2. 「鍵データベース・ファイル (Key Database File)」 → 「新規」とクリックします。図 4 に示すとおり「新規」ウィンドウが表示されます。

3. 「鍵データベース・タイプ」フィールドの「CMS」を選択します。

4. 「ファイル名」に、「key.kdb」のようにファイル名を入力します。

5. 「位置」フィールドのデフォルト値をそのまま使用するか、新しい値を参照するか入力します。

6. 「OK」をクリックします。「パスワード・プロンプト」ウィンドウが表示されます ( 13ページの図 5 参照)。

図 4. 「新規」鍵データベース・ファイル・ウィンドウ


7. 「パスワード」フィールドにパスワードを入力し、「確認パスワード」フィールドでパスワードをもう一度確認します。「OK」をクリックします。

8. 確認ウィンドウが表示され、鍵データベースが作成されたことを確認できます。「OK」をクリックします。

鍵データベースが正常に作成され、「IBM 鍵管理 (IBM Key Management)」ウィンドウが表示されます。

ここで「IBM 鍵管理 (IBM Key Management)」ウィンドウに、作成した新規CMS 鍵データベース (たとえば、C:¥Program Files¥ibm¥gsk¥bin¥key.kdb) および署名者ディジタル証明書が反映されている必要があります。

以下の署名者ディジタル証明書が iKeyman にはあります。v RSA Secure Server Certification Authority

v Thawte Personal Basic CA

v Thawte Personal Freemail CA

v Thawte Personal Premium CA

v Thawte Premium Server CA

v Thawte Server CA

v VeriSign Class 1 CA Individual Subscriber-Persona Not Validated



v VeriSign Class 1 Public Primary Certification Authority



v VeriSign Class 1 Public Primary Certification Authority — G2



図 5. 「パスワード・プロンプト」ウィンドウ

第 2 章 iKeyman を使用したディジタル証明書の管理 13

v VeriSign Class 2 Onsite Individual Certification Authority

v VeriSign International Server Certification Authority — class 3

これらの署名者ディジタル証明書を使用することにより、クライアントはこれらの署名者からの有効なディジタル証明書を持つサーバーに接続できます。作成した鍵データベースは、作成後そのままの形で使用して、いずれかの署名者の有効なディジタル証明書を持つサーバーに接続できます。

このリストにない署名者ディジタル証明書を使用する必要がある場合は、それをCA に要求し、自らの鍵データベースにその証明書を追加する必要があります ( 15

ページの『CA ルート・ディジタル証明書の追加』を参照)。

テスト用の自己署名ディジタル証明書の作成実動アプリケーションの開発では、製品テストが終了するまで実際のディジタル証明書を購入する必要がない場合もあります。iKeyman を使用すると、テストが終了するまで自己署名ディジタル証明書を作成して使用できます。自己署名ディジタル証明書は、一時的なディジタル証明書で、自分自身が発行して自分自身が CA となります。

注: 自己署名ディジタル証明書で実動アプリケーションをリリースしないでください。ブラウザーやクライアントからサーバーを認識したり通信することができません。

鍵データベースに自己署名ディジタル証明書を作成するには、次の手順に従います。


2. 「鍵データベース・ファイル (Key Database File)」 → 「オープン」をクリックします。「オープン」ウィンドウが表示されます。

3. 自己署名ディジタル証明書を追加する鍵データベース・ファイルを選択して、「オープン」をクリックします。「パスワード・プロンプト」ウィンドウが表示されます。

4. パスワードを入力して「OK」をクリックします。「IBM 鍵管理 (IBM KeyManagement)」ウィンドウが表示されます。タイトル・バーに選択した鍵データベース名が表示され、このファイルが開かれて作業する準備ができていることを示します。

5. プルダウン・リストから「個人証明書 (Personal Certificates)」を選択します。

6. 「新規自己署名 (New Self-Signed)」を選択します。「新規自己署名証明書の作成」ウィンドウが表示されます ( 15ページの図 6 参照)。


7. 「keytest」のように、「鍵ラベル」フィールドに自己署名ディジタル証明書用のラベル名を入力します。

8. 共通名および組織を入力し、国を選択します。残りのフィールドはデフォルト値のままにするか、新規の値を入力します。

9. 「OK」をクリックします。「IBM 鍵管理 (IBM Key Management)」ウィンドウが表示されます。「個人証明書 (Personal Certificates)」フィールドに作成した自己署名ディジタル証明書が表示されます。

新規自己署名ディジタル証明書のデフォルトの有効期間は 365 日です。最短期間は1 日です。最長期間は 7300 日 (20 年) です。

CA ルート・ディジタル証明書の追加CA ルート・ディジタル証明書を要求し、CA から受け取ると、自分のデータベースに追加できます。ほとんどのルート・ディジタル証明書は、*.arm の形式 (たとえば「cert.arm」など) を取ります。

CA ルート・ディジタル証明書をデータベースに追加するには、以下の手順に従います。



図 6. 「新規自己署名証明書の作成」ウィンドウ


3. CA ルート・ディジタル証明書を追加する鍵データベース・ファイルを選択して「オープン」をクリックします。「パスワード・プロンプト」ウィンドウが表示されます。


5. プルダウン・リストから「署名者証明書 (Signer Certificates)」を選択します。

6. 「追加 (Add)」をクリックします。「ファイルから CA の証明書を追加 (AddCA’s Certificate from a File)」ウィンドウが表示されます。

7. 「データ・タイプ (Data type)」をクリックして「Base64 エンコード ASCIIデータ (Base64-encoded ASCII data)」のようにデータ・タイプを選択します。

8. CA ルート・ディジタル証明書の証明書ファイル名および位置を入力するか、「ブラウズ」をクリックして名前と位置を選択します。

9. 「OK」をクリックします。「ラベルの入力 (Enter a Label)」ウィンドウが表示されます。

10. 「VeriSign Test CA Root Certificate」のように、CA ルート・ディジタル証明書のラベルを入力して「OK」をクリックします。「IBM 鍵管理 (IBM KeyManagement)」ウィンドウが表示されます。

「署名者証明書 (Signer Certificates)」フィールドに追加した CA ルート・ディジタル証明書のラベルが表示されます。

CA ルート・ディジタル証明書の削除署名者ディジタル証明書リストのいずれかの CA のサポートが必要でなくなったときは、その CA のルート・ディジタル証明書を削除する必要があります。

注: CA ルート・ディジタル証明書を削除する前に、iKeyman から証明書を抽出してバックアップ・コピーを作成してください (後で CA ルートを再作成する場合)。

CA ルート・ディジタル証明書をデータベースから削除するには、以下の手順に従います。



3. CA ルート・ディジタル証明書を削除する鍵データベース・ファイルを選択して「オープン」をクリックします。「パスワード・プロンプト」ウィンドウが表示されます。



5. プルダウン・リストから「署名者証明書 (Signer Certificates)」を選択します。

6. 削除する CA ルート・ディジタル証明書を選択して「削除」をクリックします。「確認」ウィンドウが表示されます。「はい」をクリックします。

7. 「IBM 鍵管理 (IBM Key Management)」ウィンドウが表示されます。削除したCA ルート・ディジタル証明書のラベルが「署名者証明書 (SignerCertificates)」フィールドに表示されなくなります。

データベース間の証明書のコピー専用の信頼ネットワークを設定したか、またはテスト用に自己署名証明書を使用している場合、データベースから証明書を抽出して署名者証明書として別のデータベースに追加する必要があります。

シナリオ 1:(ソース) 鍵データベースから証明書を抽出して (ターゲット) 鍵データベースに署名者証明書として追加するには、次の手順に従います。



3. 別の (ターゲット) 鍵データベースに署名者証明書として追加する証明書を含む (ソース) 鍵データベースを選択して「オープン」をクリックします。「パスワード・プロンプト」ウィンドウが表示されます。

4. パスワードを入力して「OK」をクリックします。「IBM 鍵管理 (IBM KeyManagement)」ウィンドウが表示されます。タイトル・バーに選択した鍵データベースの名前が表示され、このクラスが開かれて作業する準備ができていることを示します。

5. エクスポートする証明書のタイプとして「個人 (Personal)」または「署名者(Signer)」のどちらかを選択します。

6. 別のデータベースに追加する証明書を選択します。

7. 「個人 (Personal)」を選択する場合、「証明書の抽出 (Extract Certificate)」をクリックします。「署名者 (Signer)」を選択した場合、「抽出 (Extract)」をクリックします。「証明書をファイルへ抽出 (Extract a Certificate to aFile)」ウィンドウが表示されます。

8. 「データ・タイプ (Data type)」をクリックして「Base64 エンコード ASCIIデータ (Base64-encoded ASCII data)」のようにデータ・タイプを選択します。このデータ・タイプは、証明書ファイルに保存されている証明書のタイプと一致する必要があります。iKeyman ツールは、Base64 エンコード ASCII ファイルおよびバイナリー DER エンコード証明書をサポートしています。

9. 証明書のファイル名と証明書を保存する位置を入力するか、「ブラウズ」をクリックして名前と位置をクリックします。

10. 「OK」をクリックします。証明書が指定されたファイルに書き込まれ、「IBM鍵管理 (IBM Key Management)」ウィンドウが表示されます。


署名者証明書として証明書をデータベース (ターゲット) に追加するには、以下の手順に従います。



3. 上記で抽出された証明書を追加する鍵データベースを選択して、「オープン」をクリックします。「パスワード・プロンプト」ウィンドウが表示されます。


5. 追加する証明書のタイプ「署名者 (Signer)」を選択します。

6. 「追加 (Add)」をクリックします。「ファイルから CA の証明書を追加 (AddCA’s Certificate from a File)」ウィンドウが表示されます。

7. 証明書を抽出したときに使用した証明書のファイル名を入力します。詳細については、上記のステップ9 (17ページ)を参照してください。

8. 「ラベルの入力 (Enter a Label)」ウィンドウが表示されます。

9. 証明書の名前を指定して「OK」をクリックします。

証明書が (ターゲット) データベースに追加されました。

シナリオ 2:前のシナリオでは、個人または署名者証明書をソース・データベースから抽出してターゲット・データベースへ署名者証明書として追加しました。このシナリオでは、個人証明書をソース・データベースからエクスポートし、ターゲット・データベースに個人証明書としてインポートします。

個人証明書を (ソース) 鍵データベースからエクスポートして個人証明書として (ターゲット) 鍵データベースにインポートするには、次の手順に従います。



3. 別の (ターゲット) 鍵データベースに個人証明書として追加する証明書を含む(ソース) 鍵データベースを選択して「オープン」をクリックします。「パスワード・プロンプト」ウィンドウが表示されます。



6. エクスポートする個人証明書を選択します。


7. 「エクスポート / インポート (Export/Import)」プッシュボタンを選択して現在のデータベースと PKCS#12 ファイルまたは別のデータベース間で鍵を転送します。「鍵のエクスポート / インポート (Export/Import Key)」ウィンドウが表示されます。

8. 「アクション・タイプの選択 (Choose Action Type)」から「鍵のエクスポート(Export Key)」を選択します。

9. リストをエクスポートするためにプルダウンから「鍵ファイル・タイプ (KeyFile Type)」 (たとえば PKCS12 ファイル) を選択します。

10. 証明書をエクスポートするファイルの名前 (たとえば「copy.p12」)　を入力するか、「ブラウズ」をクリックして名前と位置を選択し、「OK」をクリックします。「パスワード・プロンプト」ウィンドウが表示されます。

11. 証明書ファイルのパスワードを入力し、パスワードを確認して、「OK」をクリックします。

証明書が (ソース) データベースからエクスポートされました。

注: PKCS#12 ファイルは一時ファイルです。使用後削除してください。

個人証明書を (ターゲット) 鍵データベースにインポートするには、以下の手順に従います。



3. 上記でエクスポートした証明書をインポートする (ターゲット) 鍵データベースを選択して「オープン」をクリックします。「パスワード・プロンプト」ウィンドウが表示されます。



6. ターゲット鍵データベースに個人証明書がない場合、「インポート」をクリックして PKCS#12 ファイルまたは別のデータベースから鍵をインポートします。「鍵のインポート (Import Key)」ウィンドウが表示されます。ターゲット鍵データベースに 1 つまたは複数の個人証明書がある場合、次の手順に従います。

v 「鍵のエクスポート / インポート (Export/Import key)」プッシュボタンをクリックすると、「鍵のエクスポート / インポート (Export/Import key)」ウィンドウが表示されます。

v 「アクション・タイプの選択 (Choose Action Type)」から「インポート(Import)」を選択します。

7. エクスポートで選択した鍵ファイル・タイプと同じタイプを選択します。詳細については、ステップ9 (17ページ)を参照してください。


8. エクスポートした証明書を含むファイルの名前を入力するか、「ブラウズ」をクリックして名前とロケーションを選択します。詳細については、ステップ10 (19

ページ)を参照してください。「OK」をクリックします。「パスワード・プロンプト」ウィンドウが表示されます。

9. 証明書をエクスポートしたときのパスワードを指定します。詳細については、ステップ11 (19 ページ)を参照してください。「OK」をクリックします。

証明書が (ターゲット) データベースにインポートされました。

ディジタル証明書の要求ディジタル証明書は、SSL 対応のサーバー・コードを実行する必要があり、またクライアント・アプリケーションが必要な場合があります。ディジタル証明書を獲得するには、iKeyman を使用して要求を生成し、CA に要求を提出します。CA は依頼者の ID を検査して、ディジタル証明書を送信します。

鍵データベースにディジタル証明書を要求するには、以下の手順に従います。



3. 要求を生成する鍵データベース・ファイルを選択して「オープン」をクリックします。「パスワード・プロンプト」ウィンドウが表示されます。


5. プルダウン・リストから「個人証明書要求 (Personal Certificate Requests)」を選択します。

6. 「新規」をクリックします。「新規の鍵および証明書要求の作成」ウィンドウが表示されます ( 21ページの図 7 参照)。


7. ディジタル証明書要求用に、「Production Certificate for MyWeb at My

Company」のように「鍵ラベル」を入力します。

8. 共通名および組織を入力し、国を選択します。残りのフィールドはデフォルト値のままにするか、新規の値を入力します。

9. ウィンドウの最下部に、「certreq.arm」のようにファイル名を入力します。

10. 「OK」をクリックします。確認ウィンドウが表示されて、新規ディジタル証明書の要求が作成されたことを確認できます。

11. 「OK」をクリックします。「IBM 鍵管理 (IBM Key Management)」ウィンドウが表示されます。「個人証明書要求 (Personal Certificate Requests)」フィールドに作成した新規ディジタル証明書要求の鍵ラベルが表示されます。

12. ファイルを CA に送信して新規ディジタル証明書を要求するか、CA の Web

サイトの要求フォームに要求をカット・アンド・ペーストします。

ディジタル証明書の受信CA から新規ディジタル証明書が送信されると、その証明書を要求を生成した鍵データベースに追加する必要があります。

ディジタル証明書を受信して鍵データベースに追加するには、以下の手順に従います。



図 7. 「新規の鍵および証明書要求の作成」ウィンドウ


3. 要求を生成した鍵データベース・ファイルを選択して「オープン」をクリックします。「パスワード・プロンプト」ウィンドウが表示されます。



6. 「受信 (Receive)」をクリックします。「ファイルから証明書を受信 (ReceiveCertificate from a File)」ウィンドウが表示されます。

7. 「データ・タイプ (Data type)」をクリックして、「Base64 エンコードASCII データ (Base64-encoded ASCII data)」のように新規ディジタル証明書のデータ・タイプを選択します。CA が E メール・メッセージの一部として証明書を送信する場合、証明書を別のファイルにカット・アンド・ペーストする必要があります。

8. 新規ディジタル証明書の証明書ファイル名および位置を入力するか、「ブラウズ」をクリックして名前と位置を選択します。

9. 「OK」をクリックします。「ラベルの入力 (Enter a Label)」ウィンドウが表示されます。

10. 「Production Certificate for MyWeb at My Company」のように、新規ディジタル証明書用のラベルを入力し、「OK」をクリックします。「IBM 鍵管理(IBM Key Management)」ウィンドウが表示されます。「個人証明書(Personal Certificates)」フィールドに追加したディジタル証明書のラベルが表示されます。

ディジタル証明書の削除いずれかのディジタル証明書を必要としなくなった場合は、以下の手順に従い証明書をデータベースから削除します。

注: ディジタル証明書を削除する前に、後で証明書を再作成する場合のためにバックアップ・コピーを作成します。

鍵データベースからディジタル証明書を削除するには、以下の手順に従います。



3. ディジタル証明書を削除する鍵データベース・ファイルを選択して「オープン」をクリックします。「パスワード・プロンプト」ウィンドウが表示されます。




6. 削除するディジタル証明書を選択して「削除」をクリックします。「確認」ウィンドウが表示されます。

7. 「はい」をクリックします。「IBM 鍵管理 (IBM Key Management)」ウィンドウが表示されます。削除したディジタル証明書のラベルが「個人証明書(Personal Certificates)」フィールドに表示されなくなります。

新規デフォルト鍵の設定 (CMS のみ)SSL アプリケーションの設定を簡単に行うために、iKeyman ユーティリティーでは、鍵データベースに複数の個人証明書エントリーが含まれる場合に、アプリケーションが使用するデフォルトのディジタル証明書を指定します。選択した CA からの正式なディジタル証明書を待つ間に (テスト用に) アプリケーションで自己署名ディジタル証明書を使用して始めた場合、複数のディジタル証明書がデータベースに存在する可能性があります。

正式なディジタル証明書を CA から受信した後も、自己署名ディジタル証明書をデータベースに残し、CA が発行したディジタル証明書をデフォルトのディジタル証明書にして使用できます。デフォルトのディジタル証明書には、エントリー・ラベルの前にアスタリスク (*) が付いています。

注: 自己署名ディジタル証明書で実動アプリケーションをリリースしないでください。ブラウザーやクライアントからサーバーを認識したり通信することができません。

最初に受信したり自己署名として最初に作成したディジタル証明書は、デフォルトのディジタル証明書としてマークされます。新規ディジタル証明書を受信したり自己署名ディジタル証明書を作成すると、毎回そのディジタル証明書をデフォルトのディジタル証明書とするかどうかのオプションを選択できます。ただし、デフォルトのディジタル証明書を明示的に変更することは、いつでも可能です。

鍵データベース内のデフォルトのディジタル証明書を変更するには、次の手順に従います。



3. デフォルトのディジタル証明書を変更する鍵データベースを選択して、「オープン」をクリックします。「パスワード・プロンプト」ウィンドウが表示されます。


5. プルダウン・リストから「個人証明書 (Personal Certificates)」を選択します。デフォルトのディジタル証明書には、エントリー・ラベルの前にアスタリスク (*) が付いています。

6. デフォルトのディジタル証明書として設定するディジタル証明書を選択して「表示 / 編集 (View/Edit)」をクリックするか、エントリーをダブルクリックしま


す。ディジタル証明書エントリーの鍵情報ウィンドウが表示されます (図 8 を参照)。

7. このディジタル証明書をデフォルトのディジタル証明書として設定する場合、「この証明書をデフォルトとして設定 (Set the certificate as the default)」を選択して「OK」をクリックします。「IBM 鍵管理 (IBM KeyManagement)」ウィンドウが表示されます。デフォルトとして設定したディジタル証明書のラベルには、エントリーの前にアスタリスク (*) が付いていることで識別されます。

データベース・パスワードの変更iKeyman ツールを使用してデータベースのパスワードを変更できます。

鍵データベースのパスワードを変更するには、次の手順に従います。



3. パスワードを変更する鍵データベース・ファイルを選択して「オープン」をクリックします。「パスワード・プロンプト」ウィンドウが表示されます。


図 8. 鍵情報ウィンドウ


5. 「鍵データベース・ファイル (Key Database File)」 → 「パスワードの変更」をクリックします。「パスワードの変更」ウィンドウが表示されます。

6. 「パスワード」フィールドに新規パスワードを入力して、「確認パスワード」フィールドに再び入力します。

7. 「OK」をクリックします。ステータス・バーのメッセージで要求が正常に完了したことを確認できます。

スマート・カード上のディジタル証明書の管理iKeyman ユーティリティーを使用してスマート・カード上 (一般には、PKCS11 暗号トークン上) のディジタル証明書を管理できます。これを実行するために、スマート・カードを管理するモジュール名を iKeyman ユーティリティーに通知する方法が 2 つあります。

v プロパティー・ファイルから通知する方法

1. SSL ツールキットに同梱の (クラス・ディレクトリーにある)

「ikmuser.sample」ファイルを (クラス・ディレクトリーにある)

「ikmuser.properties」というファイルにコピーします。

2. 「ikmuser.properties」ファイルを編集して「DEFAULT_CRYPTOGRAPHIC_MODULE」プロパティーをスマート・カードを管理するモジュール名に設定します。次に例を示します。

DEFAULT_CRYPTOGRAPHIC_MODULE=C:¥¥Winnt¥¥System32¥¥W32pk2ig.dll

このモジュールは、通常スマート・カード用のソフトウェアをインストールするとシステムにインストールされます。上記の .dll は、ここで例として使用しているだけです。

3. 「ikmuser.properties」ファイルを保存します。

上記の構成ステップを 1 回だけ実行します。iKeyman ユーティリティーが開始すると、毎回「ikmuser.properties」ファイル内の内容を読み取ります。

v iKeyman GUI から通知する方法

また、iKeyman GUI から直接モジュール名を入力できます。

モジュール名が「ikmuser.properties」ファイルに設定されている場合、この名前はデフォルトとして常に GUI パネルに表示されます。優先モジュール名でない場合、この名前を変更できます。

注: IBM JSSE を使用する場合、JDK 環境の「java.security」ファイルを編集してIBM JCE を CMS より高い優先度に設定します。

スマート・カード上のディジタル証明書を管理するには、「鍵データベース・ファイル (Key Database File)」 → 「オープン」をクリックし、「CMS 暗号トークン(CMS Cryptographic Token)」を選択して、正しいモジュール名を使用していることを確認します。「オープン」ウィンドウが表示されます ( 26ページの図 9 参照)。


「OK」ボタンをクリックすると、表示されるメッセージに応じて、パスワード等の情報を入力する必要があります。CMS 暗号トークン・サポート用の「暗号トークンのオープン」ウィンドウの例が表示されます (図 10 参照)。

スマート・カードには容量が少ないものもあり、個人証明書の受信やインポートに必要な署名者証明書を保持できない場合があります。使用しているスマート・カードの容量が少ない場合、スマート・カードに加えて 2 次鍵データベースを開くことができます (CMS でのみサポート)。 2 次鍵データベースは、スマート・カードでの個人証明書の受信およびインポートに関連した署名者証明書のコンテナーとして機能します。スマート・カードに十分な容量がある場合、2 次鍵データベースを開く必要はありません。

スマート・カード用のディジタル証明書を要求するには、鍵データベースのディジタル証明書の要求の説明と同じ手順に従って、「鍵データベース (KeyDatabase)」 → 「オープン」をクリックして、鍵データベース・タイプの「CMS暗号トークン (CMS Cryptographic Token)」を選択します。スマート・カードのモジュール名とパスワードを指定した後、鍵データベースを開いた場合と同じ手順に従います。

CA から新規ディジタル証明書が送信されたら、要求を生成したスマート・カードに追加します。鍵データベースでのディジタル証明書の受信の説明と同じ手順に従って、「鍵データベース・ファイル (Key Database File)」 → 「オープン」をクリックし、鍵データベース・タイプの「CMS 暗号トークン」を選択し、モジュール名を指定して、「OK」をクリックします。この時点で、要求に関連した署名者証明書を保持するだけの容量がスマート・カードにない場合、2 次鍵データベースを開く

図 9. 「IBM 鍵管理 (IBM Key Management)」ウィンドウ内の暗号トークン

図 10. 「暗号トークンのオープン」ウィンドウ


必要があります。暗号トークンと (オプションで) 2 次鍵データベースを開いたら、鍵データベースを開いた場合と同じ手順に従います。

IBM JSSE を使用した暗号トークンのオープン前の節の画面ショットには、CMS を使用した暗号トークンを開いたときのダイアログが表示されています。IBM JSSE を使用して暗号トークンを開くには、次の手順に従います。

1. JDK 環境の「java.security」ファイルを編集して、IBM JCE を CMS より高い優先度に設定します。

2. 「鍵データベース・ファイル (Key Database File)」の次に「オープン」をクリックして、「Java Cryptographic Token」を選択し、正しいモジュール名を使用していることを確認します。「オープン」ウィンドウが表示されます (下の図12 を参照)。

3. 「OK」ボタンをクリックします。次の画面が表示されます。

4. スロット番号を入力して「OK」を押します。

5. 暗号トークン用のパスワード・ダイアログ・ボックスが表示されます。スマート・カードの PIN 番号を入力して「OK」をクリックします。

MS CryptoAPI を使用した暗号トークンのオープンMS CryptoAPI を使用して暗号トークンを開くには、次の手順に従います。

1. 「鍵データベース・ファイル (Key Database File)」をクリックして、「オープン」をクリックします。

2. 「CMS 暗号トークン (CMS Cryptographic Token)」を選択して、正しいモジュール名を使用していることを確認します。暗号サービス・プロバイダーを入力して「OK」をクリックします。

3. パスワードが表示されます。暗号トークンに使用するパスワードを入力します。

図 11. IBM JSSE を使用した鍵データベース・ファイルのオープン

図 12. 暗号トークンのスロット番号の選択


stash ファイルへの暗号化データベース・パスワードの保管安全なネットワーク接続のために、暗号化されたデータベース・パスワードを stash

ファイルに保管します。stash ファイルにパスワードを保管するには、次のようにします。


2. 「鍵データベース・ファイル (Key Database File)」 → 「Stash ファイル(Stash File)」を選択します。情報ダイアログが表示され、パスワードが隠されたこと、およびその場所が通知されます。「OK」をクリックします。


第 3 章 IKEYCMD コマンド行インターフェースの使用

IKEYCMD は、iKeyman に加えて、鍵、証明書、認証要求の管理に使用できるツールです。機能的には iKeyman と類似していますが、IKEYCMD ではコマンド行構文を使用し、グラフィカル・ユーザー・インターフェースは使用しません。IKEYCMD は、証明書と鍵管理タスクにカスタム・インターフェースの追加を行うアプリケーションのために、ネイティブ・シェル・スクリプトおよびプログラムから呼び出すことができます。そして、iKeyman が現在サポートしているすべてのタイプの鍵データベース・ファイルを作成できます。IKEYCMD を使用すれば、認証要求の作成、CA 署名証明書のインポート、および自己署名証明書の管理ができます。IKEYCMD は Java ベースで、SSL ツールキットがサポートするすべてのプラットフォームで使用できます。

IKEYCMD は、公開/秘密鍵の作成と管理に関連する構成タスクに使用します。ただし、サーバー構成ファイル httpd.conf を更新する構成オプションには IKEYCMD を使用できません。サーバー構成ファイルを更新するオプションには、IBM 管理サーバーを使用する必要があります。

IKEYCMD は Java およびネイティブ・コマンド行呼び出しを使用して、IKEYMAN

タスク・スクリプトを使用可能にします。

IKEYCMD コマンド行インターフェースの環境設定IKEYMAN は、gsk7cmd コマンド (適切なパラメーターを使用して Java を呼び出す UNIX スクリプトまたは Windows 実行可能ファイル) を使用して実行できます。または、Java を使用してクラスを直接実行することもできます。

IKEYMAN コマンド行インターフェースでは、gsk7cmd を使用する方法を推奨します。 gsk7cmd を使用して IKEYCMD を実行するには、以下の手順で環境変数を設定します。

1. Java または JRE 実行可能ファイルのロケーションへのパスを設定します。

UNIX export PATH=/opt/IBMJava/bin:/usr/local/ibm/gsk7/bin:$PATH

Windows「マイコンピュータ」を右クリックします。「プロパティ」を選択します。「詳細」タブをクリックします。「環境変数」ボタンをクリックします。「システム環境変数」セクションで次のエントリーを新規に作成します。

JAVA_HOME=C:¥Program Files¥IBM¥Java

次に既存の PATH エントリーを次のように変更します。

PATH=<existingentries>;C:¥Program Files¥IBM¥GSK7¥bin;C:¥ProgramFiles¥IBM¥Java¥bin;

ここまで完了したら、gsk7cmd をどのディレクトリーからも実行できます。gsk7cmd コマンドを実行するには、以下の構文を使用します。

gsk7cmd command


(command は必須のコマンド名です)。

2. クラスを直接指定して IKEYMAN を実行するには、以下のように環境変数を設定して IKEYCMD コマンド行インターフェースを使用します。

a. Java または JRE 実行可能ファイルのロケーションへのパスを設定します。

UNIX

export PATH=/opt/IBMJava/bin:$PATH

Windows「マイコンピュータ」を右クリックします。「プロパティ」を選択します。「詳細」タブをクリックします。「環境変数」ボタンをクリックします。「システム環境変数」セクションでエントリーを次のように編集します。

PATH=<existingentries>;C:¥Program Files¥IBM¥Java¥bin;C:¥ProgramFiles¥IBM¥GSK7¥bin;C:¥Program Files¥IBM¥GSK7¥lib;

b. 次の CLASSPATH 環境変数を設定します。

UNIX 1 行で入力します。

export CLASSPATH=/usr/local/ibm/gsk7/classes/cfwk.zip:/usr/local/ibm/gsk/classes/gsk7cls.jar:$CLASSPATH

注: UNIX によっては、さらに CLASSPATH 環境変数の設定が必要な場合があります。必要に応じて gsk7cmd スクリプトを参照して設定する環境変数を決定してください。

Windows「マイコンピュータ」を右クリックします。「プロパティ」を選択します。「詳細」タブをクリックします。「環境変数」ボタンをクリックします。「システム環境変数」セクションで次の新規変数を作成します (1 行で入力します)。

CLASSPATH=C:¥Program Files¥IBM¥GSK¥classes¥cfwk.zip;C:¥Program Files¥IBM¥GSK7¥classes¥gsk7cls.jar;<existingentries>

ここまで完了したら、IKEYCMD を任意のディレクトリーから実行できるようになります。 IKEYCMD コマンドを実行するには、以下の構文を使用します。

java com.ibm.gsk.ikeyman.Ikeycmd command

注:

1. JRE または JDK を使用しているかどうかによっては、Java を JRE に置換できます。たとえば、以下のようにします。

jre com.ibm.gsk.ikeyman.Ikeycmd <command>

2. インストール・ガイドでも説明されているように、IBM JDK 1.4.1 を使用し、IBM JDK ディレクトリー・ツリーから gskikm.jar を除去していない場合は、PATH または CLASSPATH の設定に関係なく、IBM JDK Ikeyman を使用します。これは、Ikeyman の別のバージョンが IBM JDK 1.4.1 にパッケージされているためです。

3. 上記の設定は、Java および SSL ツールキットの 32 ビット・バージョンを使用していることを想定しています。インストールすると、Ikeyman コマンド行インターフェースの 64 ビット・バージョンを gsk7cmd_64 で呼び出すことができますが、64 ビット・ライブラリーおよび実行可能ファイルへのパスを環境変数に含める必要があります。


IKEYCMD コマンド行構文Java CLI の構文は、以下のとおりです。

gsk7cmd [-Dikeycmd.properties=<properties_file>] <object> <action> [options]

コマンドの説明:

object 以下のいずれかです。

-keydb鍵データベース (CMS 鍵データベース・ファイル、WebDB 鍵リング・ファイル、または SSLight クラス) に対するアクション

-versionIKEYCMD のバージョン情報を表示します。

action オブジェクトに対する特定のアクション。options は、オプションで、必須、オプション、いずれの場合でも、object および action のペアに指定されます。オプションのすべてのセットについては、 45ページの『IKEYCMD

コマンド行オプションの概要』を参照してください。指定されているオブジェクトに許可されるアクションのすべてのセットについては、 44ページの『IKEYCMD コマンド行パラメーターの概要』を参照してください。

注: キーワード、「object」および「action」の位置は定位置であり、指定された順番でなければなりません。ただし、options に定位置はないため、オプションとオペランドのペアとして指定されている条件に一致すれば、順序は自由です。

-cert 証明書に対するアクション

-certreq認証要求に対するアクション

-Dikeycmd.propertiesこの Java の呼び出しに使用するオプションのプロパティー・ファイル名を指定します。デフォルトのプロパティー・ファイル ikeycmd.properties がサンプル・ファイルとして提供されます。このファイルは Java アプリケーションで変更し使用できます。

-help IKEYCMD 呼び出しのヘルプを表示します。

ユーザー・インターフェースのタスクの参照先以下のテーブルは、IKEYCMD コマンド行インターフェースのタスクを要約したものです。

IKEYMAN および IKEYCMD のタスク参照先

パスワードなしでの使用 32ページの『パスワードなしでの使用』

新規鍵データベースの作成とデータベース・パスワードの指定

33ページの『新規鍵データベースの作成』

鍵ペアと認証要求の新規作成 35ページの『新規の鍵ペアと認証要求の作成』

自己署名証明書の作成 35ページの『自己署名証明書の作成』

第 3 章 IKEYCMD コマンド行インターフェースの使用 31

IKEYMAN および IKEYCMD のタスク参照先

別のデータベースまたは PKCS12 ファイルへの鍵のエクスポート

36ページの『鍵のエクスポート』

別のデータベースまたは PKCS12 ファイルからの鍵のインポート

37ページの『鍵のインポート』

認証局 (CA) と認証要求のリスト 38ページの『CA のリスト作成』

鍵データベースのオープン 38ページの『鍵データベースのオープン』

鍵データベースへの CA 署名証明書の受信 38ページの『CA 署名証明書』

スマート・カードにおけるディジタル証明書の管理

41ページの『スマート・カードにおけるディジタル証明書の管理』

鍵データベースのデフォルト鍵の表示 39ページの『鍵データベース内のデフォルト鍵の表示』

証明書の詳細情報の表示 39ページの『証明書の詳細情報の表示』

CA のルート証明書の保管 40ページの『CA 証明書の保管』

stash ファイルへの暗号化データベース・パスワードの保管

28ページの『stash ファイルへの暗号化データベース・パスワードの保管』

パスワードなしでの使用Certificate Management System (CMS) の鍵データベースは、パスワードなしでも操作できます。つまり、 -pw パラメーターをオプションにすることができます。この情報は、-Dikeycmd.properties ファイルを使用して指定できます。パスワードなしで CMS 鍵データベースを作成する場合は、使用している ikeycmd.properties ファイルに DEFAULT_CMS_PASSWORD_REQUIRED=false を追加し、以下を 1 行で入力する必要があります。

gsk7cmd -Dikeycmd.properties=<properties file> -keydb-create -db <filename> -type cms -expire <days> -stash


-createデータベースを作成します。

-db <filename>

データベースの名前です。

-expire <days>

パスワードの期限切れまでの日数です。このパラメーターは、CMS 鍵データベースにのみ有効です。

-keydbコマンドが鍵データベース用であることを指定します。

<properties file>-pw パラメーターが必要な場合にその情報を入れます。CMS 鍵データベースでは、DEFAULT_CMS_PASSWORD_REQUIRED を使用します。

-stash 鍵データベースのパスワードを隠しておきます。鍵データベースの作成時に-stash オプションを指定すると、<filename of key database>.sth のようにパスワードとファイル名がファイルに隠しておかれます。


このパラメーターは、CMS 鍵データベースにのみ有効です。たとえば、作成中のデータベースの名前を keydb.kdb にすると、stash ファイル名は、keydb.sth となります。

注: IBM HTTP Server の場合、必ずパスワードを隠しておく必要があります。

-type cms「パスワードなし」での操作は CMS を使用した場合にのみサポートされます。

注: IBM HTTP Server では、CMS 鍵データベースのみが処理されます。

新規鍵データベースの作成鍵データベースとは、サーバーが 1 つ以上の鍵ペアおよび証明書を保管するために使用するファイルです。1 つの鍵データベースをすべての鍵ペアと証明書に使用することも、複数のデータベースを作成することもできます。

IKEYCMD コマンド行インターフェースを使用して新規の鍵データベースを作成するには、次のコマンドを 1 行で入力します。

gsk7cmd -keydb -create -db <filename> -pw <password> -type<cms | jks | jceks | pks12> -expire <days> -stash


-db <filename>


-expire <days>



-pw <password>鍵データベースにアクセスするためのパスワードです。

-type <cms | jks | jceks | pkcsk>データベース・タイプです。

注: IBM HTTP Server では、CMS 鍵データベースのみが処理されます。

-stash 鍵データベースのパスワードを隠しておきます。鍵データベースの作成時に-stash オプションを指定すると、<filename_of_key_database>.sth のようにパスワードとファイル名がファイルに隠しておかれます。

このパラメーターは、CMS 鍵データベースにのみ有効です。たとえば、作成中のデータベースの名前を keydb.kdb にすると、stash ファイル名は、keydb.sth となります。



データベース・パスワードの設定新規の鍵データベースを作成するときは、鍵データベースのパスワードを指定します。このパスワードによって秘密鍵が保護されます。秘密鍵とは、文書に署名したり、公開鍵で暗号化されたメッセージを暗号化解除できる唯一の鍵です。データベースのパスワードを頻繁に変更することをお勧めします。

パスワードは、以下のガイドラインに従って指定してください。

v パスワードには U.S. 英語の文字セットの文字を使用する。

v パスワードには、最小半角 6 文字以上使用し、その中に連続しない数字を最小 2

個使用する。パスワードは、ユーザーに関して一般的に入手可能な情報、たとえば、イニシャル、あるいはユーザー、ユーザーのパートナーまたは子供の誕生日などを使用していないことを確認してください。

v パスワードを隠しておく。

注: IBM HTTP Server の場合、パスワードの有効期限を把握しておいてください。パスワードの有効期限が切れると、エラー・ログにメッセージが書き込まれます。パスワードの有効期限が切れてもサーバーは起動しますが、ネットワーク接続の安全性は保障されません。

データベース・パスワードの変更データベース・パスワードを変更するには、以下を 1 行で入力します。

gsk7cmd -keydb -changepw -db <filename>.kdb -pw <password> -new_pw<new_password> -expire <days> -stash


-db <filename>


-changepwパスワードを変更します。


-new_pw <new_password>鍵データベースの新しいパスワードです。古いパスワードと同じパスワードは使用できません。また、NULL ストリングにもできません。


-expire <days>


-stash 鍵データベースのパスワードを隠しておきます。このパラメーターは、CMS

鍵データベースにのみ有効です。



新規の鍵ペアと認証要求の作成公開鍵と秘密鍵のペアおよび認証要求を作成するには、以下のように行います。

1. 次のコマンドを 1 行で入力します。

gsk7cmd -certreq -create -db <filename> -pw <password> -label <label>-dn <distinguished_name> -size <1024 | 512> -file <filename>


-certreq認証要求を指定します。

-create作成アクションを指定します。

-db <filename>


-pw <password>

鍵データベースにアクセスするためのパスワードです。

-label <label>

証明書または認証要求に付加されるラベルです。

-dn <distinguished_name>

X.500 識別名を入力します。この識別名は、次のように引用符付きストリングの形式で入力されます。この場合必ず指定する必要があるのは、CN、O、および C だけです (CN=一般名称、O=組織、OU=組織単位、L=住所、ST=州、地域、C=国)。例: "CN=weblinux.raleigh.ibm.com,O=ibm,OU=IBM HTTP

Server,L=RTP,ST=NC,C=US"

-size <1024 | 512>鍵のサイズ (512 または 1024) です。

-file <filename>

認証要求の保管先のファイル名です。

2. 証明書が正常に作成されたことを確認します。

a. 作成した認証要求ファイルの内容を表示します。

b. 鍵データベースに認証要求が記録されていることを確認します。

gsk7cmd -certreq -list -db <filename> -pw <password>

作成されたラベルのリストを確認する必要があります。

3. 新たに作成したファイルを認証局 (CA) に送信します。

自己署名証明書の作成既知の CA の場合、証明書が届くまでは通常 2、3 週間かかります。証明書が発行されるまでの間は、IKEYMAN によってサーバーの自己署名証明書を作成し、クライアントとサーバーとの間の SSL セッションを使用可能にします。専用の Web ネットワークで独自の CA として機能している場合は以下の手順を使用します。

自己署名証明書を作成するには、次のコマンドを 1 行で入力します。


gsk7cmd -cert -create -db <filename> -pw <password> -size <1024 | 512> -dn<distinguished name> -label <label> -default_cert <yes | no> -expire <days>


-cert 自己署名証明書を指定します。

-create作成アクションを指定します。

-db <filename>



-dn <distinguished name>

X.500 識別名を入力します。この識別名は、次のように引用符付きストリングの形式で入力されます。この場合必ず指定する必要があるのは、CN、O、および C だけです (CN=一般名称、O=組織、OU=組織単位、L=住所、ST=

州、地域、C=国)。例: "CN=weblinux.raleigh.ibm.com,O=ibm,OU=IBM HTTP

Server,L=RTP,ST=NC,C=US"

-label <label>

データベース内で鍵と証明書を識別するのに使用する記述コメントです。

-size 鍵のサイズ (512 または 1024) です。

-default_cert <yes | no>鍵データベース内でデフォルトの証明書かどうかです。

-expire <days>新規自己署名ディジタル証明書のデフォルトの有効期間は 365 日です。最短期間は 1 日です。最長期間は 7300 日 (20 年) です。

鍵のエクスポート鍵を別の鍵データベースまたは PKCS12 ファイルにエクスポートするには、次のコマンドを入力します。

gsk7cmd -cert -export -db <filename> -pw <password> -label <label>-type <cms | jks | jceks | pkcs12> -target <filename> -target_pw <password>-target_type <cms | jks | jceks | pkcs12>


-cert 個人証明書を指定します。

-exportエクスポート・アクションを指定します。

-db <filename>




-label <label>証明書に付加されたラベルです。

-target <filename>宛先ファイルまたは宛先データベースです。target_type が JKS、CMS、または JCEKS の場合は、ここで指定したデータベースが存在する必要があります。

-target_pw宛先の鍵データベースのパスワードです。

-target_type <cms | jks | jceks | pkcs12>-target オペランドで指定したデータベースのタイプです。

-type <cms | jks | jceks | pkcs12>データベースの鍵のタイプです。

鍵のインポート別の鍵データベースから証明書をインポートするには、次のコマンドを入力します。

gsk7cmd -cert -import -db <filename>-pw <password> -label <label> -type <cms | JKS | JCEKS | pkcs12>-target <filename> -target_pw <password> -target_type <cms | JKS | JCEKS | pkcs12>


-cert 証明書を指定します。

-importインポート・アクションを指定します。

-db <filename>


-pw <password>


-label <label>

証明書に付加されたラベルです。

-type <cms | JKS | JCEKS | pkcs12>データベースのタイプです。

-target <filename>

宛先データベースです。

-target_pw <password>

-target に鍵データベースを指定する場合の鍵データベースのパスワードです。

-target_type <cms | JKS | JCEKS | pkcs12>-target オペランドによって指定されたデータベースのタイプです。

PKCS12 ファイルの鍵をインポートするには、次のコマンドを入力します。


gsk7cmd -cert -import -file <filename> -pw <password> -type pkcs12 -target<filename> -target_pw <password> -target_type <cms | JKS | JCEKS | pkcs12>

CA のリスト作成鍵データベースのトラステッド CA のリストを表示するには、次のコマンドを 1

行で入力します。

gsk7cmd -cert -list CA -db <dbname> -pw <password>-type <cms | jks | jceks | pkcs12>

鍵データベースのオープン鍵データベースの明示的なオープンはありません。各コマンドごとに、データベースとパスワードのオプションが指定されます。また、こうした指定によって鍵データベースでの操作に必要な情報が提供されます。

CA 署名証明書このプロシージャーは、サーバー上でトラステッド CA とされる認証局 (CA) から電子的にメールされた証明書の受信に使用します。デフォルトでは、以下の CA 証明書が鍵データベースに保管され、トラステッド CA 証明書としてマークされています。

v Verisign Class 2 OnSite Individual CA

v Verisign International Server CA — Class 3

v VeriSign Class 1 Public Primary CA — G2






v RSA Secure Server CA (from RSA)

v Thawte Personal Basic CA

v Thawte Personal Freemail CA

v Thawte Personal Premium CA

v Thawte Premium Server CA

v Thawte Server CA

認証局 (CA) から複数の証明書が送信されることがあります。サーバー用の証明書のほかに、追加の署名証明書または中間 CA 証明書が CA から送信される場合もあります。たとえば、Global Server ID 証明書の送信時に Verisign には、中間 CA 証明書が一緒に送られます。サーバーの証明書を受信する前に、追加の中間 CA 証明書を受信してください。中間 CA 証明書の受信方法については、 40ページの『CA

証明書の保管』の手順に従います。

注: CA 署名証明書を発行した CA が鍵データベースのトラステッド CA ではない場合、まず、その CA 証明書を保管し、その CA をトラステッド CA として


指定する必要があります。これで、CA 署名証明書をデータベースに受信できます。トラステッド CA でない CA から CA 署名証明書を受信することはできません。詳しくは、 40ページの『CA 証明書の保管』を参照してください。

鍵データベースに CA 署名証明書を受信するには、次のコマンドを 1 行で入力します。

gsk7cmd -cert -receive -file <filename> -db <filename> -pw <password>-format <ascii | binary> -label <label> -default_cert <yes | no>


-cert 自己署名証明書を指定します。

-receive受信アクションを指定します。

-file <filename>

CA 証明書を含むファイルです。

-db <filename>


-pw <password>


-format <ascii | binary>認証局 (CA) から提供される CA 証明書の形式 (ASCII またはバイナリー)

です。

-default_cert <yes | no>鍵データベース内でデフォルトの証明書かどうかです。

-label <label>

CA 証明書に付加されたラベルです。

-trust この CA をトラステッド CA にできるかどうかを指定します。CA 証明書の受信時に enable オプションを使用します。

鍵データベース内のデフォルト鍵の表示デフォルト鍵のエントリーを表示するには、次のコマンドを入力します。

gsk7cmd -cert -getdefault -db <dbname> -pw <password>

証明書の詳細情報の表示鍵の詳細情報を表示するには、次のコマンドを 1 行で入力します。

gsk7cmd -cert -details -showOID -db <filename> -pw <password> -label <label>


-cert この操作が証明書に適用されることを示します。

-details鍵についての詳細なエントリーを表示します。

-showOID証明書または認証要求に関する詳細情報を表示します。


-db <filename>


-pw <password>


-label <label>

証明書または認証要求に付加されたラベルです。

CA 証明書の保管トラステッド CA でない CA からの証明書を保管するには、以下のようにします。

gsk7cmd -cert -add -db <filename>.kdb -pw <password>-label <label> -format <ascii | binary> -trust <enable |disable>-file <filename>


-add 追加アクションを指定します。


-db <filename>


-file <filename>

CA 証明書を含むファイルです。

-format <ascii | binary>認証局 (CA) からバイナリーまたは ASCII ファイルが提供されます。

-label <label>

証明書または認証要求に付加されるラベルです。


-trust <enable | disable>この CA を信頼できるかどうかを指示します。はいである必要があります。

stash ファイルへの暗号化データベース・パスワードの保管セキュア・ネットワーク接続の場合、CMS 暗号化データベースのパスワードはstash ファイルに保管されます。CMS データベースの作成時にパスワードを保管するには、次のコマンドを入力します。

gsk7cmd -keydb -create -db <path_to_db>/<db_name> -pw <password> -type cms-expire <days> -stash

CMS データベースの作成後にパスワードを保管するには、次のコマンドを入力します。

gsk7cmd -keydb -stashpw -db <db_name> -pw <password>


スマート・カードにおけるディジタル証明書の管理iKeyman CLI では、スマート・カード (一般的には PKCS11 暗号化デバイス) においてディジタル証明書をユーザーが管理できます。CMS、IBM JSSE、またはMicrosoft CryptoAPI のいずれかでディジタル証明書を管理するためには、以下のステップに従って、使用するスマート・カードの管理用のモジュール名を iKeyman

CLI に通知する必要があります。

1. $JAVA_HOME/jre/lib/security/ ディレクトリーに保管されている次のいずれかの設定を使用して、JDK 環境の java.security ファイルを編集します。

v security.provider.1=sun.security.provider.Sun — versions greater than JDK 1.3.1

v security.provider.2=com.ibm.spi.IBMCMSProvider

v security.provider.3=com.ibm.crypto.provider.IBMJCE

2. ikeycmd.properties ファイルを編集して、DEFAULT_CRYPTOGRAPHIC_MODULE プロパティーをスマート・カードを管理するためのモジュール名に設定します。次に例を示します。


このモジュールは、通常スマート・カード用のソフトウェアをインストールするとシステムにインストールされます。上記の .dll は、ここでは例示のためにのみに使用されており、実際のシステムでは異なる場合があります。

3. ikeycmd.properties ファイルを保管します。

4. PKCS11 関連の操作には、次のコマンドを使用します。

-crypto <module_name> -tokenlabel <token_label> -pw <password>

たとえば、PKCS11 暗号化デバイスに含まれる証明書を表示するには、次のように入力します。

gsk7cmd -Dikeycmd.properties=<propertiesfile> -cert -list all -crypto <module_name>-tokenlabel <token_label> -pw <password>



-crypto <module_name>PKCS11 暗号化デバイスの使用を指定します。ここで <module_name> は、スマート・カードを管理するモジュールの名前です。ikmcmd.properties ファイルで指定されている場合はオプションです。

-list all証明書を表示します。

-pw <password>この PKCS11 暗号化デバイスのパスワードです。

-tokenlabel <token_label>

PKCS11 暗号化デバイスのトークン・ラベルです。

IBM JSSE インプリメンテーションを使用して暗号化ハードウェア・デバイスをオープンする場合は、次のようにします。

1. $JAVA_HOME/jre/lib/security/ ディレクトリーに保管されている次のいずれかの設定を使用して、JDK 環境の java.security ファイルを編集します。


v security.provider.1=sun.security.provider.Sun — JDK 1.3.1 only



つまり、IBM JCE の優先順位を java.security ファイルの CMS よりも高く設定します。

2. ikeycmd.properties ファイルを編集して、DEFAULT_CRYPTOGRAPHIC_MODULE プロパティーをスマート・カードを管理するためのモジュール名に設定します。次に例を示します。


このモジュールは、通常スマート・カード用のソフトウェアをインストールするとシステムにインストールされます。上記の .dll は、ここでは例示のためにのみに使用されており、実際のシステムでは異なる場合があります。


4. PKCS11 関連の操作には、次のコマンドを使用します。

-crypto <module_name> -relativeSlotNumber <slot_number> -pw <password>

たとえば、PKCS11 暗号化デバイスに含まれる証明書を表示するには、次のように入力します。

gsk7cmd -Dikeycmd.properties=<propertiesfile> -cert -list all -crypto <module_name>-relativeSlotNumber <slot_number> -pw <password>

ここで、


-crypto <module_name>PKCS11 暗号化デバイスの使用を指定します。ここで <module_name> は、スマート・カードを管理するモジュールの名前です。ikmcmd.properties ファイルで指定されている場合はオプションです。


-pw <password>この PKCS11 暗号化デバイスのパスワードです。

-relativeSlotNumber <slot_number>PKCS11 暗号化デバイスの相対スロット番号です。

MS CryptoAPI を使用して暗号化ハードウェア・デバイスをオープンする場合は、次のようにします。

1. ikeycmd.properties ファイルを編集します。暗号化サービス・プロバイダー(CSP) 名を DEFAULT_CRYPTOGRAPHIC_MODULE プロパティーに設定します。次に例を示します。

DEFAULT_CRYPTOGRAPHIC_MODULE=Schlumberger Cryptographic Service Provider

通常、CSP はスマート・カードのソフトウェアをインストールしたシステムにインストールされます。



3. 暗号化デバイスに含まれる証明書を表示するには、次のように入力します。

gsk7cmd -Dikeycmd.properties=<propertiesfile> -cert -list all-crypto <CSP_module_name



-crypto <CSP_module_name>暗号化サービス・プロバイダー (CSP) の名前を指定します。


Microsoft 証明書ストアの管理iKeyman CLI では、Microsoft 証明書ストア (Windows 2000 Service Pack 2 以降でのみサポート) を管理できます。 Microsoft 証明書ストアで処理するには、-dbMSCertificateStore を使用します。-db MSCertificateStore に関連した操作では、パスワード (-pw) は必要ありません。

たとえば、Microsoft 証明書ストアに保管されている証明書の詳細を表示するには、次のコマンドを 1 行で入力します。

gsk7cmd -cert -details -db MSCertificateStore -label <label>


-cert 証明書情報を指定します。

-details詳細モードを指定します。

-db MSCertificateStoreMicrosoft 証明書ストアを指定します。

-label <label>

操作で使用される証明書のラベルです。

Java 鍵ストアの管理iKeyman CLI では、java.security レジストリーに登録されている多数の鍵ストア・プロバイダーをサポートしています。たとえば、java.security レジストリーに以下が設定されている場合、JKS、JCEKS、PKCS12、および CMS を使用できるようになります。

v security.provider.1=sun.security.provider.Sun — versions greater than JDK 1.3.1



注: 次の機能は CMS 鍵ストアでのみ有効です。

表 1. CMS 鍵ストアの機能

機能キーワード

鍵データベースのパスワードをファイルに隠しておく

-keydb -stashpw-stash


表 1. CMS 鍵ストアの機能 (続き)

機能キーワード

デフォルトの個人証明書の設定/取得

-cert -setdefault-cert -getdefaultdefault_cert <no | yes>

トラステッド証明書の設定 -cert -modify-trust <enable | disable>

パスワードの有効期限の設定 -expire <days>

パスワードなしでの使用 -pw <password>

IKEYCMD コマンド行パラメーターの概要次のテーブルで、指定したオブジェクト上で実行可能な各アクションを説明します。

オブジェクトアクション説明

-keydb -changepw 鍵データベースのパスワードを変更します。

-convert 鍵データベースの形式を別の形式に変換します。

-create 鍵データベースを作成します。

-delete 鍵データベースを削除します。

-stashpw 鍵データベースのパスワードをファイルに隠しておきます。

-cert -add CA 証明書をファイルから鍵データベースに追加します。

-create 自己署名証明書を作成します。

-delete CA 証明書を削除します。

-details 特定の証明書の詳細情報をリストします。

-export 個人証明書とそれに関連した秘密鍵を鍵データベースから PKCS#12 ファイルまたは別の鍵データベースにエクスポートします。

-extract 証明書を鍵データベースから抽出します。

-getdefault デフォルトの個人証明書を取得します。

-import 鍵データベースまたは PKCS#12 ファイルから証明書をインポートします。

-list すべての証明書をリストします。

-modify 証明書を変更します (注: 現在変更可能なフィールドは、「証明書の信頼 (Certificate Trust)」フィールドだけです)。

-receive ファイル内の証明書を鍵データベースで受信します。

-setdefault デフォルトの個人証明書を設定します。

-sign ファイルに保管されている証明書に、鍵データベースに保管されている証明書とともに署名し、署名した証明書をファイルに保管します。


オブジェクトアクション説明

-certreg -create 認証要求を作成します。

-delete 認証要求データベースから認証要求を削除します。

-details 特定の認証要求の詳細情報をリストします。

-extract 認証要求データベースの認証要求をファイルに抽出します。

-list 認証要求データベースのすべての認証要求をリストします。

-recreate 認証要求を再作成します。

-crypto PKCS11 暗号化デバイスの操作を指示します。プロパティー・ファイルで指定されている場合、-crypto の後の値はオプションです。

-tokenlabel PKCS11 暗号化デバイスのラベル。

-secondaryDB PKCS11 デバイスの操作をサポートする 2 次鍵データベース。

-secondaryDBpw PKCS11 デバイスの操作をサポートする 2 次鍵データベースのパスワード。

-showOID 証明書または認証要求の詳細情報を表示します。

-help IKEYCMD コマンドのヘルプ情報を表示します。

-version IKEYCMD のバージョン情報を表示します。

IKEYCMD コマンド行オプションの概要以下のテーブルでは、コマンド行に使用できる各オプションについて説明します。オプションは完全なグループとしてリストされています。ただし、使用方法はコマンド行で指定されている object (オブジェクト) および action (アクション) によって異なります。

オプション説明

-db 鍵データベースの完全修飾パスです。

-default_cert クライアント認証のデフォルトとして使用する証明書を yes または no

で指定します。デフォルトは「no」です。

-dn X.500 識別名です。この識別名は、次のように引用符付きストリングの形式で入力します。この場合必ず指定する必要があるのは、CN、O、および C だけです ("CN=Jane Doe,O=IBM,OU=Java

Development,L=Endicott, ST=NY,ZIP=13760,C=country")。

-encryption 証明書エクスポート・コマンドで使用される暗号化の強さを strong または weak で指定します。デフォルトは strong です。

-expire 証明書またはデータベース・パスワードの有効期限を日数で示します。デフォルトは、証明書の場合 365 日間で、データベース・パスワードは 60 日間です。期間には、0 から 7300 (20 年間) までを指定できます。


オプション説明

-file 証明書または認証要求のファイル名です。指定されている object (オブジェクト) によって異なります。

-format 証明書の形式です (Base64_encoded ASCII の場合は、ascii、Binary

DER データの場合は binary)。デフォルトは、ascii です。

-label 証明書または認証要求に付加されたラベルです。

-new_format 鍵データベースの新しい形式です。

-new_pw データベースの新規パスワードです。

-old_format 鍵データベースの古い形式です。

-pw 鍵データベースまたは PKCS#12 ファイルのパスワードです。 33ページの『新規鍵データベースの作成』を参照してください。

-size 鍵のサイズ (512 または 1024) です。デフォルトは 1024 です。

-stash 鍵データベースのパスワードをファイルに隠しておくためのインジケーターです。指定すると、パスワードはファイルに隠しておかれます。

-target 宛先ファイルまたは宛先データベースです。

-target_pw -target に鍵データベースを指定する場合の鍵データベースのパスワードです。 33ページの『新規鍵データベースの作成』を参照してください。

-target_type -target オペランドによって指定されているデータベースのタイプです(-type を参照)。

-trust CA 証明書の信頼状況を enable または disable で指定します。デフォルトは enable です。

-type データベースのタイプです。指定できるタイプは以下のとおりです。

v cms (CMS 鍵データベースを示す)

v jce (Sun 所有の Java Cryptography Extension を示す)

v jceks (Sun 所有の Java Cryptography Extension 鍵ストアを示す)

v pkcs12 (PKCS#12 ファイルを示す)

-x509version 作成する X.509 証明書のバージョン (1、2、または 3)。デフォルトは、3 です。

CMS 鍵データベースのコマンド行呼び出し以下は、各コマンド行呼び出しと、オプションのパラメーター (イタリックで表記)

のリストです。すべてのコマンドは、1 行で入力されます。

注: 簡単にするために、実際の Java 呼び出し gsk7cmd は、各コマンドの呼び出しから省略しています。

-keydb -changepw -db <filename> -pw <password> -new_pw <new_password>-stash -expire <days>

-keydb -create -db <filename> -pw <password> -type <cms>-expire <days> -stash

-keydb -stashpw -db <filename> -pw <password>

-cert -getdefault -db <filename> -pw <password>

-cert -modify -db <filename> -pw <password> -label <label>-trust <enable | disable>

-cert -setdefault -db <filename> -pw <password> -label <label>


暗号化コマンド行の呼び出し (CMS インプリメンテーション)以下は、各コマンド行呼び出しと、オプションのパラメーター (イタリックで表記)



-keydb -changepw -crypto <module_name>-tokenlabel <token_label> -pw <password> -new_pw <new_password>

-cert -add -crypto <module_name> -tokenlabel <token_label> -pw <password>-label <label> -file <filename> -format <ascii | binary>

-cert -create -crypto <module_name> -tokenlabel <token_label> -pw <password>-label <label> -dn <distinguished_name> -size <1024 | 512>-x509version <3 | 1 | 2> -default_cert <no | yes> -expire <days>

-cert -delete -crypto <module_name> -tokenlabel <token_label> -pw <password>-label <label>

-cert -details -crypto <module_name> -tokenlabel <token_label>-pw <password> -label <label>

-cert -details -showOID -crypto <module_name> -tokenlabel <token_label>-pw <password> -label <label>

-cert -extract -crypto <module_name> -tokenlabel <token_label> -pw <password>-label <label> -target <filename> -format <ascii | binary>

次のコマンドでは、2 次鍵データベース・サポートを使用して暗号化デバイスに証明書をインポートします。

-cert -import -db <filename> -pw <password> -label <label>-type <cms> -crypto <module_name> -tokenlabel <token_label>-pw <password> -secondaryDB <filename> -secondaryDBpw <password>

次のコマンドでは、2 次鍵データベース・サポートを使用して暗号化デバイスにPKCS12 証明書をインポートします。

-cert -import -file <filename> -pw <password>-type <pkcs12> -crypto <module_name> -tokenlabel <token_label>-pw <password> -secondaryDB <filename> -secondaryDBpw <password>

-cert -list <all | personal | CA> -crypto <module_name>-tokenlabel <token_label> -pw <password>

-cert -receive -file <filename> -crypto <module_name> -tokenlabel <token_label>-pw <password> -secondaryDB <filename> -secondaryDBpw <password>-format <ascii | binary>

-certreq -create -crypto <module_name> -tokenlabel <token_label>-pw <password> -label <label> -dn <distinguished_name>-size <1024 | 512> -file <filename>

-certreq -delete -crypto <module_name> -tokenlabel <token_label>-pw <password> -label <label>

-certreq -details -crypto <module_name> -tokenlabel <token_label>-pw <password> -label <label>

-certreq -details -showOID -crypto <module_name> -tokenlabel <token_label>-pw <password> -label <label>

-certreq -extract -crypto <module_name> -tokenlabel <token_label>-pw <password> -label <label> -target <filename>

-certreq -list -crypto <module_name> -tokenlabel <token_label>-pw <password>


暗号化コマンド行の呼び出し (IBM JSSE インプリメンテーション)以下は、各コマンド行呼び出しと、オプションのパラメーター (イタリックで表記)



-keydb -list

-cert -add -crypto <module_name> -relativeSlotNumber <slot_number>-pw <password> -label <label> -file <filename> -format <ascii | binary>

-cert -create -crypto <module_name> -relativeSlotNumber <slot_number>-pw <password> -label <label> -dn <distinguished_name>-size <1024 | 512> -x509version <3 | 1 | 2>

-cert -delete -crypto <module_name> -relativeSlotNumber <slot_number>-pw <password> -label <label>

-cert -details -crypto <module_name> -relativeSlotNumber <slot_number>-pw <password> -label <label>

-cert -details -showOID -crypto <module_name> -relativeSlotNumber <slot_number>-pw <password> -label <label>

-cert -extract -crypto <module_name> -relativeSlotNumber <slot_number>-pw <password> -label <label> -target <filename>-format <ascii | binary>

-cert -import -db <filename> -pw <password> -label <label>-type <pkcs12 | cms | JKS | JCEKS> -crypto <module_name>-relativeSlotNumber <slot_number> -pw <password>

-cert -list <all | personal | CA> -crypto <module_name>-relativeSlotNumber <slot_number> -pw <password>

-cert -receive -file <filename> -crypto <module_name>-relativeSlotNumber <slot_number> -pw <password>-format <ascii | binary>

-certreq -create -crypto <module_name> -relativeSlotNumber <slot_number>-pw <password> -label <label> -dn <distinguished_name>-size <1024 | 512> -file <filename>

-certreq -delete -crypto <module_name> -relativeSlotNumber <slot_number>-pw <password> -label <label>

-certreq -details -crypto <module_name> -relativeSlotNumber <slot_number>-pw <password> -label <label>

-certreq -details -showOID -crypto <module_name> -relativeSlotNumber <slot_number>-pw <password> -label <label>

-certreq -list -crypto <module_name> -relativeSlotNumber <slot_number>-pw <password>

PKCS11 暗号化コマンド行の呼び出し (Microsoft CryptoAPI インプリメンテーション)

以下は、各コマンド行呼び出しと、オプションのパラメーター (イタリックで表記)



-cert -add -crypto <CSP_module_name> -label <label>-file <filename> -format <ascii | binary>


-cert -create -crypto <CSP_module_name>-label <label> -dn <distinguished_name> -size <1024 | 512>-x509version <3 | 1 | 2> -expire <days>

-cert -delete -crypto <CSP_module_name> -label <label>

-cert -details -crypto <CSP_module_name> -label <label>

-cert -details -showOID -crypto <CSP_module_name> -label <label>

-cert -extract -crypto <CSP_module_name> -label <label>-target <filename> -format <ascii | binary>

注: 次のコマンドでは、PKCS12 鍵データベースの -label は必要ありません。

-cert -import -db <filename> -pw <password> -label <label>-type <pkcs12 | cms | JKS | JCEKS> -crypto <CSP_module_name>

-cert -list <all | personal | CA> -crypto <CSP_module_name>

Microsoft 証明書ストアのコマンド行呼び出し以下は、各コマンド行呼び出しと、オプションのパラメーター (イタリックで表記)



-cert -add -db MSCertificateStore -label <label> -file <filename>-format <ascii | binary>

-cert -create -db MSCertificateStore -label <label> -dn <distinguished_name>-size <1024 | 512> -x509version <3 | 1 | 2> -expire <days>

-cert -delete -db MSCertificateStore -label <label>

-cert -details -db MSCertificateStore -label <label>

-cert -details -showOID -db MSCertificateStore -label <label>

-cert -export -db MSCertificateStore -label <label>-target <filename> -target_pw <password> -target_type <cms | jks | jceks | pkcs12>

-cert -extract -db MSCertificateStore -label <label>-target <filename> -format <ascii | binary>

-cert -import -db <filename> -pw <password> -label <label>-type <cms | JKS | JCEKS> -target MSCertificateStore

-cert -import -file <filename> -pw <password>-type <pkcs12> -target MSCertificateStore

-cert -list <all | personal | CA> -db MSCertificateStore

鍵ストアのすべてのタイプ (CMS、JKS、JCEKS、PKCS12) のコマンド行呼び出し

以下は、各コマンド行呼び出しと、オプションのパラメーター (イタリックで表記)



-keydb -changepw -db <filename> -pw <password> -newpw <new_password>

注: 次は、CMS 鍵データベースでのみ有効です。


-keydb -changepw -db <filename> -pw <password> -newpw<new_password> -expire <days>

-keydb -convert -db <filename> -pw <password>-old_format <cms | JKS | JCEKS | pkcs12> -new_format <cms | JKS | JCEKS | pkcs12>

-keydb -create -db <filename> -pw <password> -type <cms | JKS | JCEKS | pkcs12>

-keydb -delete -db <filename> -pw <password>

-cert -add -db <filename> -pw <password> -label <label>-file <filename> -format <ascii | binary>

-cert -create -db <filename> -pw <password> -label <label>-dn <distinguished_name> -size <1024 | 512> -x509version <3 | 1 | 2>-expire <days>

-cert -delete -db <filename> -pw <password> -label <label>

-cert -details -db <filename> -pw <password> -label <label>

-cert -export -db <filename> -pw <password> -label <label>-type <cms | JKS | JCEKS | pkcs12> -target <filename>-target_pw <password> -target_type <cms | JKS | JCEKS | pkcs12>

-cert -extract -db <filename> -pw <password> -label <label>-target <filename> -format <ascii | binary>

-cert -import -db <filename> -pw <password> -label <label>-type <cms | JKS | JCEKS> -target <filename> -target_pw <password>-target_type <cms | JKS | JCEKS | pkcs12>

-cert -import -file <filename> -pw <password>-type <pkcs12> -target <filename> -target_pw <password>

-cert -list <all | personal | CA> -db <filename>-pw <password> -type <cms | JKS | JCEKS | pkcs12>

-cert -receive -file <filename> -db <filename>-pw <password> -format <ascii | binary>

-certreq -create -db <filename> -pw <password>-label <label> -dn <distinguished_name> -size <1024 | 512> -file <filename>

-certreq -delete -db <filename> -pw <password> -label <label>

-certreq -details -db <filename> -pw <password> -label <label>

-certreq -extract -db <filename>-pw <password> -label <label> -target <filename>

-certreq -list -db <filename> -pw <password>

-certreq -recreate -db <filename>-pw <password> -label <label> -target <filename>

ユーザー・プロパティー・ファイルJava CLI 呼び出しに必要な入力の一部を省略するために、プロパティー・ファイルにユーザー・プロパティーを指定できます。プロパティー・ファイルは、Java オプション -Dikeycmd.properties を使用して Java コマンド行呼び出しで指定できます。Java アプリケーションがアプリケーションのデフォルトの設定を変更できるようにサンプルのプロパティー・ファイル ikeycmd.properties が提供されています。


第 4 章アクセシビリティーに関する GSKit iKeyman のサポート

身体に障害を持つ方が IBM 製品を利用できるようにするために、IBM の製品には重要なアクセシビリティー機能が搭載されています。これらの機能は直接利用できるか、支援テクノロジーと互換性があります。 IBM アクセシビリティー・センターおよび Sun Microsystem のアクセシビリティー・グループは、協力して次世代のアクセシビリティー機能を設計して Java アプリケーションに組み込みました。http://www-3.ibm.com/able/accessjava.html のチェックリストに従って Java2 アプリケーションを利用できるにようにしてください。iKeyman は、現在アクセシビリティー・サポート・イニシアチブに準拠する製品の 1 つです。

注: 現在の Java アクセシビリティー・サポートは、Windows プラットフォーム上でのみ完全に機能します。

次のような機能があります。

v 使いやすさに関するアクセシビリティー・サポート

ユーザーは、以下のようにキーボードだけで iKeyman を操作できます。

[Tab] 前方に移動キー

[Shift]+[Tab]後方に移動キー

[Space]アクションのトリガー・キー

[上矢印]選択可能項目を上に動かすキー

[下矢印]選択可能項目を下に動かすキー

v 表示効果のアクセシビリティー・サポート

1. 色およびフォントについてプラットフォームの設定を変更します。たとえば、Windows プラットフォームでは、システムの色とフォントの設定を「コントロールパネル」の「画面」のプロパティーで変更します。

2. アクセシビリティー・サポートを使用可能にします。「ビュー (View)」 →

「Windows ルック・アンド・フィール (Windows Look and Feel)」を選択します。iKeyman の表示に現在の色とフォントが適用されます。



付録. 特記事項

本書は米国 IBM が提供する製品およびサービスについて作成したものであり、本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBM

の営業担当員にお尋ねください。本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、またはサービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の製品、プログラム、またはサービスを使用することができます。ただし、IBM 以外の製品とプログラムの操作またはサービスの評価および検証は、お客様の責任で行っていただきます。

IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について実施権を許諾することを意味するものではありません。実施権についてのお問い合わせは、書面にて下記宛先にお送りください。

〒106-0032東京都港区六本木 3-2-31IBM World Trade Asia CorporationLicensing

以下の保証は、国または地域の法律に沿わない場合は、適用されません。 IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。国または地域によっては、法律の強行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。

この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、改良または変更を行うことがあります。

本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものではありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部ではありません。それらの Web サイトは、お客様の責任でご使用ください。

IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信ずる方法で、使用もしくは配布することができるものとします。

本プログラムのライセンス保持者で、(i) 独自に作成したプログラムとその他のプログラム（本プログラムを含む）との間での情報交換、および (ii) 交換された情報の相互利用を可能にすることを目的として、本プログラムに関する情報を必要とする方は、下記に連絡してください。


IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758U.S.A.

本プログラムに関する上記の情報は、適切な使用条件の下で使用することができますが、有償の場合もあります。

本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、IBM より提供されます。

この文書に含まれるいかなるパフォーマンス・データも、管理環境下で決定されたものです。そのため、他の操作環境で得られた結果は、異なる可能性があります。一部の測定が、開発レベルのシステムで行われた可能性がありますが、その測定値が、一般に利用可能なシステムのものと同じである保証はありません。さらに、一部の測定値が、推定値である可能性があります。実際の結果は、異なる可能性があります。お客様は、お客様の特定の環境に適したデータを確かめる必要があります。

IBM 以外の製品に関する情報は、その製品の供給者、出版物、もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、他社製品に関する実行性、互換性、またはその他の要求については確証できません。IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。

IBM の将来の方向または意向に関する記述については、予告なしに変更または撤回される場合があり、単に目標を示しているものです。

本書はプランニング目的としてのみ記述されています。記述内容は製品が使用可能になる前に変更になる場合があります。

本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名前が含まれている場合があります。これらの名称はすべて架空のものであり、名称や住所が類似する企業が実在しているとしても、それは偶然にすぎません。

この情報をソフトコピーでご覧になっている場合は、写真やカラーの図表は表示されない場合があります。

商標以下は、IBM Corporation の商標です。

AIX

DB2IBM

IBM (ロゴ)

OS/390

SecureWay


Tivoli

Tivoli (ロゴ)

Universal Database

WebSpherez/OS

zSeries

Microsoft および Windows は、Microsoft Corporation の米国およびその他の国における商標です。

UNIX は、The Open Group の米国およびその他の国における登録商標です。

他の会社名、製品名およびサービス名などはそれぞれ各社の商標または登録商標です。

付録. 特記事項 55


索引日本語, 数字, 英字, 特殊文字の順に配列されています。なお, 濁音と半濁音は清音と同等に扱われています。

［ア行］アクション・リスト、IKEYCMD 44

アクセシビリティー色、フォント設定 51

キーボード操作 51

定義 51

プラットフォームの制限 51

暗号化 1

コマンド呼び出し、リスト作成 47

暗号化データベースのパスワード 40

暗号方式公開鍵 1

説明 1

非対称 1

オプション・リスト、IKEYCMD 45

［カ行］鍵インポート 37

エクスポート 36

デフォルト・エントリーの表示 39

ペア 1

鍵格納ファイル 8

鍵データベース作成 12, 33

パスワード 34

鍵データベース・ファイルの作成 12

鍵ペア作成 35

仮想プライベート・ネットワーク(VPN) 5

クライアント認証 5, 9

グローバル・サーバー証明書SSL に備わる 9

公開鍵 1

公開鍵、所有者の 2

公開鍵暗号方式 1

公開鍵と秘密鍵のペア 1, 3

コマンド・リスト作成、暗号 47

コマンド・リスト作成、IKEYCMD 46

［サ行］識別名所有者の 2

発行者の 2

自己署名ディジタル証明書作成 14, 35

説明 4

内容 6

自己署名ディジタル証明書の作成 14

証明書受信 38

トラステッドでない CA の保管 40

要求の作成 35

CA 署名 39

署名者ディジタル証明書、リスト 13

署名済みディジタル証明書 6

所有者の公開鍵 2

所有者の識別名 2

新規デフォルト鍵の設定 23

ステップアップ・プロトコル 9

セキュア電子メール 5

セキュア・トンネル 5

セキュリティー上の考慮事項 3

［タ行］データベース鍵データベース・ファイルの作成 12

パスワードの変更 24

データベース・パスワードの変更 24

ディジタル証明書概要 1

形式 2

削除 22

自己署名 4, 6, 14

受信 21

使用 4

署名者 13

署名済みの 6


セキュリティー上の考慮事項 3

抽出 17

認証局 (CA) 2, 3

目的 2

有効期限 2

要求 6, 20

ルート CA の削除 16

ルート CA の追加 15

レイアウト 2

RSA Secure Server CA 13

ディジタル証明書 (続き)

SSL および trust チェーン 8

Thawte Personal Basic CA 13

Thawte Personal Freemail CA 13

Thawte Personal Premium CA 13

Thawte Premium Server CA 13

Thawte Server CA 13

VeriSign Class 1 Public Primary

CA 13


Certification Authority — G2 13

VeriSign Class 2 Onsite Individual

Certification Authority 14


CA 13




CA 13

VeriSign Class 3Public Primary


VeriSign International Server

Certification Authority — class 3 14

ディジタル証明書の形式 2

ディジタル証明書の削除 22

ディジタル証明書の受信 21

ディジタル証明書の抽出 17

ディジタル証明書の要求 6, 20

ディジタル証明書のレイアウト 2

デジタル署名、発行者の 2

デフォルト鍵、設定 23

電子メール 5

［ナ行］二重ハンドシェーク 9

認証クライアント 5, 9

認証局 (CA)

ディジタル証明書 2

ルート CA 4

trust 階層 3

［ハ行］パスワード、データベース用に変更 24

パスワード、stash ファイルへの保管 40

発行者の識別名 2

ハンドシェーク説明 6

二重 9


非対称暗号方式 1

秘密鍵 1, 3

秘密鍵と公開鍵のペア 3

プレマスター・シークレット 8

プロパティー・ファイル、IKEYCMD 50

［マ行］マスター・シークレット 8

メッセージ確認コード (MAC) 8

［ラ行］ルート CA 4

CCA

リスト 38

CA ルート・ディジタル証明書削除 16

追加 15

CA ルート・ディジタル証明書の削除 16

CA ルート・ディジタル証明書の追加 15

HHTTP 6

IIKE 規格 5

IKEYCMD

暗号化データベースのパスワード 40

オブジェクトに対するアクションのリスト 44

オプション 45

鍵のインポート 37

鍵のエクスポート 36

環境設定 29

コマンド行の構文 31

鍵データベースのパスワード 34

新規鍵データベース 33

コマンド呼び出し、リスト作成 46

自己署名証明書 35

証明書の受信 38

新規の鍵ペア、認証要求 35

タスク・リスト 31

定義 29

デフォルト鍵の表示 39

トラステッドでない CA 証明書の保管40

プロパティー・ファイル 50

CA 署名証明書 39

IKEYCMD (続き)

CA のリスト作成 38

iKeyman

鍵データベース・ファイルの作成 12

自己署名ディジタル証明書の作成 14


データベース・パスワードの変更 24

ディジタル証明書の削除 22

ディジタル証明書の受信 21

ディジタル証明書の抽出 17

ディジタル証明書の要求 20

CA ルート・ディジタル証明書の削除16

CA ルート・ディジタル証明書の追加15

IP セキュリティー 5

IPsec 規格 5

LLightweight Directory Access Protocol

(LDAP) 5

PPEM 5

Public Key Infrastructure (PKI) 8

RRSA Secure Server CA 13

SSecure Electronic Transaction (SET) 5

SET 5

SSL

暗号化 1

概要 1, 6

グローバル・サーバー証明書を備えた9

定義 5

ディジタル証明書および trust チェーン 8

二重ハンドシェーク 9

ハンドシェーク 6

SSL の仕組み 6

SSL ステップアップ・プロトコル 9

stash ファイル、パスワード保管 40

S/MIME 5

TThawte

Personal Basic CA 13

Personal Freemail CA 13

Personal Premium CA 13

Premium Server CA 13

Server CA 13

trust 階層 3

trust チェーン 3, 4, 8

説明 3, 4

ディジタル証明書および SSL 8

VVeriSign, Inc.

Class 1 Public Primary CA 13

Class 1 Public Primary Certification

Authority — G2 13

Class 2 Onsite Individual Certification

Authority 14


Class 2 Public Primary Certification

Authority — G2 13


Class 3Public Primary Certification

Authority — G2 13

International Server Certification

Authority — class 3 14


��

Printed in Japan

SC88-9855-00

Documents

Secure Sockets Layer の入門および iKeyman ユーザーズ・ガ …publib.boulder.ibm.com/tividd/td/ITAME/SC32-1363-00/ja...本書は、Secure Socket Layer (SSL) ベースのシステムをインストール、管理、およ