Documentation Contents

JavaTM Secure Socket Extension (JSSE)

リファレンスガイド

JavaTM Platform Standard Edition 6


はじめに
特長と利点
JSSE 標準 API
SunJSSE プロバイダ
関連ドキュメント
用語と定義
Secure Sockets Layer (SSL) プロトコルの概要
SSL を使用することの利点
SSL のしくみ
主要なクラス
クラスの関係
コアクラスとインタフェース
SocketFactory および ServerSocketFactory クラス
SSLSocketFactory および SSLServerSocketFactory クラス
SSLSocket および SSLServerSocket クラス
SSLEngine による非ブロック入出力
SSLSession インタフェース
HttpsURLConnection クラス
サポートクラスとインタフェース
SSLContext クラス
TrustManager インタフェース
TrustManagerFactory クラス
X509TrustManager インタフェース
KeyManager インタフェース
KeyManagerFactory クラス
X509KeyManager インタフェース
TrustManager と KeyManager の関連性
二次サポートクラスおよびインタフェース
SSLSessionContext インタフェース
SSLSessionBindingListener インタフェース
SSLSessionBindingEvent クラス
HandShakeCompletedListener インタフェース
HandShakeCompletedEvent クラス
HostnameVerifier インタフェース
X509Certificate クラス
旧バージョン (JSSE 1.0.x) の実装クラスおよびインタフェース
JSSE のカスタマイズ
インストールディレクトリ<java-home>
カスタマイズ
JCE およびハードウェア高速化/スマートカードのサポート
JCE の使用法
ハードウェアアクセラレータ
スマートカードをキーストアおよびトラストストアとして使用するための JSSE の構成
複数の動的キーストア

Kerberos 符号化方式
Kerberos 要件
ピアのアイデンティティー情報
セキュリティーマネージャー

その他のキーストア形式 (PKCS12)

トラブルシューティング
構成上の問題点
デバッグユーティリティー
コード例
安全でないソケットから安全なソケットへの変換
JSSE サンプルコードの実行
JSSE で使用するキーストアの作成
付録 A: 標準名

付録 B: プロバイダのプラグイン可能性


はじめに

ネットワークを通じてやり取りされるデータには、意図された受信者以外の人も、簡単にアクセスできます。データにパスワードやクレジットカード番号などの個人情報が含まれる場合、権限のない者がデータを理解できないよう、手段を講じる必要があります。また、意図的であるかどうかに関わらず、通信中にデータが変更されないようにすることも重要です。Secure Sockets Layer (SSL) および Transport Layer Security (TLS) は、ネットワークを通じたデータの送信時に、データの機密性および整合性を保護するために設計されたプロトコルです。

Java Secure Socket Extension (JSSE) により、安全なインターネット通信が可能になります。JSSE では、Java バージョンの SSL および TLS プロトコルのフレームワークおよび実装が提供されます。また、データ暗号化、サーバー認証、メッセージの整合性のほか、オプションでクライアント認証の機能が含まれます。JSSE を使うと、開発者は Hypertext Transfer Protocol (HTTP)、Telnet、FTP など、TCP/IP のアプリケーションプロトコルを実行するクライアントとサーバーの間で、安全なデータのやり取りを実現できます。SSL の概要については、「Secure Sockets Layer (SSL) の概要」を参照してください。

JSSE は、基盤となる複雑なセキュリティーアルゴリズムや「ハンドシェーク」機構を抽象化することにより、識別するのが難しく、しかし危険なセキュリティー上の弱点が生まれるリスクを最小限に抑えます。また、JSSE を開発者がアプリケーションに直接統合できる構築ブロックとして使うと、アプリケーション開発が簡単になります。

これまでの JSSE は、JavaTM 2 SDK Standard Edition (J2SDK) v 1.3 のオプションパッケージでした。JSSE は、J2SDK 1.4 より Java TM Standard Edition Development Kit に統合されています。

JSSE は、アプリケーションプログラミングインタフェース (API) フレームワークと、その API の実装を提供します。JSSE API は、java.security および java.net パッケージによって定義された「コア」ネットワークおよび暗号化サービスを補い、拡張されたネットワークソケットクラス、トラストマネージャー、キーマネージャー、SSLContext、およびソケット作成動作をカプセル化するソケットファクトリのフレームワークを提供します。ソケット API は JDK 5.0 のブロック化入出力モデルを基にしているため、実装段階で固有の入出力メソッドを選択できるようにするために非ブロック SSLEngine API が導入されました。

JSSE API では、SSL バージョン 2.0 および 3.0 のほか、Transport Layer Security (TLS) 1.0 をサポートします。これらのセキュリティープロトコルは、通常の双方向のストリームソケットをカプセル化し、JSSE API は認証、暗号化、および整合性保護の透過的なサポートを追加します。Sun の JRE に付属している JSSE 実装は、SSL 3.0 と TLS 1.0 をサポートします。SSL 2.0 は実装しません。

すでに説明したように、JSSE は Java SE 6 プラットフォームのセキュリティーコンポーネントで、Java Cryptography Architecture (JCA) フレームワーク上の別の場所にあるものと同じ設計方針に基づいています。暗号化に関するセキュリティーコンポーネントのこのフレームワークにより、実装の独立性と、可能な場合にはアルゴリズムの独立性を実現できます。JSSE は、JCA で定義されたのと同じプロバイダアーキテクチャーを使用します。

Java SE 6 プラットフォームのほかのセキュリティーコンポーネントには、Java 暗号化拡張機能 (JCE)、Java 認証・承認サービス (JAAS)、および Java セキュリティーツールがあります。JSSE は JCE と同じ概念およびアルゴリズムを多数含んでいますが、単純なストリームソケット API の下でこれらを自動的に適用します。

JSSE API は、その他の SSL/TLS プロトコルと公開鍵インフラストラクチャー (PKI) 実装をシームレスにプラグインできる設計になっています。開発者が、リモートホストの信頼性やリモートホストに送信する認証鍵データを決定するロジックを提供することもできます。

特長と利点

JSSE には次のような重要な特長があります。

JSSE で利用できる暗号化機能

暗号化アルゴリズム *

暗号化処理

鍵の長さ (ビット)

RSA

認証と鍵交換

512 以上

RC4

バルク暗号化

128
128 (40 が有効)

DES

バルク暗号化

64 (56 が有効)
64 (40 が有効)

Triple DES

バルク暗号化

192 (112 が有効)

AES

バルク暗号化

256
128

Diffie-Hellman

鍵の承認

1024
  512

DSA

認証

1024

* Note:SunJSSE 実装では、暗号化アルゴリズムのすべてにおいて JavaTM 暗号化拡張機能 (JCE) を使用します。


JSSE 標準 API

JSSE 標準 API は、javax.net および javax.net.ssl パッケージで利用できる API で、次の点をカバーします。

SunJSSE プロバイダ

Sun の Java SE の実装には、「SunJSSE」という名前の JSSE プロバイダが含まれています。このプロバイダはあらかじめインストールされ、JCA に登録されています。このプロバイダが提供する暗号化サービスは次のとおりです。

このプロバイダの詳細は、「SunJSSE」の項を参照してください。

関連ドキュメント

Java Secure Socket Extension 関連ドキュメント

Java プラットフォームのセキュリティー関連ドキュメント

暗号化に関する輸出上の問題

米国の暗号政策については、次のサイトを参照してください。

暗号化に関するドキュメント

オンラインリソース

書籍:

  • Applied Cryptography, Second Edition (Bruce Scheneier 著)John Wiley and Sons, Inc., 1996

  • Cryptography Theory and Practice (Doug Stinson 著)CRC Press, Inc., 1995.

  • 『Cryptography & Network Security:Principles & Practice』、William Stallings 著、Prentice Hall, 1998.

Secure Sockets Layer 関連ドキュメント

オンラインリソース

書籍:

  • 『SSL and TLS:Designing and Building Secure Systems』、Eric Rescorla 著、Addison Wesley Professional 発行、2000

  • SSL and TLS Essentials:Securing the Web (Stephen Thomas 著)John Wiley and Sons, Inc., 2000

  • Java 2 Network Security, Second Edition (Marco Pistoia, Duane F Reller, Deepak Gupta, Milind Nagnur, and Ashok K Ramani 著)Prentice Hall, 1999. Copyright 1999 International Business Machines

用語と定義

このドキュメントでは、暗号化に関する用語が使用されます。この節では、こうした用語を定義します。

認証

認証とは、通信相手の識別情報を確認するプロセスです。

暗号群

暗号群とは、暗号化パラメータの組み合わせで、認証、鍵の承認、暗号化、および整合性保護に使用するセキュリティーアルゴリズムおよび鍵のサイズを定義します。

証明書

証明書とは、デジタル署名付きの文で、あるエンティティー (人や会社など) の識別情報および公開鍵の内容を保証します。証明書には、自己署名付き証明書と証明書発行局 (CA) から発行された証明書があります。証明書発行局とは、ほかのエンティティーのために有効な証明書を発行する信頼のおけるエンティティーです。よく知られている CA には VeriSign、Entrust、および GTE CyberTrust があります。X509 は証明書の一般的な形式で、JDK の keytool で管理することができます。

暗号化ハッシュ関数

暗号化ハッシュ関数はチェックサムと似ています。データは、ハッシュと呼ばれる、比較的小さなビット文字列を生成するアルゴリズムで処理されます。暗号化ハッシュ関数には、次のような 3 つの主な特徴があります。(1) 一方向の関数であるため、ハッシュからオリジナルデータを生成することはできません。(2) オリジナルデータをわずかに変更しても、ハッシュでは大きな変更になります。(3) 暗号化鍵は必要ありません。

暗号化サービスプロバイダ

JCA では、さまざまな暗号化アルゴリズムの実装が、暗号化サービスプロバイダ (略称は「プロバイダ」) によって提供されます。プロバイダは、基本的には、特定のアルゴリズムのエンジンクラスを実装するパッケージです。エンジンクラスは、具体的な実装のない抽象的な方法で暗号化サービスを定義します。

デジタル署名

デジタル署名とは、手書きの署名のデジタル版です。これは、ネットワークで伝送されるデータが、それを送信したと主張する人物からのものであり、送信中にデータが変更されていないことを保証するものです。たとえば、RSA ベースのデジタル署名を計算するには、まずデータの暗号化ハッシュを計算し、次に送信者の非公開鍵でハッシュを暗号化します。

暗号化および暗号解読

暗号化とは、複雑なアルゴリズムを使用して、元のメッセージ (クリアテキスト) を符号化されたメッセージ (暗号テキスト) に変換するプロセスです。暗号テキストは、復号化しない限り、その内容を理解できません。復号化とは、クリアテキストから暗号テキストを作成するのとは逆のプロセスです。通常、データの暗号化および復号化に使用するアルゴリズムには、次の 2 つのカテゴリがあります。それは、秘密鍵 (対称型) 暗号と公開鍵 (非対称型) 暗号です。

ハンドシェークプロトコル

2 つのソケット同士が新しいセッションや既存のセッションの使用に同意するネゴシエーションのフェーズです。ハンドシェークプロトコルは、レコードプロトコルを介して交換される一連のメッセージです。ハンドシェークの終了時に、セッションの接続に固有の暗号化鍵や、整合性を保護するための鍵が、鍵の承認による秘密に基づいて新たに生成されます。

鍵協定

鍵協定は、2 つのパーティーが協力して共通鍵を確立するための方法です。それぞれの側が一定のデータを生成して交換します。その後、2 つのデータが組み合わされて、1 つの鍵が生成されます。適正な非公開初期化データを保持しているユーザーだけが、最終的な鍵を取得することができます。Diffie-Hellman (DH) は、一般的な鍵協定アルゴリズムの一例です。

鍵交換

一方の側が対称鍵を生成し、標準的には RSA により、ピアの公開鍵を使用して暗号化します。それからデータがピアに送信され、ピアは対応する非公開鍵を使用して対称鍵を復号化します。

キーマネージャーとトラストマネージャー

キーマネージャーとトラストマネージャーは、それぞれの鍵データにキーストアを使用します。キーマネージャーはキーストアを管理し、ユーザー承認時など必要に応じて公開鍵を提供します。トラストマネージャーは、管理するトラストストアの情報にもとづいて、トラストの対象者を決定します。

キーストアとトラストストア

キーストアは、鍵データのデータベースです。鍵データにはさまざまな用途があり、それには認証やデータ整合性も含まれます。利用できるキーストアにはさまざまな型があり、その中には「PKCS12」や Sun の「JKS」も含まれます。

一般に、キーストア情報は次の 2 つのカテゴリに分類できます。それは、鍵のエントリと、信頼される証明書のエントリです。鍵のエントリはエンティティーの識別情報とその非公開鍵から構成されており、さまざまな暗号化の用途に使用できます。これとは対照的に、信頼される証明書のエントリには、公開鍵とそのエンティティーの識別情報しか含まれていません。したがって、javax.net.ssl.KeyManager の場合など、非公開鍵が必要な場合は、信頼される証明書のエントリを使用することはできません。JKS の J2SDK 実装では、キーストアに鍵のエントリと、信頼される証明書のエントリの両方を含めることができます。

トラストストアとは、トラストの対象を決めるときに使用するキーストアです。すでに信頼しているエンティティーからデータを受け取る場合、およびそのエンティティーが発信元を名乗るエンティティーであることを検証できる場合は、データは実際にそのエンティティーから届いたものであると仮定できます。

ユーザーがそのエンティティーを信頼すると決定した場合に限り、トラストストアにエントリが追加されます。ユーザーは、鍵のペアを生成するか、証明書をインポートすることにより、そのエントリにトラストを与えます。これにより、キーストアのエントリは信頼されたエントリとみなされます。

次のような 2 つのキーストアファイルがあると便利です。1 つは鍵のエントリだけのファイル、もう 1 つは信頼された証明書のエントリを含むファイルです。これには、証明書発行局 (CA) が発行する証明書が含まれます。前者には機密性のある情報が含まれますが、後者には機密性のある情報は含まれません。単独のキーストアファイルではなく、異なる 2 つのキーストアファイルを使用すると、独自の証明書 (および対応する非公開鍵) と他の証明書を論理的に区別した明確な区分が提供されます。アクセス制限があるキーストアに非公開鍵を保存すると、非公開鍵をさらに保護することができます。一方、必要であれば、より自由にアクセスできるキーストアで信頼される証明書を提供することもできます。

メッセージ認証コード

メッセージ認証コード (MAC) は、送信された情報や、信頼できないメディアに保存されている情報の整合性を、秘密鍵にもとづいてチェックする方法を提供します。通常、MAC は秘密鍵を共有する 2 つの当事者間で、お互いが送信する情報を検証するために使用されます。

暗号化ハッシュ機能に基づくMAC 機構は、HMAC と呼ばれます。HMAC は、共有する秘密鍵と組み合わせて、Message Digest 5 (MD5) や Secure Hash Algorithm (SHA) などの暗号化ハッシュ関数とともに使用できます。HMAC については、RFC 2104 で規定されています。

公開鍵暗号方式

公開鍵暗号化では、2 つの鍵を生成する暗号化アルゴリズムを使用します。一方の鍵は公開されますが、他方は非公開のままです。公開鍵と非公開鍵では、逆の暗号化処理がなされ、一方の鍵で暗号化したものを他方の鍵で復号化します。公開鍵暗号化は、非対称暗号化とも呼ばれます。

レコードプロトコル

レコードプロトコルは、アプリケーションレベルのデータやハンドシェークプロセスの一部であるデータをすべて、独立したデータレコードにパッケージ化します。これは、TCP ストリームソケットでアプリケーションバイトストリームをネットワークパケットに変換する場合によく似ています。個々のレコードは、使用している暗号化鍵および整合性保護鍵によって保護されます。

秘密鍵暗号方式

秘密鍵暗号方式では、データの暗号化と復号化に同じ鍵を使用する暗号化アルゴリズムを使用します。秘密鍵暗号方式は対称暗号方式とも呼ばれます。

セッション

セッションとは、名前付きの状態の情報のコレクションで、認証されたピア識別情報、暗号群、鍵の承認の秘密を含みます。セッションでは、安全なソケットハンドシェークを通じてネゴシエーションが行われます。セッションは、複数の安全なソケットインスタンスで共有することができます。

トラストマネージャー

「キーマネージャーとトラストマネージャー」を参照してください。

トラストストア

「キーストアとトラストストア」を参照してください。

Secure Sockets Layer (SSL) プロトコルの概要

Secure Sockets Layer (SSL) は、Web で暗号化を実装する場合にもっともよく使用されるプロトコルです。SSL は、ネットワークで安全な通信を行うために暗号化プロセスを組み合わせて使用します。この節では、SSL および SSL が使用する暗号化プロセスについて簡単に説明します。

SSL は、インターネットで使用される標準的な TCP/IP ソケットプロトコルの機能を安全に拡張します。次の図「SSL を使用する TCP/IP プロトコル」で示すように、Secure Sockets Layer は標準的な TCP/IP プロトコルのトランスポート層とアプリケーション層の間に追加されます。SSL とともにもっともよく使用されるアプリケーションは Hypertext Transfer Protocol (HTTP) です。これはインターネットの Web ページ用のプロトコルです。このほかにも、Net News Transfer Protocol (NNTP)、Telnet、Lightweight Directory Access Protocol (LDAP)、Interactive Message Access Protocol (IMAP)、File Transfer Protocol (FTP) などのアプリケーションがあり、やはり SSL とともに使用します。

注: 現在のところ、安全な FTP の標準規格は存在しません。

SSL を使用する TCP/IP プロトコル

TCP/IP の層

プロトコル

アプリケーション層

    HTTP、NNTP、Telnet、FTP など

Secure Sockets Layer

    SSL

トランスポート層

    TCP

インターネット層

    IP

SSL は 1994 年に Netscape 社によって開発され、インターネットの世界で使用されるようになると、標準的な存在になりました。現在では、国際的な標準化機構である Internet Engineering Task Force (IETF) が管理しています。IETF は SSL の名称を Transport Layer Security (TLS) に変更し、1999 年 1 月にバージョン 1.0 を初めて発表しました。TLS 1.0 は、SSL の最新バージョン 3.0 を少しだけ変更したものです。SSL 3.0 と TLS 1.0 にはほとんど違いがありません。

SSL を使用することの利点

次の 3 つの理由から、機密情報をネットワークで送信する際に危険が伴う場合があります。

SSL はこれらの問題に対応しています。最初の問題には、認証と呼ばれるプロセスを通じ、通信の当事者双方に互いの識別情報を任意に確認させることで対応しています。両者が認証されると、SSL は両者を暗号化接続して安全な通信を行います。両者の通信を暗号化することで 2 番目の問題に対応し、機密性が保持されます。SSL で使用する暗号化アルゴリズムには、安全なハッシュ関数が含まれています。これはチェックサムに似ています。これにより、送信中にデータが変更されていないことが保証されます。安全なハッシュ関数により、3 番目の問題に対応し、データの整合性を確保します。

認証も暗号化もオプションであり、当事者間でネゴシエーションが行われた暗号群に基づいていることに注意してください。

もっとも端的な SSL の使用例は電子商取引です。電子商取引では、通信するサーバーの識別情報は保証されていると考えるべきではありません。クレジットカードの番号を入力するだけですばらしいサービスが受けられるという偽の Web サイトを作成するのは簡単なことです。SSL を使うと、クライアントがサーバーの識別情報を認証することができます。また、サーバーもクライアントの情報を認証できますが、インターネット上の取引では、この方法はあまり使われていません。

クライアントとサーバーが互いの情報を認証すると、SSL は暗号化アルゴリズムを使って機密性とデータの整合性を提供します。これにより、クレジットカード番号のような機密情報をインターネット上で安全に送信することができます。

SSL は認証、機密性、およびデータの整合性を提供しますが、非拒否サービスは提供しません。非拒否性とは、メッセージを送信したエンティティーは、後になって送信を拒否することができないということを意味します。メッセージとデジタル署名が関連付けられていると、後になって通信内容を証明することができます。SSL 単独では、非拒否性を提供しません。

SSL のしくみ

SSL が有効な理由の 1 つに、複数の暗号化プロセスを使用していることがあります。SSL は、公開鍵暗号で認証を行い、秘密鍵暗号とデジタル署名で機密性とデータの整合性を提供します。SSL について理解する前に、暗号化の処理方法を理解しておくと役立ちます。

暗号化処理

暗号化の主な目的は、権限のない第三者が非公開の通信にアクセスしたり、その内容を理解するのを困難にすることです。暗号化では、データに対する権限のないすべてのアクセスを必ずしも制限できるわけではありませんが、権限のない第三者が非公開のデータを読み取れないようにすることができます。暗号化では、複雑なアルゴリズムを使用して、元のメッセージ (クリアテキスト) を符号化されたメッセージ (暗号テキスト) に変更します。通常、ネットワークで送信されるデータの暗号化および復号化に使用するアルゴリズムには 2 つのカテゴリがあります。秘密鍵暗号方式と公開鍵暗号方式です。これらの暗号方式については、以下の節で説明します。

秘密鍵暗号方式も公開鍵暗号方式も、合意に基づく暗号鍵または暗号鍵のペアを使用します。鍵は、データの暗号化プロセスおよび復号化プロセスで暗号化アルゴリズムが使用するビット文字列です。暗号化鍵は錠の鍵に似ています。錠を空けることができるのは、正しい鍵だけです。

通信の当事者が互いに鍵を安全に送信するのは、些細な問題ではありませN。公開鍵証明書を使うと、公開鍵を安全に送信し、受信者に公開鍵の信頼性を保証することができます。公開鍵証明書については、後の節で説明します。

以下で説明する暗号化プロセスでは、セキュリティーコミュニティーで使用する名称を使います。通信の当事者をそれぞれ Alice と Bob とし、権限のない第三者を Charlie とします。Charlie は攻撃者にもなります。

秘密鍵暗号方式

秘密鍵暗号方式では、通信する Alice と Bob はメッセージの暗号化と復号化に同じ鍵を使います。暗号化されたデータをネットワークで送信する前に、Alice と Bob は鍵を持っていることが必要で、暗号化と復号化に使用する暗号化アルゴリズムに同意している必要があります。

秘密鍵暗号方式で大きな問題になるのは、攻撃者にアクセスされずに一方から他方に鍵を渡す方法です。Alice と Bob が秘密鍵暗号方式でデータを暗号化しても、Charlie がその鍵にアクセスできれば Alice と Bob の非公開メッセージを傍受することができます。Charlie は Alice と Bob のメッセージを復号化できるだけではなく、Alice になりすまして暗号化データを Bob に送信することもできるのです。Bob には、メッセージが Charlie から届いたものか Alice から届いたものかはわかりません。

秘密鍵の配布方法の問題が解決すれば、秘密鍵暗号はたいへん貴重なツールになります。そのアルゴリズムにより、優れたセキュリティーと暗号化データが比較的迅速に提供できるからです。SSL セッションで送信される機密性の高いデータの多くは、秘密鍵暗号方式で送信されます。

秘密鍵暗号方式は、データの暗号化と復号化に同じ鍵を使用するので、対称暗号化方式とも呼ばれます。よく知られている秘密鍵暗号化アルゴリズムには、Data Encryption Standard (DES)、トリプル DES (3DES)、Rivest Cipher 2 (RC2)、および Rivest Cipher 4 (RC4) があります。

公開鍵暗号方式

公開鍵暗号化方式は、公開鍵と非公開鍵を使うことで鍵の配布方法を解決しました。公開鍵はネットワークを通じて公開し、送信できますが、非公開鍵は通信の 1 人の当事者にしか公開されません。公開鍵と非公開鍵は暗号化方式が逆で、一方の鍵で暗号化したものをもう一方の鍵で復号化します。

ここで、Bob が Alice に公開鍵暗号方式で秘密のメッセージを送信する場合を考えてみましょう。Alice は公開鍵と非公開鍵をどちらも持っているので、非公開鍵は安全な場所に保管しておき、公開鍵を Bob に送信します。Bob は Alice の公開鍵を使って Alice への秘密のメッセージを暗号化します。Alice は非公開鍵を使ってメッセージを復号化します。

Alice が非公開鍵を使ってメッセージを暗号化し、そのメッセージを Bob に送信すれば、Bob が受信するデータは Alice から届いたものだと考えることができます。Bob が Alice の公開鍵でデータを復号化できれば、そのメッセージは Alice が自分の非公開鍵で暗号化したものに間違いありません。Alice の非公開鍵を持っているのは Alice だけだからです。問題は、Alice の公開鍵が公開されているために、だれもがメッセージを読めてしまうことです。このシナリオは、安全なデータ通信を考慮に入れていませんが、デジタル署名の基本には触れています。デジタル署名とは公開鍵証明書のコンポーネントの 1 つで、SSL でクライアントやサーバーを認証するために使用します。公開鍵証明書とデジタル署名については、後の項で説明します。

公開鍵暗号方式は、データの暗号化と復号化に同じ鍵を使用するので、非対称暗号化方式とも呼ばれます。SSL を使用することが多い、よく知られている公開鍵暗号化アルゴリズムには、Rivest Shamir Adleman があります。このほかにも、秘密鍵を交換するために設計された SSL を使う公開鍵暗号化アルゴリズムには、Diffie-Hellman (DH) があります。公開鍵暗号方式には膨大な計算が必要なため、速度が遅くなります。そこで、この方式は暗号化データ通信全体に使用するよりもむしろ、秘密鍵など少量のデータを暗号化する場合にだけ使用します。

秘密鍵暗号方式と公開鍵暗号方式の比較

秘密鍵暗号方式と公開鍵暗号方式のどちらにも、長所と弱点があります。秘密鍵暗号方式では、データの暗号化や復号化に時間はかかりませんが、通信者同士が同じ秘密鍵情報を持つ必要があり、鍵の交換方法が問題になります。公開鍵暗号方式では、鍵を秘密にする必要がないので交換方法は問題になりません。しかしデータの暗号化と復号化に使用するアルゴリズムには膨大な計算が必要で、速度が遅くなります。

公開鍵証明書

公開鍵証明書を使うと、エンティティーは非対称暗号方式で使用する公開鍵を安全に配布できます。公開鍵証明書は次のような状況を回避します。Charlie が自分の公開鍵と非公開鍵を作成すれば、自分は Alice だと名乗って Bob に公開鍵を送信できます。Bob は Charlie と通信できますが、データを Alice に送信していると思い込んでしまいます。

公開鍵証明書は電子的なパスポートだと考えることができます。これは、信頼できる組織によって発行され、所有者に識別情報を提供します。公開鍵証明書を発行する信頼できる組織を、証明書発行局 (CA) と呼びます。CA は公証人にたとえることができます。CA から証明書を取得するには、識別情報の証拠となるものを提供する必要があります。CA は、申請者が申し立てる組織の代表であるとの確証が得られたら、証明書に含まれる情報の妥当性を証明する証明書に署名します。

公開鍵証明書には、次のようなフィールドがあります。

  • 発行者 - 証明書を発行した CA です。証明書を発行する CA が信頼でき、証明書が有効であれば、証明書は信頼できます。

  • 有効期間 - 証明書には期日があります。証明書の妥当性を検証する場合は、この日付は確認すべき情報の 1 つになります。

  • サブジェクト - サブジェクトフィールドには、証明書が表すエンティティーの情報が含まれます。

  • サブジェクトの公開鍵 - 証明書が提供する主な情報に、サブジェクトの公開鍵があります。その他のフィールドは、この鍵の妥当性を確認するためのものです。

  • 署名 - 証明書は、証明書を発行した CA によって電子的に署名されます。署名は CA の非公開鍵を使って作成され、証明書の妥当性を保証するものです。証明書にだけ署名され、SSL トランザクション送信されるデータには署名されないので、SSL には非拒否性がありません。

Alice が Bob に公開鍵証明書で自分の公開鍵を送信するとき、Bob が Alice の公開鍵を有効であると認める以外のことを行わない場合、Charlie が Alice になりすましたとしても、Bob が Charlie に秘密情報を送信することはありません。

複数の証明書を証明書チェーンでリンクすることもできます。証明書チェーンを使用する場合、最初の証明書は必ず送信者の証明書です。次は送信者の証明書を発行したエンティティーの証明書です。チェーン内にさらに証明書がある場合、直前の証明書を発行した証明書発行局の証明書が続きます。チェーンの最後の証明書は、ルート CA の証明書です。ルート CA は、広く信頼されている公開証明書発行局です。複数のルート CA の情報は、通常、クライアントのインターネットブラウザに保存されています。この情報には、CA の公開鍵が含まれています。よく知られている CA には VeriSign、Entrust、および GTE CyberTrust があります。

暗号化ハッシュ関数

暗号化されたデータを送信する場合、SSL は通常、暗号化ハッシュ関数を使ってデータの整合性を保証します。ハッシュ関数を使って、Alice が Bob に送ったデータを Charlie が改ざんできないようにします。

暗号化ハッシュ関数はチェックサムに似ています。主な違いは、チェックサムがデータの偶発的変化を検出するのに対し、暗号化ハッシュ関数は故意による変更を検出するということです。データが暗号化ハッシュ関数で処理されると、ハッシュと呼ばれる小さなビット文字列が生成されます。メッセージがごくわずかだけ変更された場合も、結果として生成されるハッシュは大きく変更されます。暗号化ハッシュ関数には、暗号化鍵が必要ありません。SSL とともに使用されることが多いハッシュ関数には、Message Digest 5 (MD5) と Secure Hash Algorithm (SHA) の 2 つがあります。SHA は、U.S. National Institute of Science and Technology (NIST) によって提案されました。

メッセージ認証コード

メッセージ認証コード (MAC) は暗号化ハッシュに似ていますが、秘密鍵をベースにしている点が異なります。秘密鍵情報が暗号化ハッシュ関数で処理したデータに含まれている場合、その結果生成されるハッシュは HMAC と呼ばれます。

Alice は、Bob へのメッセージを Charlie が傍受していないことを確認したい場合、メッセージの HMAC を計算して元のメッセージに HMAC を追加できます。次に、Bob と共有している秘密鍵を使ってメッセージと HMAC を暗号化します。Bob は、メッセージを復号化して HMAC を計算すれば、送信中にメッセージが変更されたかどうかを知ることができます。SSL では、HMAC を使って安全なデータを送信します。

デジタル署名

メッセージに暗号化ハッシュが作成されると、ハッシュは送信者の非公開鍵で暗号化されます。このような暗号化ハッシュをデジタル署名と呼びます。

SSL 処理

SSL を使った通信は、クライアントとサーバー間の情報交換から始まります。この情報交換を SSL ハンドシェークと呼びます。

SSL には、主に次のような 3 つの目的があります。

  • 暗号群のネゴシエーション

  • 情報の認証 (オプション)

  • 暗号化機構の同意による情報セキュリティーの確立

暗号群のネゴシエーション

SSL セッションは、どの暗号群を使用するかについて、クライアントとサーバーがネゴシエーションを行うことから始まります。暗号群とは、コンピュータがデータを暗号化するために使用する暗号化アルゴリズムと鍵のサイズです。符号化方式には、公開鍵交換アルゴリズムまたは鍵協定アルゴリズム、およびおよび暗号化ハッシュ関数に関する情報が含まれます。クライアントは利用できる暗号群をサーバーに伝え、サーバーは、どちらにも適用できる暗号群を選択します。

サーバーの認証

SSL の認証ステップは省略できます。しかし、Web 上の電子商取引では、一般的にクライアントがサーバーを認証します。サーバーの認証により、サーバーが表すとクライアントが信じているエンティティーを、そのサーバーが実際に表していることをクライアントが確認できます。

サーバーは、自らが表すと唱える組織に属していることを証明するため、クライアントに公開鍵証明書を提示します。この証明書が有効であれば、クライアントはサーバーの識別情報について確信できます。

クライアントとサーバーは、同じ秘密鍵について同意できる情報を交換します。たとえば、RSA を使う場合、クライアントは公開鍵証明書で取得したサーバーの公開鍵を使用して、秘密鍵情報を暗号化します。クライアントは暗号化された秘密鍵情報をサーバーに送信します。復号化にはサーバーの非公開鍵が必要なので、サーバーでだけ、このメッセージを復号化できます。

暗号化されたデータの送信

クライアントとサーバーは、同じ秘密鍵にアクセスします。それぞれのメッセージでは、この処理の最初の段階で選択した、秘密情報を共有する暗号化ハッシュ関数を使って、メッセージに添付される HMAC を計算します。次に、秘密鍵と、この処理の最初の段階で設定した秘密鍵アルゴリズムを使い、安全なデータと HMAC を暗号化します。その後、クライアントとサーバーは、暗号化されハッシュ化されたデータを使って安全に通信することができます。

SSL プロトコル

前の節では、SSL ハンドシェークを上位レベルで説明しました。つまり、暗号化されたメッセージを送信する前にクライアントとサーバーで行われる情報交換について説明しました。この節では、さらに詳しく説明します。

次の「SSL メッセージ」には、SSL ハンドシェークで交換される一連のメッセージが示されています。特定の状況下でだけ送信されるメッセージには (Optional) と記されています。SSL メッセージの説明は次のとおりです。

SSL ハンドシェークで交換されるメッセージシーケンス

SSL メッセージは、次の順序で送信されます。

  1. Client hello - クライアントはサーバー情報を送信します。この情報には、自分がサポートする最上位バージョンの SSL と暗号群のリストが含まれます。TLS 1.0 は SSL 3.1 と表示されます。暗号群の情報には、暗号化アルゴリズムと鍵のサイズが含まれます。

  2. Server hello - サーバーは、クライアントとサーバーの両方がサポートする最上位バージョンの SSL と最適な暗号群を選択し、この情報をクライアントに送信します。

  3. Certificate - サーバーはクライアントに証明書または証明書チェーンを送信します。証明書チェーンは通常、サーバーの公開鍵証明書で始まり、認証局のルート証明書で終わります。このメッセージはオプションで、サーバー認証を求められた場合に使用します。

  4. Certificate request - サーバーがクライアントを認証する必要がある場合、クライアントに証明書要求を送信します。インターネットアプリケーションでは、このメッセージが使われることはほとんどありません。

  5. Server key exchange - 上記の 3 で送信した公開鍵情報が鍵交換を行うのに不十分な場合、サーバーはクライアントにサーバー鍵交換メッセージを送信します。

  6. Server hello done - サーバーは、最初のネゴシエーションメッセージを終了したことをクライアントに伝えます。

  7. Certificate - メッセージ 4 でサーバーがクライアントに証明書を要求すると、クライアントはメッセージ 3 でサーバーが行なったようにして、証明書チェーンを送信します。

    注: クライアントに証明書を要求するのは、ごく一部のインターネットサーバーアプリケーションだけです。

  8. Client key exchange - クライアントは、対称暗号方式で使用する鍵を作成する情報を生成します。RSA では、クライアントはサーバーの公開鍵でこの鍵情報を暗号化してサーバーに送信します。

  9. Certificate verify - このメッセージは、上述のとおりクライアントが証明書を提示する場合に送信されます。このメッセージは、サーバーにクライアントの認証処理を完了させるためのものです。このメッセージが使用されると、クライアントは暗号化ハッシュ関数で電子的に署名した情報を送信します。サーバーがクライアントの公開鍵でこの情報を復号化すれば、サーバーはクライアントを認証できます。

  10. Change cipher spec - クライアントはメッセージを送信し、暗号化モードを変更するようサーバーに伝えます。

  11. Finished - クライアントはサーバーに、安全なデータ通信を開始する準備ができたことを伝えます。

  12. Change cipher spec - サーバーはメッセージを送信し、暗号化モードを変更するようクライアントに伝えます。

  13. Finished - サーバーはクライアントに、安全なデータ通信を開始する準備ができたことを伝えます。SSL ハンドシェークが終了します。

  14. Encrypted data - クライアントとサーバーは、メッセージ 1 と 2 で取り決めた対称暗号化アルゴリズムと暗号化ハッシュ関数、およびメッセージ 8 でクライアントがサーバーに送信した秘密鍵を使って通信します。
  15. Close Messages - 接続の終わりに、それぞれの側が close_notify メッセージを送信し、接続が終了したことをピアに伝えます。

SSL セッションで生成したパラメータを保存しておけば、それ以降も SSL セッションで利用することができます。SSL セッションのパラメータを保存しておけば、暗号化通信をすばやく開始できます。

符号化方式の選択とリモートエンティティーの検証

SSL/TLS プロトコルでは、保護された接続を確保するための一連の具体的な手順を定義しています。ただし、選択する符号化方式により、接続で確保するセキュリティーの種類が決まります。たとえば、匿名符号化方式を選択した場合、アプリケーションにはリモートピアの識別情報を検証する手段がありません。暗号化なしの符号化方式が選択された場合は、データの機密性を保護できません。また SSL/TLS プロトコルでは、受信した資格と、ピアから送信されることが予期される資格が一致するようにとは規定していません。接続が何らかの理由で悪意のあるピアにリダイレクトされたときに、悪意のあるピアの資格が現在のトラストデータに基づいて受け入れられた場合、その接続は有効と見なされてしまいます。

raw SSLSockets/SSLEngines を使用する場合は、データの送信前に必ずピアの資格をチェックしてください。SSLSocket クラスと SSLEngine クラスは、URL のホスト名がピアの資格にあるホスト名と一致するかどうかを自動的に検証しません。ホスト名が検証されなければ、URL 不正行為によって被害を受ける可能性があります。

https などのプロトコルは、ホスト名の検証処理が不要です。アプリケーションは、HostnameVerifier を使用してデフォルトの HTTPS ホスト名規則を上書きできます。詳細については、HttpsURLConnection を参照してください。

SSL と TLS に関する参照資料

SSL についての参考資料は、「Secure Sockets Layer の関連ドキュメント」を参照してください。

主要なクラス

クラスの関係

安全な通信を行うには、接続の両方の側で SSL が使用できることが必要です。JSSE API の接続のエンドポイントクラスは、SSLSocket および SSLEngine です。次の図では、SSLSocket/SSLEngine の作成に使用される主なクラスを論理的な順序で並べています。

SSLSocket/SSLEngine の作成に使用されるクラス

SSLSocketSSLSocketFactory またはインバウンド接続を受け取る SSLServerSocket によって作成されます。SSLServerSocketSSLServerSocketFactory で作成されます。SSLSocketFactory および SSLServerSocketFactory オブジェクトはどちらも SSLContext で作成されます。SSLEngine は、SSLContext によって直接作成され、アプリケーションに依存してすべての入出力を処理します。


重要: raw SSLSockets/SSLEngines を使用する場合は、データの送信前に必ずピアの資格をチェックしてください。たとえば SSLSocket/SSLEngine クラスは、URL のホスト名がピアの資格にあるホスト名と一致するかどうかを自動的に検証しません。ホスト名が検証されなければ、URL 不正行為によって被害を受ける可能性があります。

SSLContext を取得して初期化するには、次の 2 通りの方法があります。

SSL 接続が確立されると、SSLSession が作成されます。これには設定した識別情報、使用する暗号群などの情報が含まれます。次に、SSLSession を使って両方のエンティティーの現在の関係と状態を表します。各 SSL 接続には、一度に 1 つのセッションが含まれますが、そのセッションがエンティティー間の接続に、同時に、または連続して何度も使用されることがあります。

コアクラスとインタフェース

コア JSSE クラスは、java.net および javax.net.ssl パッケージの一部です。

SocketFactory および ServerSocketFactory クラス

抽象クラス javax.net.SocketFactory は、ソケットの作成に使われます。このクラスは、他のファクトリでサブクラス化する必要があります。ファクトリは、ソケットの特定のサブクラスを作成し、一般的なソケットレベルの機能を追加するフレームワークを提供します。たとえば、「SSLSocketFactory」を参照してください。

javax.net.ServerSocketFactory クラスは、SocketFactory クラスに似ていますが、サーバーソケットの作成に特に使われます。

ソケットファクトリを使うと、構築するソケットに関する一連のポリシーを簡単に取得し、ソケットを要求する特別なコード設定を必要としない方法でソケットを作成できます。

  • ファクトリとソケットに多相性があるため、種類が異なるファクトリを渡すだけで、種類が異なるソケットに同じアプリケーションコードを使用できます。

  • ソケット構築時に使用するパラメータを使って、ファクトリ自身をカスタマイズできます。たとえば、ファクトリをカスタマイズして、異なるネットワークタイムアウトのソケットや、設定済みのセキュリティーパラメータを返すことができます。

  • アプリケーションに返されるソケットは java.net.Socket (または javax.net.ssl.SSLSocket) のサブクラスにすることができます。そうすれば、圧縮、セキュリティー、レコード宣言、統計情報収集、ファイアウォールトンネリングなどの機能の新しい API を直接公開できます。

SSLSocketFactory および SSLServerSocketFactory クラス

javax.net.ssl.SSLSocketFactory は、安全なソケットを作成するファクトリとして動作します。このクラスは、javax.net.SocketFactory の抽象サブクラスです。

安全なソケットファクトリは、安全なソケットの作成と初期設定の詳細情報をカプセル化します。これには、認証鍵、ピア証明書の検証、使用できる暗号群などが含まれます。

javax.net.ssl.SSLServerSocketFactory クラスは SSLSocketFactory クラスに似ていますが、サーバーソケットの作成に特化して使われます。

SSLSocketFactory の取得

SSLSocketFactory を取得するには、次の 3 つの方法があります。

  • SSLSocketFactory.getDefault static メソッドを呼び出してデフォルトのファクトリを取得する。

  • API パラメータとしてファクトリを受信する。つまり、ソケットを作成する必要があるものの、そのソケットの設定内容の詳細に関与しないコードには、SSLSocketFactory パラメータでメソッドを含めることができます。これは、クライアントによって呼び出され、ソケットの作成時に使用する SSLSocketFactory を指定するパラメータです。(例: javax.net.ssl.HttpsURLConnection)

  • 動作を指定した新規ファクトリを構築する

通常、デフォルトのファクトリはサーバー認証だけをサポートするように設定されています。このため、デフォルトのファクトリで作成されたソケットは、一般的な TCP ソケット以上にクライアントの情報を漏らすことはありません。

ソケットを作成して使用するクラスの多くは、ソケットの作成方法を詳しく知る必要はありません。パラメータとして渡されたソケットファクトリを介してソケットを作成するのは、ソケット設定の詳細を分離し、ソケットを作成して使用するクラスの再利用性を高めるよい方法です。

新しいソケットファクトリインスタンスを作成するには、独自のソケットファクトリサブクラスを実装するか、ソケットファクトリのファクトリとして動作するクラスを別に使用します。そのようなクラスの 1 つに、SSLContext があります。このクラスは、プロバイダベースの構成クラスとして JSSE 実装に提供されています。

SSLSocket および SSLServerSocket クラス

javax.net.ssl.SSLSocket は、標準的な Java の java.net.Socket クラスのサブクラスです。標準的なソケットメソッドをすべてサポートし、安全なソケットに固有のメソッドを追加します。このクラスのインスタンスは、その作成に使用された SSLContext をカプセル化します。ソケットインスタンスの安全なソケットセッションの作成を管理する API もありますが、トラストマネージャーおよびキーマネージャーは直接公開されません。

javax.net.ssl.SSLServerSocket クラスは SSLSocket クラスに似ていますが、サーバーソケットの作成に特化して使われます。

ピアの不正行為を防止するには、常に SSLSocket に示される資格を検証してください。

実装にあたっての注意: SSL と TLS プロトコルは複雑なので、接続時の入力バイトがハンドシェークのデータとアプリケーションデータのどちらなのかを予測し、現在の接続状態にどのような影響を与えるか (処理を中断させることもある) を予測するのは困難です。Sun JSSE の実装では、SSLSocket.getInputStream() によって取得されたオブジェクトの available() メソッドは、SSL 接続で正常に復号化されても、アプリケーションではまだ読み込まれていないデータのバイト数を返します。

SSLSocket の取得

SSLSocket のインスタンスは、次の 2 つの方法で取得できます。1 つ目は、そのクラスの複数の createSocket メソッドのうちの 1 つを介して、SSLSocketFactory のインスタンスで SSLSocket を作成する方法です。2 つ目は、SSLServerSocket クラスの accept メソッドを介して SSLSocket を取得する方法です。

SSLEngine による非ブロック入出力

SSL/TLS が利用される機会はますます増えています。広範な計算プラットフォームやデバイスを包含するさまざまなアプリケーションで使用されています。こうした技術の普及に伴い、アプリケーションのパフォーマンス、拡張性、サイズその他の要件を満たすため、異なる入出力モデルやスレッドモデルにおいても使用可能にする必要が生じています。たとえば、ブロックおよび非ブロック入出力チャネル、非同期入出力、任意の入力ストリームと出力ストリーム、およびバイトバッファーでの使用が求められています。また、数千のネットワーク接続を管理することが必要な、非常に拡張性の高いパフォーマンス重視の環境で使用することも求められています。

Java SE 5 以前の JSSE API は、SSLSocket によるストリームベースソケットという 1 つのトランスポート抽象化のみをサポートしていました。ストリームベースソケットは多くのアプリケーションに適切でしたが、異なる入出力モデルやスレッドモデルを使用する必要があるアプリケーションの要求は満たせませんでした。1.6.0 では、新しい抽象化手法が導入され、トランスポートに依存せずに SSL/TLS プロトコルをアプリケーションで使用できるようになりました。これによりアプリケーションでは、アプリケーションの必要を満たす最善のトランスポートモデルや計算モデルを自由に選択することができます。この新しい抽象化により、非ブロック入出力チャネルや他の入出力モデルをアプリケーションで使用できるだけでなく、異なるスレッドモデルにも対応することができます。事実上これは、入出力とスレッドの決定がアプリケーションに委ねられることになります。こうした柔軟性に対応するため、これからのアプリケーションは、それ自体が複雑な問題でもある入出力とスレッドを管理するとともに、SSL/TLS プロトコルをある程度理解する能力を持つ必要があります。このように、新しい抽象化は高度な API なので、初心者は引き続き SSLSocket を使用してください。

API を初めて使用する人は、「java.nio.channels.SocketChannel を拡張する SSLSocketChannel だけにしたらどうか」と考えることもあるでしょう。そうしない主な理由は 2 つあります。

  • クラス階層、および Selector や他のタイプの SocketChannel との相互動作方法など、SSLSocketChannel をどのような API にすべきかということに関して、難問が数多くありました。SSL/TLS に対応するために拡張された新しい API 抽象化は、どれも同じほど重要な分析が必要となり、大規模で複雑な API になる可能性のあることが判明しました。

  • 新しい API のすべての JSSE 実装では、最善の入出力および計算戦略を自由に選択することになりましたが、これらの詳細事項を隠すことは、全面的な制御権を必要とするアプリケーションにとっては不適切です。どんな固有の実装方法も、アプリケーションセグメントによっては適さない場合があります。
入出力を抽象化し、データをバイトのストリームとして処理することによってこれらの問題を解決した結果、新しい API は既存または将来のどんな入出力モデルでも使用できるようになりました。このソリューションでは、入出力と CPU の処理が開発者に任されますが、構成不能または変更不能な内部の詳細設定によって JSSE 実装を使用できなくなるような状況を防止しています。

JGSS や SASL など、他の Java プログラミング言語 API のユーザーは、アプリケーションがデータをトランスポートする機能を果たすという類似点があることに気付くでしょう。

SSLEngine

この新しい抽象化方法のコアクラスは、javax.net.ssl.SSLEngine です。このコアクラスは、SSL/TLS 状態マシンをカプセル化し、SSLEngine のユーザーによって供給されるインバウンドとアウトバウンドのバイトバッファー上で動作します。次の図は、アプリケーションから送り出され、SSLEngine とトランスポート機構を経て再び戻ってくるデータフローの様子を示しています。

SSLEngine

左側に示されるアプリケーションは、アプリケーションのプレーンテキストデータをアプリケーションバッファーに供給し、SSLEngine に渡します。SSLEngine は、バッファーに格納されているデータまたはハンドシェークデータを処理して SSL/TLS 符号化データを生成し、アプリケーションによって提供されるネットワークバッファーに格納します。次にアプリケーションは、右側に示されている適切なトランスポートを使用して、ネットワークバッファーの内容をピアに送信する役割を実行します。トランスポートを介してピアから SSL/TLS 符号化データを受け取ると、アプリケーションはそのデータをネットワークバッファーに格納し、SSLEngine に渡します。SSLEngine は、ネットワークバッファーの内容を処理し、ハンドシェークデータまたはアプリケーションデータを生成します。

SSLEngine は、全体として次に示す 5 つの状態のいずれかの状態を示します。

  1. 作成 - 設定準備完了
  2. 初期ハンドシェーク - 認証の実行と通信パラメータのネゴシエーション
  3. アプリケーションデータ - アプリケーションの交換準備完了
  4. 再ハンドシェーク - 通信パラメータ/認証情報の再ネゴシエーション。 ハンドシェーク情報はアプリケーションデータと混合可能
  5. 閉鎖 - 接続のシャットダウン準備完了
これらの 5 つの状態の詳細については、SSLEngine クラスの資料を参照してください。

入門

SSLEngine を作成するには、SSLContext.createSSLEngine() メソッドを使用します。次に、クライアントまたはサーバーとして動作するようにエンジンを設定し、使用する符号化方式やクライアント認証が必要かどうかなどの他の設定パラメータも設定します。

次に SSLEngine の作成例を示します。サーバー名とポート番号は、サーバーとの通信には使用されません。 すべてのトランスポートはアプリケーションによって実行されます。以下の作成例は、SSL セッションキャッシングの場合、および取得するサーバー資格を決定する Kerberos ベースの符号化方式が実装されている場合に使用する、JSSE プロバイダへのヒントです。

import javax.net.ssl.*;
import java.security.*;

// Create/initialize the SSLContext with key material

char[] passphrase = "passphrase".toCharArray();

// First initialize the key and trust material.
KeyStore ksKeys = KeyStore.getInstance("JKS");
ksKeys.load(new FileInputStream("testKeys"), passphrase);
KeyStore ksTrust = KeyStore.getInstance("JKS");
ksTrust.load(new FileInputStream("testTrust"), passphrase);

// KeyManager's decide which key material to use.
KeyManagerFactory kmf =
    KeyManagerFactory.getInstance("SunX509");
kmf.init(ksKeys, passphrase);

// TrustManager's decide whether to allow connections.
TrustManagerFactory tmf =
    TrustManagerFactory.getInstance("SunX509");
tmf.init(ksTrust);

sslContext = SSLContext.getInstance("TLS");
sslContext.init(
    kmf.getKeyManagers(), tmf.getTrustManagers(), null);

// We're ready for the engine.
SSLEngine engine = sslContext.createSSLengine(hostname, port);

// Use as client
engine.setUseClientMode(true);

SSL/TLS データの生成と処理

SSLEngine の主要な 2 つのメソッドである wrap()unwrap() により、それぞれネットワークデータが生成および消費されます。SSLEngine の状態に応じて、このデータはハンドシェークデータかアプリケーションデータになります。

それぞれの SSLEngine には、ライフタイムを通じて数種類の段階があります。アプリケーションデータを送信/受信できるようにするには、SSL/TLS プロトコルに従ってハンドシェークを実行し、暗号化パラメータを確定する必要があります。このハンドシェークでは、SSLEngine による一連のデータやり取り手順が必要です。ハンドシェーク自体の詳細については、「SSL プロセス」を参照してください。

初期ハンドシェーク時に、wrap()unwrap() はハンドシェークデータを生成および消費し、アプリケーションはデータをトランスポートする役割を担います。wrap()/unwrap() シーケンスは、ハンドシェークが終了するまで繰り返されます。それぞれの SSLEngine 動作により SSLEngineResult が生成され、SSLEngineResult の SSLEngineResult.HandshakeStatus フィールドは、ハンドシェークを続行するために実行する必要のある以下の動作を決定するために使用されます。

標準的なハンドシェークでは次のような動作が行われます。

 クライアント  SSL/TLS メッセージ  HSStatus
 wrap()  ClientHello  NEED_UNWRAP
 unwrap()  ServerHello/Cert/ServerHelloDone  NEED_WRAP
 wrap()  ClientKeyExchange  NEED_WRAP
 wrap()  ChangeCipherSpec  NEED_WRAP
 wrap()  Finished  NEED_UNWRAP
 unwrap()  ChangeCipherSpec  NEED_UNWRAP
 unwrap()  Finished  FINISHED
これでハンドシェークが完了します。 さらに wrap() への別の呼び出しがあると、アプリケーションデータおよびパッケージを消費してトランスポートしようとします。 unwrap() は反対の動作を試みます。

ピアにデータを送信するには、まずアプリケーションが送信するデータを SSLEngine.wrap() を介して SSLEngine に送信し、対応する SSL/TLS 符号化データを取得します。次にアプリケーションは、選択したトランスポート機構を使用して符号化データをピアに送信します。アプリケーションは、トランスポート機構を介してピアから SSL/TLS 符号化データを受け取ると、SSLEngine.unwrap() を介してそのデータを SSLEngine に送り、ピアによって送信されたプレーンテキストデータを取得します。

非ブロック SocketChannel を使用してピアと通信する SSL アプリケーションの例を次に示します。SSL アプリケーションは、非ブロック SocketChannel を組み込んだ Selector を使用することにより、堅牢性と拡張性を高めることができます。以下のサンプルコードは、前の例で作成した SSLEngine を使用して符号化することにより、ピアに文字列 「hello」 を送信します。バイトバッファーのサイズは、SSLSession からの情報を使用して決定されます。

// Create a non-blocking socket channel
SocketChannel socketChannel = SocketChannel.open();
socketChannel.configureBlocking(false);
socketChannel.connect(new InetSocketAddress(hostname, port));

// Complete connection
while (!socketChannel.finishedConnect()) {
    // do something until connect completed
}

// Create byte buffers to use for holding application and encoded data
SSLSession session = engine.getSession();
ByteBuffer myAppData = ByteBuffer.allocate(session.getApplicationBufferSize());
ByteBuffer myNetData = ByteBuffer.allocate(session.getPacketBufferSize());
ByteBuffer peerAppData = ByteBuffer.allocate(session.getApplicationBufferSize());
ByteBuffer peerNetData = ByteBuffer.allocate(session.getPacketBufferSize());

// Do initial handshake
doHandshake(socketChannel, engine, myNetData, peerNetData);

myAppData.put("hello".getBytes());
myAppData.flip();

while (myAppData.hasRemaining()) {
    // Generate SSL/TLS encoded data (handshake or application data)
    SSLEngineResult res = engine.wrap(myAppData, myNetData);

    // Process status of call
    if (res.getStatus() == SSLEngineResult.Status.OK) {
        myAppData.compact();

        // Send SSL/TLS encoded data to peer
        while(myNetData.hasRemaining()) {
            int num = socketChannel.write(myNetData);
	    if (num == -1) {
	        // handle closed channel
	    } else if (num == 0) {
	        // no bytes written; try again later
	    }
        }
    }

    // Handle other status:  BUFFER_OVERFLOW, CLOSED
    ...
}

以下のコードは、非ブロック SocketChannel からデータを読み取り、前に作成した SSLEngine を使用して、そのデータからプレーンテキストを抽象化します。このコードが反復されるごとに、ハンドシェーク処理が進行しているかどうかに応じて、プレーンテキストが生成されたり、生成されなかったりします。
// Read SSL/TLS encoded data from peer
int num = socketChannel.read(peerNetData);
if (num == -1) {
    // Handle closed channel
} else if (num == 0) {
    // No bytes read; try again ...
} else {
    // Process incoming data
    peerNetData.flip();
    res = engine.unwrap(peerNetData, peerAppData);

    if (res.getStatus() == SSLEngineResult.Status.OK) {
        peerNetData.compact();

        if (peerAppData.hasRemaining()) {
            // Use peerAppData
        }
    }
    // Handle other status:  BUFFER_OVERFLOW, BUFFER_UNDERFLOW, CLOSED
    ...
}

動作のステータス

エンジンのステータスとアプリケーションに求められる動作の種類を示すため、SSLEngine.wrap() メソッドと SSLEngine.unwrap() メソッドは、前の例に示されるような SSLEngineResult インスタンスを返します。SSLEngineResult には、エンジンの全体的なステータスとハンドシェークのステータスで構成される 2 つのステータス情報があります。

全体的なステータスは、SSLEngineResult.Status enum によって表されます。たとえばこのステータスには、エラーがないことを意味する OK、入力バッファーのデータが不足しているために、アプリケーションはネットワークからデータを読み込むなどしてピアからもっとデータを取得する必要があることを示す BUFFER_UNDERFLOW、出力バッファーの結果を保持する領域が不足しているために、アプリケーションは出力先バッファーをクリアまたは拡大する必要があることを示す BUFFER_OVERFLOW などがあります。

次に、SSLEngine.unwrap()BUFFER_UNDERFLOW および BUFFER_OVERFLOW ステータスを処理する方法の例を示します。SSLSession.getApplicationBufferSize() および SSLSession.getPacketBufferSize() を使用して、バイトバッファーのサイズを決定します。

SSLEngineResult res = engine.unwrap(peerNetData, peerAppData);
switch (res.getStatus()) {

case BUFFER_OVERFLOW:
  // Maybe need to enlarge the peer application data buffer.
  if (engine.getSession().getApplicationBufferSize() >
          peerAppData.capacity()) {
      // enlarge the peer application data buffer
  } else {
        // compact or clear the buffer
  }
  // retry the operation
  break;

case BUFFER_UNDERFLOW:
  // Maybe need to enlarge the peer network packet buffer
  if (engine.getSession().getPacketBufferSize() >
          peerNetData.capacity()) {
      // enlarge the peer network packet buffer
  } else {
        // compact or clear the buffer
  }
  // obtain more inbound network data and then retry the operation
  break;

// Handle other status: CLOSED, OK
...
}

ハンドシェークのステータスは、SSLEngineResult.HandshakeStatus enum によって表されます。このステータスにより、ハンドシェークが完了しているかどうか、発信側はピアからさらにハンドシェークデータを取得する必要があるかどうか、またピアにもっとハンドシェークデータを送信する必要があるかどうかなどの状態を表します。

動作結果ごとに 2 種類のステータスを示すことにより、エンジンはアプリケーションで実行することが必要な 2 つの動作、つまりハンドシェークへの応答における動作と wrap()/unwrap() メソッドの全体的なステータスを表す動作を示すことができます。たとえばエンジンは、1 回の SSLEngine.unwrap() 呼び出しの結果として、SSLEngineResult.Status.OK を返して入力データが正常に処理されたことを示し、SSLEngineResult.HandshakeStatus.NEED_UNWRAP を返すことにより、ハンドシェークを継続するためにアプリケーションがピアからさらに SSL/TLS 符号化データを取得し、もう一度 SSLEngine.unwrap() に供給すべきことを示します。お気付きのとおり、先の例はかなり単純化されていますが、これらすべてのステータスを適正に処理するにはコードをかなり拡張する必要があります。

次に、wrap()/unwrap() メソッドのハンドシェークのステータスと全体的なステータスをチェックすることによって、ハンドシェークデータを処理する方法の例を示します。

void doHandshake(SocketChannel socketChannel, SSLEngine engine,
        ByteBuffer myNetData, ByteBuffer peerNetData) throws Exception {

    // Create byte buffers to use for holding application data
    int appBufferSize = engine.getSession().getApplicationBufferSize();
    ByteBuffer myAppData = ByteBuffer.allocate(appBufferSize);
    ByteBuffer peerAppData = ByteBuffer.allocate(appBufferSize);

    // Begin handshake
    engine.beginHandshake();
    SSLEngineResult.HandshakeStatus hs = engine.getHandshakeStatus();

    // Process handshaking message
    while (hs != SSLEngineResult.HandshakeStatus.FINISHED &&
        hs != SSLEngineResult.HandshakeStatus.NOT_HANDSHAKING) {

        switch (hs) {

        case NEED_UNWRAP:
            // Receive handshaking data from peer
            if (socketChannel.read(peerNetData) < 0) {
                // Handle closed channel
            }

            // Process incoming handshaking data
            peerNetData.flip();
            SSLEngineResult res = engine.unwrap(peerNetData, peerAppData);
            peerNetData.compact();
            hs = res.getHandshakeStatus();

            // Check status
            switch (res.getStatus()) {
            case OK :
                // Handle OK status
                break;

            // Handle other status: BUFFER_UNDERFLOW, BUFFER_OVERFLOW, CLOSED
            ...
            }
            break;

        case NEED_WRAP :
            // Empty the local network packet buffer.
            myNetData.clear();

            // Generate handshaking data
            res = engine.wrap(myAppData, myNetData);
            hs = res.getHandshakeStatus();

            // Check status
            switch (res.getStatus()) {
            case OK :
                myNetData.flip();

                // Send the handshaking data to peer
                while (myNetData.hasRemaining()) {
                    if (socketChannel.write(myNetData) < 0) {
                        // Handle closed channel
                    }
                }
                break;

            // Handle other status:  BUFFER_OVERFLOW, BUFFER_UNDERFLOW, CLOSED
            ...
            }
            break;

        case NEED_TASK :
	    // Handle blocking tasks
            break;

        // Handle other status:  // FINISHED or NOT_HANDSHAKING
        ...
        }
    }

    // Processes after handshaking
    ...
}

ブロックタスク

ハンドシェーク動作の間に、SSLEngine はブロックしたり処理に長い時間がかかったりするタスクに直面することがあります。たとえば、TrustManager はリモートの証明書検証サービスに接続する必要があり、KeyManager は、プロンプトを表示して、クライアント認証の一部として使用する証明書をユーザーに決定してもらう必要があります。SSLEngine は、エンジンの非ブロック性を回避するため、それらのタスクに直面した場合に SSLEngineResult.HandshakeStatus.NEED_TASK を返します。このステータスを受け取ると、アプリケーションは SSLEngine.getDelegatedTask() を呼び出してタスクを取得し、その要件に適したスレッドモデルを使用してタスクを処理します。アプリケーションは、たとえばスレッドプールからスレッドを入手してタスクを処理し、メインスレッドはほかの入出力の処理に取りかかります。

新しく作成されたスレッドでそれぞれのタスクを実行する例を次に示します。

if (res.getHandshakeStatus() == SSLEngineResult.HandshakeStatus.NEED_TASK) {
    Runnable task;
    while ((task=engine.getDelegatedTask()) != null) {
        new Thread(task).start();
    }
}
エンジンは、未処理のタスクすべてが完了するまで、wrap/unwrap 呼び出しをブロックします。

シャットダウン

SSL/TLS 接続を正しい順序でシャットダウンするため、SSL/TLS プロトコルではクローズメッセージを送信する必要があります。したがって、アプリケーションが SSL/TLS 接続を終了する場合は、最初に SSLEngine からクローズメッセージを取得し、トランスポート機構を使用してそれらのメッセージをピアに送信して、最後にトランスポート機構をシャットダウンします。次に例を示します。
// Indicate that application is done with engine
engine.closeOutbound();

while (!engine.isOutboundDone()) {
    // Get close message
    SSLEngineResult res = engine.wrap(empty, myNetData);

    // Check res statuses

    // Send close message to peer
    while(myNetData().hasRemaining()) {
        int num = socketChannel.write(myNetData);
	if (num == -1) {
	    // handle closed channel
	} else if (num == 0) {
	    // no bytes written; try again later
	}
	myNetData().compact();
    }
}

// Close transport
socketChannel.close();
SSLEngine を明示的にクローズするアプリケーションに加え、SSLEngine は、ハンドシェークデータを処理している間にクローズメッセージを受け取ることにより、ピアによってクローズされます。 または、アプリケーションデータまたはハンドシェークデータを処理している間にエラーが発生した SSLEngine によってクローズされます。そのエラーは、SSLException がスローされることによって示されます。 そのような場合アプリケーションは、SSLEngine.wrap() を呼び出してクローズメッセージを取得し、前の例に示されるように SSLEngine.isOutboundDone() が true 値を返すまで、または SSLEngineResult.getStatus() が CLOSED を返すまでそのメッセージをピアに送信します。

正常なシャットダウンに加え、クローズメッセージが交換される前にトランスポートリンクを切断する非常シャットダウン方法があります。前の例では、非ブロック SocketChannel からの読み取りまたは書き込みを実行しようとすると、アプリケーションは -1 を受け取ります。最後の入力データになったら、engine.closeInbound() を呼び出し、SSL/TLS の観点からはリモートのペアによって正常にクローズされた SSLEngine を検証してください。 その後アプリケーションは、上述の手順に従って正常なシャットダウンを試みます。SSLSocket とは異なり、SSLEngine を使用するアプリケーションは、SSLEngine を使用する場合よりも明らかに多くの状態移行、ステータス、およびプログラミングに対処する必要があります。SSLEngine ベースアプリケーションの作成方法については、「NIO ベースの HTTPS サーバー」を参照してください。

SSLSession インタフェース

javax.net.ssl.SSLSession は、SSLSocket/SSLEngine 接続の 2 つのピアの間で取り決めたセキュリティーコンテキストを表します。一度確立されたセッションは、同じ 2 つのピアの間で接続されるその後の SSLSocket/Engine によっても共有できます。セッションには暗号群が含まれます。これは、リモートピアのネットワークアドレスに関する権限のないヒントと同様、安全なソケットの通信でも使用され、作成や最後の使用の時点などで、管理情報としても使用されます。セッションには、SSLSocket/SSLEngine による通信を暗号化して整合性を保証する暗号鍵を作成するために使用される、ピア間で取り決めた共用マスターとなる秘密も含まれます。このマスターとなる秘密の値は、基盤となるセキュリティーソケット実装にだけ伝えられ、SSLSession API では公開されません。

SSLSession.getPacketBufferSize() および SSLSession.getApplicationBufferSize() の呼び出しも、SSLEngine によって使用される適切なバッファーサイズを決定するために使用されます。

注: SSL/TLS プロトコルは、実装が最大 16K バイトのプレーンテキストを含むパケットを生成することを指定します。ただし、一部の実装はこの指定に違反し、32K バイトまでの大きいレコードを生成します。SSLEngine.unwrap() コードが大きいインバウンドパケットを検出した場合、SSLSession から返されるバッファーサイズは動的に更新されます。アプリケーションは常に、必要に応じて BUFFER_OVERFLOW/BUFFER_UNDERFLOW のステータスをチェックして、対応するバッファーを拡大する必要があります。32K バイトの着信レコードを許可した場合でも、SunJSSE は常に標準に準拠した 16K バイトのレコードを送信します。回避策については、「カスタマイズ」のシステムプロパティー jsse.SSLEngine.acceptLargeFragments も参照してください。

HttpsURLConnection クラス

https プロトコルは http プロトコルに似ていますが、データを要求または受信する前に、まず SSL/TLS ソケットを利用して安全なチャネルを確立してピアの識別情報を検証します。 javax.net.ssl.HttpsURLConnectionjava.net.HttpsURLConnection クラスを拡張し、https に固有の機能をサポートします。https URL の構造と使用法の詳細については、java.net.URL, java.net.URLConnectionjava.net.HttpURLConnection、および javax.net.ssl.HttpURLConnection クラスを参照してください。

HttpsURLConnection を取得する際、URLConnection.connect メソッドを使って実際にネットワーク接続を開始する前に、複数の http/https パラメータを構成できます。これらについては、以下を参照してください。

割り当て済みの SSLSocketFactory の設定

状況によっては、HttpsURLConnection のインスタンスによって使用される SSLSocketFactory を指定したほうがよい場合があります。たとえば、デフォルト実装ではサポートされないプロキシを使ってトンネリングを行う場合がこれに該当します。新しい SSLSocketFactory は、すでに必要なトンネリングの完了したソケットを返すことができます。このため、HttpsURLConnection は追加のプロキシを使用することができます。

HttpsURLConnection クラスには、ロード時に割り当てられたデフォルトの SSLSocketFactory があります(特に SSLSocketFactory.getDefault によって返されたファクトリの場合)。以降、HttpsURLConnection のインスタンスは、static メソッド HttpsURLConnection.setDefaultSSLSocketFactory によってクラスに新しいデフォルトの SSLSocketFactory が割り当てられるまで、現在のデフォルトの SSLSocketFactory を継承します。HttpsURLConnection のインスタンスが作成されたあと、setSSLSocketFactory メソッドへの呼び出しにより、このインスタンス上の継承された SSLSocketFactory を上書きできます。

デフォルトの static メソッド SSLSocketFactory を変更しても、既存の HttpsURLConnections のインスタンスには何の影響もありません。既存のインスタンスを変更するには、setSSLSocketFactory メソッドを呼び出す必要があります。

getSSLSocketFactory メソッドまたは getDefaultSSLSocketFactory メソッドを呼び出すことにより、インスタンスごと、またはクラスごとに SSLSocketFactory を取得できます。

割り当て済みの HostnameVerifier の設定

URL のホスト名が SSL/TLS ハンドシェーク時に受け取ったクレデンシャルのホスト名と一致しない場合、URL Spoofing が発生している可能性があります。ホスト名の確実性に疑いが持たれる場合、SSL 実装は、インスタンスの割り当て済み HostnameVerifier のコールバックを実行します。こうすることで、より詳しいチェックを行うことができます。ホスト名識別子は、判定を下すために必要な処理を行います。その一環として、たとえばその他のホスト名パターンマッチングを実行したり、対話式のダイアログボックスを表示したりします。ホスト名ベリファイアによる検証に失敗した場合は、接続が切断されます。ホスト名の検証については、RFC 2818 を参照してください。

setHostnameVerifier メソッドおよび setDefaultHostnameVerifier メソッドは、setSSLSocketFactory メソッドおよび setDefaultSSLSocketFactory メソッドとよく似ています。これらの共通点は、インスタンスごと、またはクラスごとに HostnameVerifiers が割り当てられ、現在の値が getHostnameVerifier メソッドまたはgetDefaultHostnameVerifier メソッドによって取得されるという点です。

サポートクラスとインタフェース

この節で説明するクラスとインタフェースは、SSLContext オブジェクトの作成と初期化をサポートし、SSLSocketFactory、SSLServerSocketFactory オブジェクトと SSLEngine オブジェクトを作成するために提供されます。サポートクラスとインタフェースは javax.net.ssl パッケージに含まれています。

この節で説明するクラスは SSLContextKeyManagerFactory、および TrustManagerFactory の 3 つで、いずれもエンジンクラスです。エンジンクラスとは、特定のアルゴリズムの API クラス (SSLContext の場合はプロトコル) です。1 つまたは複数の暗号化サービスプロバイダ (プロバイダ) パッケージで実装が提供されることがあります。プロバイダとエンジンクラスの詳細は、「JavaTM 暗号化アーキテクチャーリファレンスガイド」の「設計方針」と「概念」のセクションを参照してください。

JSSE に標準で付属する SunJSSE プロバイダは、SSLContextKeyManagerFactory、および TrustManagerFactory 実装を提供し、標準の Java セキュリティー (java.security) API ではエンジンクラスの実装も提供します。SunJSSE が提供する実装は次のとおりです。

エンジンクラス        アルゴリズムまたは 
実装           プロトコル

KeyStore              "PKCS12"

KeyManagerFactory     "SunX509", "NewSunX509"

TrustManagerFactory   "PKIX" (aka "X509"/"SunPKIX"), "SunX509"

SSLContext            "SSLv3" (aka "SSL"), "TLSv1" (aka "TLS")
      

SSLContext クラス

javax.net.ssl.SSLContext は、安全なソケットプロトコルの実装のエンジンクラスです。このクラスのインスタンスは、SSL ソケットファクトリおよび SSL エンジンのファクトリとして動作します。SSLContext は、そのコンテキストの下で作成されたすべてのオブジェクトで共有される状態情報をすべて保持します。たとえば、セッションの状態は、ソケットファクトリにより作成され、コンテキストにより提供されたソケットによってハンドシェークプロトコルが取り決められると、SSLContext と関連付けられます。キャッシュに書き込まれたこれらのセッションは、同じコンテキストで作成された別のソケットで再利用したり共有することができます。

各インスタンスは、認証の実行に必要な鍵、証明書チェーン、および信頼されたルート CA 証明書を使って init メソッドで設定されます。この設定は、鍵とトラストマネージャーの形で提供されます。これらのマネージャーは認証をサポートし、コンテキストによってサポートされる暗号群の鍵の承認を提供します。

現在は、X.509 ベースのマネージャーだけがサポートされています。

SSLContext オブジェクトの作成

他の JCA プロバイダベースの「エンジン」クラスと同様に、SSLContext オブジェクトは、SSLContext クラスの getInstance ファクトリメソッドを使って作成されます。このような static メソッドは、最低限要求された安全なソケットプロトコルを実装するインスタンスを返します。返されるインスタンスも、その他のプロトコルを実装できます。たとえば、getInstance("SSLv3") から返されるインスタンスは、"SSLv3""TLSv1" を実装します。getSupportedProtocols メソッドは、このコンテキストから SSLSocket、SSLServerSocket または SSLEngine が作成されたときに、サポート対象のプロトコルのリストを返します。実際の SSL 接続でどのプロトコルを有効にするかは、setEnabledProtocols(String[] protocols) メソッドを使って制御できます。

注: SSLSocketFactory.getDefault を呼び出すと、SSLContext が自動的に作成され、インスタンス化され、SSLSocketFactory に静的に割り当てられます。したがって、デフォルト動作をオーバーライドする場合を除き、SSLContext オブジェクトを直接作成したり初期化したりする必要はありません。

getInstance ファクトリメソッドを呼び出して SSLContext オブジェクトを作成するには、プロトコル名を指定する必要があります。または、要求されたプロトコルの実装を提供するプロバイダを次のように指定することもできます。

public static SSLContext getInstance(String protocol);

public static SSLContext getInstance(String protocol,
String provider);

public static SSLContext getInstance(String protocol,
Provider provider);

プロトコル名だけを指定すると、システムは、要求されたプロトコルの実装がその環境で利用できるかどうかを判断します。複数の実装がある場合、より望ましいものがあるかどうかを判断します。

プロトコル名とプロバイダを指定すると、システムは、要求されたプロトコルの実装が要求されたプロバイダで利用できるかどうかを判断し、利用できない場合は例外をスローします。

プロトコルは、希望する安全なソケットプロトコルを記述する文字列 (「SSL」など) です。SSLContext オブジェクトの一般的なプロトコル名は、付録 A で定義されています。

次に SSLContext の取得例を示します。

SSLContext sc = SSLContext.getInstance("SSL");

新しく作成された SSLContext は、init メソッドを呼び出すことによって初期化する必要があります。

public void init(KeyManager[] km, TrustManager[] tm,
SecureRandom random);

KeyManager[] パラメータが NULL の場合、このコンテキストには空の KeyManager が定義されます。TrustManager[] パラメータが NULL の場合、インストールされたセキュリティープロバイダは、TrustManagerFactory のもっとも優先度の高い実装で検索され、適切な TrustManager が取得されます。同様に、SecureRandom パラメータも NULL にすることができます。その場合、デフォルト実装が使用されます。

内部のデフォルトコンテキストが使用される場合 (SSLContextSSLSocketFactory.getDefault() または SSLServerSocketFactory.getDefault() によって作成されるなど) は、デフォルトの KeyManagerTrustManager が作成されます。また、デフォルトの SecureRandom 実装も選択されます。

TrustManager Interface

TrustManager は、提示された認証クレデンシャルの信頼性を判定します。信頼できないクレデンシャルの場合、接続は切断されます。安全なソケットピアのリモート識別情報を認証するには、1 つまたは複数の TrustManagerSSLContext オブジェクトを初期化する必要があります。サポートされる認証機構のそれぞれに対し、TrustManager を 1 つ渡す必要があります。SSLContext の初期化中に NULL が渡されると、トラストマネージャーが作成されます。通常は、X.509 公開鍵証明書 (X509TrustManager など) に基づく認証をサポートする単一のトラストマネージャーが存在しています。安全なソケット実装には、共有の秘密鍵、Kerberos、またはその他の機構に基づく認証をサポートするものもあります。

TrustManagerTrustManagerFactory によって、またはインタフェースの具体的な実装を行うことによって作成されます。

TrustManagerFactory クラス

javax.net.ssl.TrustManagerFactory はプロバイダベースのサービスのエンジンクラスで、1 つまたは複数の型の TrustManager オブジェクトのファクトリとして動作します。これはプロバイダベースなので、さらにファクトリを実装して設定し、より高度なサービスを提供するトラストマネージャーや、インストール専用の認証ポリシーを実装するトラストマネージャーを追加したり、別に提供することができます。

TrustManagerFactory の作成

このクラスのインスタンスは SSLContext と同様の方法で作成しますが、getInstance メソッドにプロトコル名ではなくアルゴリズム名の文字列を渡す点が異なります。
public static TrustManagerFactory
getInstance(String algorithm);

public static TrustManagerFactory
getInstance(String algorithm,
String provider);

public static TrustManagerFactory
getInstance(String algorithm,
Provider provider);

アルゴリズム名文字列の例を次に示します。

"PKIX"

呼び出しの例を次に示します。

TrustManagerFactory tmf =
TrustManagerFactory.getInstance("PKIX", "SunJSSE");

上の呼び出しは、SunJSSE プロバイダの PKIX トラストマネージャーファクトリのインスタンスを作成します。このファクトリを使用して、X.509 PKIX ベースの証明書パス妥当性検査を実行するトラストマネージャーを作成できます。

SSLContext を初期化する場合は、トラストマネージャーファクトリから作成したトラストマネージャーを使用するか、CertPath API などを使用して独自のトラストマネージャーを記述することができます。詳細については、「JavaTM Certification Path API プログラマーズガイド」を参照してください。X509TrustManager インタフェースを使用してトラストマネージャーを実装する場合は、トラストマネージャーファクトリは不要です。

新しく作成されたファクトリは、init メソッドの 1 つを呼び出すことによって初期化する必要があります。

public void init(KeyStore ks);
public void init(ManagerFactoryParameters spec);

使用する TrustManagerFactory に適切な init メソッドを呼び出す必要があります。プロバイダのベンダーに問い合わせてください。

「SunX509」TrustManagerFactory など、SunJSSE プロバイダが提供するファクトリは多数ありますが、TrustManagerFactory を初期化するために必要な情報は KeyStore だけなので、最初に init メソッドを呼び出すのが適切です。TrustManagerFactoryKeyStore に、認証チェック中に信頼すべきリモート証明書の情報を問い合わせます。

場合によっては、KeyStore 以外の初期化パラメータがプロバイダに必要になります。特定のプロバイダの利用者は、プロバイダによる定義に従って、適切な ManagerFactoryParameters の実装を渡す必要があります。その後、プロバイダは ManagerFactoryParameters 実装の特定のメソッドを呼び出し、必要な情報を取得できます。

たとえば、TrustManagerFactory プロバイダが、そのプロバイダを使うアプリケーションの初期化パラメータ B、R、および S を必要としているとします。KeyStore 以外の初期化パラメータを要求するすべてのプロバイダと同様に、プロバイダはアプリケーションが ManagerFactoryParameters の特定のサブインタフェースを実装するクラスのインスタンスを提供することを要求します。たとえば、呼び出し側のアプリケーションが MyTrustManagerFactoryParams のインスタンスを実装して作成し、2 つ目の init に渡すようプロバイダが要求しているとします。この場合の MyTrustManagerFactoryParams の状態を次に示します。

public interface MyTrustManagerFactoryParams extends 
ManagerFactoryParameters {
public boolean getBValue();
public float getRValue();
public String getSValue():
}

KeyStore オブジェクトやその他のパラメータで明示的に初期化されなくても、トラストが決定できるトラストマネージャーもあります。そのようなマネージャーは、たとえば、LDAP 経由でローカルディレクトリサービスのトラストデータにアクセスしたり、オンラインの証明書状態チェックサーバーをリモートで使用したり、または標準のローカル位置からデフォルトのトラストデータにアクセスすることもできます。

PKIX TrustManager のサポート

デフォルトのトラストマネージャーのアルゴリズムは「PKIX」です。デフォルトは、java.security ファイルの ssl.TrustManagerFactory.algorithm プロパティーを編集することによって変更できます。

PKIX トラストマネージャーファクトリは、インストールされたセキュリティープロバイダからの CertPath PKIX 実装を使用します。「SUN」CerPath プロバイダは Java SE Development Kit 6 に付属しています。トラストマネージャーファクトリは、通常の init(KeyStore ks) メソッドを使用するか、または新しく導入されたクラス javax.net.ssl.CertPathTrustManagerParameters を使用して CertPath パラメータを PKIX トラストマネージャーに渡すことにより初期化できます。

トラストマネージャーを取得して特定の LDAP 証明書ストアを使用する方法と、取り消し確認を有効にする方法の例を次に示します。

import javax.net.ssl.*;
import java.security.cert.*;
import java.security.KeyStore;
...

// Create PKIX parameters
KeyStore anchors = KeyStore.getInstance("JKS");
anchors.load(new FileInputStream(anchorsFile));
CertPathParameters pkixParams = new PKIXBuilderParameters(anchors,
    new X509CertSelector());

// Specify LDAP certificate store to use
LDAPCertStoreParameters lcsp = new LDAPCertStoreParameters("ldap.imc.org", 389);
pkixParams.addCertStore(CertStore.getInstance("LDAP", lcsp));

// Specify that revocation checking is to be enabled
pkixParams.setRevocationEnabled(true);

// Wrap them as trust manager parameters
ManagerFactoryParameters trustParams =
    new CertPathTrustManagerParameters(pkixParams);

// Create TrustManagerFactory for PKIX-compliant trust managers
TrustManagerFactory factory = TrustManagerFactory.getInstance("PKIX");

// Pass parameters to factory to be passed to CertPath implementation
factory.init(trustParams);

// Use factory
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(null, factory.getTrustManagers(), null);

init (KeyStore ks) メソッドが使用される場合は、取り消し確認が無効にされる点を除いて、デフォルトの PKIXParameter が使用されます。有効にするには、システムプロパティー com.sun.net.ssl.checkRevocationtrue に設定します。この設定では、CertPath 実装自身が取り消し情報の場所を検出する必要があります。SUN プロバイダの PKIX 実装では多くの場合にこの動作を実行できますが、システムプロパティー com.sun.security.enableCRLDPtrue に設定する必要があります。

PKIX および CertPath API の詳細については、「Java Certificate Path API プログラミングガイド」 を参照してください。

X509TrustManager インタフェース

javax.net.ssl.X509TrustManager インタフェースは、汎用の TrustManager インタフェースを拡張したものです。X. 509ベースの認証を行う際、トラストマネージャーは必ずこのインタフェースを実装します。

JSSE を使ったリモートソケットピアの X.509 認証をサポートするには、このインタフェースのインスタンスを SSLContext オブジェクトの init メソッドに渡す必要があります。

X509TrustManager の作成

このインタフェースは、自分で直接実装することも、SunJSSE プロバイダなど、プロバイダベースの TrustManagerFactory から取得することもできます。また、独自のインタフェースを実装して、ファクトリで生成されたトラストマネージャーに委譲することもできます。たとえば、結果として生じたトラストの決定をフィルタにかけ、GUI を使ってエンドユーザーに問い合わせる場合に、これを実行します。

注: null の KeyStore パラメータが SunJSSE の「PKIX」または「SunX509」TrustManagerFactory に渡される場合、ファクトリは次の手順でトラストデータを検索します。

  1. システムプロパティー
    javax.net.ssl.trustStore
    が定義されている場合、TrustManagerFactory は、このシステムプロパティーで指定したファイル名を使ってファイルを検索し、このファイルをキーストアで使用します。システムプロパティー javax.net.ssl.trustStorePassword が同様に定義されている場合は、ファイルを開く前に、その値を使ってトラストストアのデータの整合性をチェックします。

    javax.net.ssl.trustStore が定義されているものの、指定したファイルが存在しない場合、空のキーストアを使用するデフォルトの TrustManager が作成されます。

  2. javax.net.ssl.trustStore システムプロパティーが指定されておらず、さらにファイル
    <java-home>/lib/security/jssecacerts
    が存在すれば、そのファイルを使用します。<java-home> の詳細については、「インストールディレクトリ <java-home>」を参照してください。それ以外の場合、

  3. ファイル
    <java-home>/lib/security/cacerts
    が存在すれば、そのファイルを使用します。

どのファイルも存在しない場合、それは匿名の SSL 暗号群があるためと考えられます。この暗号群は認証を行わないので、トラストストアは必要ありません。

ファクトリは、セキュリティープロパティー javax.net.ssl.trustStore 経由で指定したファイル、または jssecacerts ファイルを検索して cacerts ファイルをチェックし、信頼されたルート証明書の JSSE 固有のセットを、コードに署名する目的で、cacerts にあるものとは別に提供できるようにします。

独自の X509TrustManager の作成

指定した X509TrustManager の動作がニーズに合わない場合は、独自の X509TrustManager を作成できます。 方法としては、独自の TrustManagerFactory を作成および登録する方法と、X509TrustManager インタフェースを直接実装する方法があります。

以下の MyX509TrustManager クラスは、デフォルトの SunJSSE X509 TrustManager が失敗したとき、その他の認証ロジックを提供することによって、デフォルトの動作を拡張します。

class MyX509TrustManager implements X509TrustManager {

     /*
      * The default PKIX X509TrustManager9.  We'll delegate
      * decisions to it, and fall back to the logic in this class if the
      * default X509TrustManager doesn't trust it.
      */
     X509TrustManager pkixTrustManager;

     MyX509TrustManager() throws Exception {
         // create a "default" JSSE X509TrustManager.

         KeyStore ks = KeyStore.getInstance("JKS");
         ks.load(new FileInputStream("trustedCerts"),
             "passphrase".toCharArray());

         TrustManagerFactory tmf =
		TrustManagerFactory.getInstance("PKIX");
         tmf.init(ks);

         TrustManager tms [] = tmf.getTrustManagers();

         /*
          * Iterate over the returned trustmanagers, look
          * for an instance of X509TrustManager.  If found,
          * use that as our "default" trust manager.
          */
         for (int i = 0; i < tms.length; i++) {
             if (tms[i] instanceof X509TrustManager) {
                 pkixTrustManager = (X509TrustManager) tms[i];
                 return;
             }
         }

         /*
          * Find some other way to initialize, or else we have to fail the
          * constructor.
          */
         throw new Exception("Couldn't initialize");
     }

     /*
      * Delegate to the default trust manager.
      */
     public void checkClientTrusted(X509Certificate[] chain, String authType)
                 throws CertificateException {
         try {
             pkixTrustManager.checkClientTrusted(chain, authType);
         } catch (CertificateException excep) {
             // do any special handling here, or rethrow exception.
         }
     }

     /*
      * Delegate to the default trust manager.
      */
     public void checkServerTrusted(X509Certificate[] chain, String authType)
                 throws CertificateException {
         try {
             pkixTrustManager.checkServerTrusted(chain, authType);
         } catch (CertificateException excep) {
             /*
              * Possibly pop up a dialog box asking whether to trust the
              * cert chain.
              */
         }
     }

     /*
      * Merely pass this through.
      */
     public X509Certificate[] getAcceptedIssuers() {
         return pkixTrustManager.getAcceptedIssuers();
     }
}
        
このようなトラストマネージャーを作成できたら、init メソッドを使って、これを SSLContext に割り当てます。以降、この SSLContext から作成された SocketFactories は、ユーザー独自の TrustManager を使用して信頼性を判定するようになります。
TrustManager[] myTMs = new TrustManager [] {
                          new MyX509TrustManager() };
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(null, myTMs, null);

keyStore の動的更新

MyX509TrustManager を拡張して、キーストアの動的更新処理を行うことができます。checkClientTrusted または checkServerTrusted のテストに失敗し、信頼できる証明書チェーンを確立できなかった場合、キーストアに対して、要求された信頼できる証明書を追加できます。更新されたキーストアを使用して初期化された TrustManagerFactory から新しい pkixTrustManager を作成する必要があります。以前に初期化した SSLContext を使って新しい接続を確立すると、新しく追加された証明書が呼び出され、信頼性の判定が行われます。

KeyManager Interface

KeyManager は、最終的にリモートホストに送信される認証クレデンシャルを選択します。自分自身 (ローカルのセキュリティーソケットピア) をリモートピアに認証させるには、1 つまたは複数の KeyManagerSSLContext オブジェクトを初期化する必要があります。 サポートされる各認証機構に、KeyManager を 1 つ渡す必要があります。SSLContext の初期化中に NULL が渡されると、空の KeyManager が作成されます。内部のデフォルトコンテキストが使用される場合 (SSLContextSSLSocketFactory.getDefault() または SSLServerSocketFactory.getDefault() によって作成されるなど) は、デフォルトの KeyManager が作成されます。通常は、X.509 公開鍵証明書に基づく認証をサポートするキーマネージャーが 1 つあります。安全なソケット実装には、共有の秘密鍵、Kerberos、またはその他の機構に基づく認証をサポートするものもあります。

KeyManagerKeyManagerFactory によって、またはインタフェースの具体的な実装を行うことによって作成されます。

KeyManagerFactory クラス

javax.net.ssl.KeyManagerFactory はプロバイダベースのサービスのエンジンクラスで、1 つまたは複数の型の KeyManager オブジェクトのファクトリとして動作します。SunJSSE プロバイダは、基本となる X.509 キーマネージャーを返すことができるファクトリを実装します。これはプロバイダベースであるため、追加のファクトリを実装し、設定することにより、追加の、または代替のキーマネージャーを提供できます。

KeyManagerFactory の作成

このクラスのインスタンスは SSLContext と同様の方法で作成しますが、getInstance メソッドにプロトコル名ではなくアルゴリズム名の文字列を渡す点が異なります。
public static KeyManagerFactory
getInstance(String algorithm);

public static KeyManagerFactory
getInstance(String algorithm,
String provider);

public static KeyManagerFactory
getInstance(String algorithm,
Provider provider);

アルゴリズム名文字列の例を次に示します。

"SunX509"

呼び出しの例を次に示します。

KeyManagerFactory kmf =
KeyManagerFactory.getInstance("SunX509", "SunJSSE");

上記の呼び出しで SunJSSE プロバイダのデフォルトのキーマネージャーファクトリのインスタンスが作成されます。キーマネージャーファクトリは、基本となる X.509 ベースの認証キーを提供します。

新しく作成されたファクトリは、init メソッドの 1 つを呼び出すことによって初期化する必要があります。

public void init(KeyStore ks, char[] password);
public void init(ManagerFactoryParameters spec);

使用する KeyManagerFactory に適切な init メソッドを呼び出します。プロバイダのベンダーに問い合わせてください。

デフォルトの「SunX509」KeyManagerFactory など、SunJSSE プロバイダが提供するファクトリは多数ありますが、KeyManagerFactory を初期化するために必要な情報は KeyStore とパスワードだけなので、最初に init メソッドを呼び出すのが適切です。KeyManagerFactoryKeyStore に、リモートのソケットピアを認証するために使用する非公開鍵、および対応する公開鍵証明書について問い合わせます。パスワードパラメータは、KeyStore の鍵にアクセスするメソッドで使用するパスワードを指定します。KeyStore の鍵はすべて、同じパスワードで保護する必要があります。

プロバイダには、KeyStore とパスワード以外の初期化パラメータが必要な場合もあります。特定のプロバイダの利用者は、プロバイダによる定義に従って、適切な ManagerFactoryParameters の実装を渡す必要があります。その後、プロバイダは ManagerFactoryParameters 実装の特定のメソッドを呼び出し、必要な情報を取得できます。

ある種のファクトリでは、KeyStore オブジェクトやその他のパラメータで初期化されなくても、認証データにアクセスできます。たとえば、Java 認証・承認サービス (JAAS) などのログイン機構の一部として鍵データにアクセスできる場合があります。

上で述べたように、SunJSSE プロバイダは「SunX509」ファクトリをサポートします。ファクトリは、KeyStore パラメータで初期化する必要があります。

X509KeyManager インタフェース

javax.net.ssl.X509KeyManager インタフェースは、汎用の KeyManager インタフェースを拡張したものです。X.509 ベースの認証を行うキーマネージャーで実装します。JSSE を使ったリモートソケットピアの X.509 認証をサポートするには、このインタフェースのインスタンスを SSLContext オブジェクトの init メソッドに渡す必要があります。

X509KeyManager の作成

このインタフェースは、自分で直接実装することも、SunJSSE プロバイダなど、プロバイダベースの KeyManagerFactory から取得することもできます。また、独自のインタフェースを実装して、ファクトリで生成されたキーマネージャーに委譲することもできます。たとえば、生成される鍵をフィルタにかけ、GUI を使ってエンドユーザーに問い合わせる場合に、これを実行します。

独自の X509KeyManager の作成

X509KeyManager のデフォルトの動作がニーズに合わない場合は、「独自の X509TrustManager の作成」と同様の手順で独自の X509KeyManager を作成できます。

TrustManagerKeyManager の関連性

これまでは、TrustManagerKeyManager の機能がしばしば混同されてきました。 ここでは、各マネージャー型の主な機能を要約します。
機能
TrustManager リモート認証クレデンシャルの信頼性 (すなわち接続の信頼性) を判定します。
KeyManager リモートホストに送信される認証クレデンシャルを決定します。

二次サポートクラスおよびインタフェース

二次サポートクラスは、安全なソケットの作成、使用、および管理をサポートする JSSE API の一部として提供されます。このクラスは、セキュリティーソケットアプリケーションでは、コアクラスやサポートクラスほどには使用されません。二次サポートクラスおよびインタフェースは javax.net.ssl および javax.security.cert パッケージに含まれています。

SSLSessionContext インタフェース

javax.net.ssl.SSLSessionContext は、単一のエンティティーに関連付けられた SSLSession をグループ化したものです。たとえば、多数のセッションに同時に参加するサーバーやクライアントに関連付けることができます。このインタフェースのメソッドを使うと、コンテキストの全セッションを列挙したり、セッション ID で特定のセッションを検索することができます。

SSLSessionContext は、SSLSession の getSessionContext メソッドを呼び出して SSLSession から任意に取得することもできます。一部の環境では、コンテキストが利用できません。それは、getSessionContext メソッドが NULL を返す場合です。

SSLSessionBindingListener インタフェース

javax.net.ssl.SSLSessionBindingListener は、SSLSession からバインドまたはアンバインドされるときに通知を受けるオブジェクトによって実装されます。

SSLSessionBindingEvent クラス

javax.net.ssl.SSLSessionBindingEvent は、SSLSession からバインドまたはアンバインドされるときに、SSLSessionBindingListener と通信するイベントです。

HandShakeCompletedListener インタフェース

javax.net.ssl.HandShakeCompletedListener は、SSLSocket 接続時に SSL プロトコルハンドシェークの完了通知を受け取る任意のクラスに実装されるインタフェースです。

HandShakeCompletedEvent クラス

javax.net.ssl.HandShakeCompletedEvent は、SSLSocket 接続の SSL プロトコルハンドシェークが終了したときに HandShakeCompletedListener と通信するイベントです。

HostnameVerifier インタフェース

SSL/TLS 実装の標準ホスト名検証ロジックが失敗した場合、実装は、このインタフェースを実装し、この HttpsURLConnection インスタンスに割り当てられたクラスの verify メソッドを呼び出します。所定のパラメータがホスト名を受け付けることが明らかな場合、コールバッククラスは、接続が許可されることを報告する必要があります。応答が受け付けられない場合、接続は切断されます。

例を示します。

public class MyHostnameVerifier implements HostnameVerifier {

public boolean verify(String hostname, SSLSession session) {
// pop up an interactive dialog box
// or insert additional matching logic
if (good_address) {
return true;
} else {
return false;
}
}
}

//...deleted...

HttpsURLConnection urlc = (HttpsURLConnection)
(new URL("https://www.sun.com/")).openConnection();
urlc.setHostnameVerifier(new MyHostnameVerifier());
HostnameVerifierHttpsURLConnection に割り当てる方法については、HttpsURLConnection クラス」を参照してください。

X509Certificate クラス

安全なソケットプロトコルの多くは、X.509 証明書という公開鍵証明書を使って認証を行います。これは、SSL および TLS プロトコルのデフォルト認証機構です。

java.security.cert.X509Certificate 抽象クラスは、X.509 証明書の属性にアクセスする標準的な方法を提供します。

注: javax.security.cert.X509Certificate クラスは、以前のバージョンの JSSE (1.0.x、1.1.x) との後方互換性を確保するためのものです。新しいアプリケーションでは java.security.cert.X509Certificate を使用し、javax.security.cert.X509Certificate は使用しません。

旧バージョン (JSSE 1.0.x) の実装クラスおよびインタフェース

JSSE の旧バージョン (1.0.x) にはリファレンス実装があり、その実装では、クラスおよびインタフェースが com.sun.net.ssl パッケージで提供されました。

v 1.4 の時点で、JSSE は J2SDK に統合されています。従来 com.sun.net.ssl パッケージにあったクラスは、javax.net.ssl パッケージに移動し、現在では標準の JSSE API に含まれています。

com.sun.net.ssl のクラスとインタフェースは下位互換のために存在しているので、使用しないようお勧めします。これらのクラスとインタフェースを使って記述したアプリケーションは、再コンパイルせずに v 1.4 以降の J2SDK で実行することができます。今後のリリースでは、このクラスとインタフェースは削除される可能性があります。そのため、新しいアプリケーションはすべて javax のクラスとインタフェースを使って書く方がよいでしょう。

現在のところ、com.sun.net.ssl API を使用して作成したアプリケーションは、com.sun.net.ssl を使用する JSSE 1.0.2 プロバイダ、または javax API を使用する v 1.4 以降の J2SDK 用に記述された JSSE プロバイダのどちらでも利用できます。ただし、J2SDK v 1.4 以降の JSSE API を使って作成したアプリケーションは、v 1.4 以降の J2SDK 用に記述された JSSE プロバイダしか利用できません。新しいリリースには何らかの新機能が含まれるので、対応していないプロバイダではそうした新機能は利用できません。SunJSSE は Sun Microsystems の J2SDK で提供されるプロバイダで、javax API で作成されています。

JSSE 1.0.2 を使用している場合のように java.protocol.handler.pkgs System プロパティーを設定して URL 検索パスを更新すれば、引き続き com.sun.net.ssl.HttpsURLConnection を取得できます。 詳細については、トラブルシューティングのHttpsURLConnection クラスを使用するコード」を参照してください。


JSSE のカスタマイズ

インストールディレクトリ<java-home>

このマニュアルでは、<java-home> は、Java SE 6 Runtime Environment (JRE) がインストールされているディレクトリを表します。ディレクトリは、JSSE を実行しているのが、JavaTM SDK をインストールした JRE か、インストールしていない JRE かによって異なります。Java SE 6 SDK には JRE が含まれていますが、ファイル階層のレベルは異なります。

<java-home> が表すディレクトリの例を、次に示します。

  • Solaris で、Java SE 6 SDK のインストール先が /home/user1/jdk1.6.0 の場合、<java-home> は次の場所です。
    /home/user1/jdk1.6.0/jre

  • Solaris で、JRE が /home/user1/jre1.6.0 にインストールされており、Java 2 SDK がインストールされていない場合、<java-home> は次の場所です。
    /home/user1/jre1.6.0

  • Microsoft Windows で、Java SE 6 SDK のインストール先が C:\jdk1.6.0 の場合、<java-home> は次の場所です。
    C:\j2k1.6.0\jre

  • Microsoft Windows で、JRE が C:\jre1.6.0 にインストールされており、Java SE 6 SDK がインストールされていない場合、<java-home> は次の場所です。
    C:\jre1.6.0

カスタマイズ

JSSE には、すべてのユーザーが使用できる実装が含まれています。必要であれば、JSSE のさまざまな機能を変更して異なる実装を追加したり、デフォルトのキーストアを指定することもできます。次の表は、カスタマイズできる機能、デフォルト設定、およびカスタマイズの提供に使用する機構をまとめたものです。表の最初の列には、指定した機能と、カスタマイズ方法の詳細が説明されているサイトへのリンクが設定してあります。

一部の機能は、システムプロパティーやセキュリティープロパティーの値を設定してカスタマイズできます。表に続く節では、プロパティー値の設定方法について説明します。


重要: この表に示すプロパティーの多くは、現在 JSSE 実装で使用されていますが、それらの名前や型 (システムまたはセキュリティー) が今後も変更されないという保証はなく、それが将来のリリースに存在するという保証もありません。変更や廃止の可能性があるプロパティーには「*」が付いています。ここでは、JSSE 実装で使用する場合の参考として、それらに言及しています。
JSSE のカスタマイズ

カスタマイズ項目

デフォルト設定

カスタマイズ方法

X509Certificate 実装

Sun Microsystems の X509Certificate 実装

cert.provider.x509v1セキュリティープロパティー

HTTPS プロトコル実装

Sun Microsystems の実装

java.protocol.handler.pkgs システムプロパティー

プロバイダ実装

SunJSSE

セキュリティープロパティーファイルの security.provider.n= 行。説明を参照

デフォルトの SSLSocketFactory 実装

Sun Microsystems からの SSLSocketFactory 実装

** ssl.SocketFactory.provider セキュリティープロパティー

デフォルトの SSLServerSocketFactory 実装

Sun Microsystems からの SSLServerSocketFactory 実装

** ssl.ServerSocketFactory.provider セキュリティープロパティー

デフォルトのキーストア

デフォルトは存在しない

* javax.net.ssl.keyStore システムプロパティー。
NONE を指定可能。この設定は、ハードウェアトークンに存在する場合など、キーストアがファイルベースでない場合に適切

デフォルトのキーストアパスワード

デフォルトは存在しない

* javax.net.ssl.keyStorePassword システムプロパティー

デフォルトのキーストアプロバイダ

デフォルトは存在しない

* javax.net.ssl.keyStoreProvider システムプロパティー

デフォルトのキーストア型

KeyStore.getDefaultType()

* javax.net.ssl.keyStoreType システムプロパティー

デフォルトのトラストストア

存在する場合は jssecacerts。存在しない場合は cacerts

* javax.net.ssl.trustStore システムプロパティー

デフォルトのトラストストアパスワード

デフォルトは存在しない

* javax.net.ssl.trustStorePassword システムプロパティー

デフォルトのトラストストアプロバイダ

デフォルトは存在しない

* javax.net.ssl.trustStoreProvider システムプロパティー

デフォルトのトラストストア型

KeyStore.getDefaultType()

* javax.net.ssl.trustStoreType システムプロパティー。
NONE を指定可能。この設定は、ハードウェアトークンに存在する場合など、トラストストアがファイルベースでない場合に適切

デフォルトのキーマネージャーファクトリのアルゴリズム名

SunX509

ssl.KeyManagerFactory.algorithm セキュリティープロパティー
デフォルトのトラストマネージャーファクトリのアルゴリズム名

PKIX

ssl.TrustManagerFactory.algorithm セキュリティープロパティー
デフォルトのプロキシホスト

デフォルトは存在しない

* https.proxyHost システムプロパティー
デフォルトのプロキシポート

80

* https.proxyPort システムプロパティー
デフォルトの暗号群

ソケットファクトリによって決定

* https.cipherSuites システムプロパティー。HttpsURLConnection で使用できる暗号群を指定する暗号群名リスト (コンマ区切り形式) を含む。 SSLSocket setEnabledCipherSuites(String[]) メソッドを参照
デフォルトのハンドシェークプロトコル

ソケットファクトリによって決定

* https.protocols システムプロパティー。HttpsURLConnection で使用できるプロトコル群を指定するプロトコル群名リスト (コンマ区切り形式) を含む。 SSLSocket setEnabledProtocols(String[]) メソッドを参照
デフォルトの https ポート

443

* https URL 内の port フィールドをカスタマイズ
SunJSSE プロバイダが使用する JCE 暗号化アルゴリズム

SunJCE 実装

代替 JCE アルゴリズムプロバイダに SunJSSE プロバイダより高い優先順位を付与
大きい SSL/TLS パケット用のバッファーのデフォルトでのサイズ設定

デフォルトは存在しない

* jsse.SSLEngine.acceptLargeFragments システムプロパティー
このシステムプロパティーを true に設定すると、SSLSession はデフォルトで大きいデータパケットを処理するようにバッファーをサイズ設定します。これにより、アプリケーションが不要な大きい SSLEngine バッファーを割り当てる場合があります。代わりに、アプリケーションはバッファーオーバーフロー条件を動的にチェックして、バッファーを適宜サイズ変更する必要があります。

.

* このプロパティーは現在、JSSE 実装で使用されています。他の実装での検証および使用は保証されていません。ほかの実装で検証する場合は、JSSE 実装と同じ方法で処理されます。プロパティーが今後も存在すること、またはシステム型やセキュリティー型が将来のリリースでも変更されないことの保証はされません。

java.lang.system プロパティーを設定してカスタマイズする項目と、java.security.Security プロパティーを設定してカスタマイズする項目があります。以下の節では、両方のプロパティー型の値を設定する方法を説明します。

java.lang.system プロパティーの設定方法

JSSE の機能には、システムプロパティーを設定してカスタマイズするものがあります。システムプロパティーは静的または動的に設定します。

  • システムプロパティーを静的に設定するには、java コマンドの -D オプションを使用します。たとえば、アプリケーション MyApp を実行してシステムプロパティー javax.net.ssl.trustStore を設定し、「MyCacertsFile」というトラストストアを指定するには、次のように入力します。
    java -Djavax.net.ssl.trustStore=MyCacertsFile MyApp

  • システムプロパティーを動的に設定するには、次のコードで java.lang.System.setProperty メソッドを呼び出します。
    System.setProperty(propertyName,
    "propertyValue");
    適切なプロパティー名と値を入力してください。たとえば、システムプロパティー javax.net.ssl.trustStore を設定して「MyCacertsFile」というトラストストアを指定する、上記の例に対応した setProperty 呼び出しでは、次のように入力します。
    System.setProperty("javax.net.ssl.trustStore",
    "MyCacertsFile");

java.security.Security プロパティーの設定

JSSE の機能には、セキュリティープロパティーを設定してカスタマイズするものがあります。セキュリティープロパティーは静的または動的に設定します。

  • セキュリティープロパティーを静的に設定するには、セキュリティープロパティーファイルに 1 行追加します。セキュリティープロパティーファイルは次のディレクトリにあります。
    <java-home>/lib/security/java.security
    ここで、<java-home> は、JRE ランタイムソフトウェアのインストールディレクトリです。インストールディレクトリ <java-home> を参照してください。

    セキュリティープロパティーファイルでセキュリティープロパティー値を指定するには、次の行を追加します。

    propertyName=propertyValue
                

    たとえば、デフォルトの「SunX509」以外のキーマネージャーファクトリのアルゴリズム名を指定するとします。ssl.KeyManagerFactory.algorithm のセキュリティープロパティー値をアルゴリズム名に指定します。たとえば、値を「MyX509」に設定するには、セキュリティープロパティーファイルを次のように変更します。

    ssl.KeyManagerFactory.algorithm=MyX509

  • セキュリティープロパティーを動的に設定するには、次のコードで java.security.Security.setProperty メソッドを呼び出します。
    Security.setProperty(propertyName,
    "propertyValue");
    適切なプロパティー名と値を入力してください。たとえば、キーマネージャーファクトリのアルゴリズム名を指定する、上記の例に対応した setProperty 呼び出しでは、次のように入力します。
    Security.setProperty("ssl.KeyManagerFactory.algorithm",
    "MyX509");

X509 証明書実装のカスタマイズ

X509Certificate.getInstance メソッドで返された X509 証明書実装は、デフォルトでは JSSE 実装の実装です。

任意で、別の実装を返すようにすることもできます。その場合は、新しい実装クラスの名前 (およびパッケージ) を、cert.provider.x509v1 というセキュリティープロパティー値に設定します。たとえば、MyX509CertificateImpl というクラスが com.cryptox パッケージにある場合、セキュリティープロパティーファイルに次の行を追加します。

cert.provider.x509v1=com.cryptox.MyX509CertificateImpl

HTTPS プロトコルの代替実装

java.net.URL クラスに https で始まる URL を使えば、SSL が利用できる Web サーバーで安全に通信できます。J2SDK では、https の URL 実装をデフォルトで提供します。

別の https プロトコル実装を使用する場合は、java.protocol.handler.pkgsシステムプロパティーに新しいクラス名を追加します。その結果、J2SDK のデフォルトクラスより前に、指定したクラスが検索され、ロードされます。詳細については、java.net.URL クラスを参照してください。

旧バージョンの JSSE ユーザーへの注記: 旧バージョンの JSSE では、JSSE のインストール中に java.protocol.handler.pkgs システムプロパティーを設定する必要がありました。このステップは、com.sun.net.ssl.HttpsURLConnection のインスタンスを取得する場合以外は不要になりました。詳細については、「トラブルシューティング」のHttpsURLConnection クラスを使用するコード」を参照してください。

プロバイダ実装のカスタマイズ

v 1.4 以降の J2SDK リリースには、「SunJSSE」という JSSE 暗号化サービスプロバイダ (プロバイダ) が標準で付属しています。基本的に、プロバイダは特定の暗号化アルゴリズムのエンジンクラスを実装するパッケージです。JSSE のエンジンクラスは SSLContextKeyManagerFactory、および TrustManagerFactory です。プロバイダとエンジンクラスの詳細は、「JavaTM 暗号化アーキテクチャーリファレンスガイド」の「設計方針」と「概念」のセクションを参照してください。

プロバイダを使用するには、そのプロバイダを静的または動的に登録する必要があります。「SunJSSE」プロバイダは登録済みなので、新しく登録する必要はありません。他のプロバイダを使用する場合は、後述のセクションでプロバイダの登録方法を確認してください。

暗号化サービスプロバイダを静的に登録する

プロバイダを静的に登録するには、セキュリティープロパティーファイルに次の行を追加します。
security.provider.n=providerClassName
          

これはプロバイダを宣言し、優先順位「n」を指定するものです。優先順位とは、特定プロバイダの指定がない場合に、要求されたサービスに関して検索されるプロバイダの順位です。順位は 1 から始まり、1 が最優先で次に 2、3 ...と続きます。

providerClassName は、プロバイダクラスの完全修飾名です。この名前は、プロバイダベンダーから取得します。

プロバイダを登録するには、セキュリティープロパティーに上記の行を追加して、providerClassName をプロバイダクラスの完全な修飾名、n をプロバイダに割り当てる優先順位にします。

標準のセキュリティープロバイダ、および SE 6 プラットフォームに付属する SunJSSE が自動的に登録されます。java.security セキュリティープロパティーファイルに次の行が追加され、SunJCE セキュリティープロバイダの優先順位が 5、SunJSSE プロバイダの優先順位が 4 として登録されます。

	  security.provider.1=sun.security.pkcs11.SunPKCS11 \
	      ${java.home}/lib/security/sunpkcs11-solaris.cfg
	  security.provider.2=sun.security.provider.Sun
	  security.provider.3=sun.security.rsa.SunRsaSign
	  security.provider.4=com.sun.net.ssl.internal.ssl.Provider
	  security.provider.5=com.sun.crypto.provider.SunJCE
	  security.provider.6=sun.security.jgss.SunProvider
	  security.provider.7=com.sun.security.sasl.Provider

他の JSSE プロバイダを使う場合は、行を追加してプロバイダを登録し、優先順位を設定します。

複数の JSSE プロバイダを同時に登録できます。プロバイダには、異なるエンジンクラスの、異なるアルゴリズムの異なる実装が含まれる場合があり、同じ型のアルゴリズムおよびエンジンクラスの一部または全部をサポートする場合もあります。特定のアルゴリズムの特定のエンジンクラス実装を検索するとき、その条件に該当する特定のプロバイダが指定されていない場合、プロバイダは優先順位付きで検索され、指定したアルゴリズムを実装する最初のプロバイダの実装が使用されます。

暗号化サービスプロバイダを動的に登録する

プロバイダを静的に登録する代わりに、プログラム開始時に Security.addProvider メソッドを呼び出して、実行時に動的に追加することができます。たとえば、プロバイダのクラス名が MyProvider で、com.ABC パッケージに MyProvider クラスがある場合、次のようなメソッドを呼び出してプロバイダを動的に追加します。

Security.addProvider(
new com.ABC.MyProvider());

Security.addProvider メソッドは、次に利用できる優先順位で、指定したプロバイダを追加します。

この登録は恒久的ではなく、十分なアクセス権があるプログラムでしか実行できません。

デフォルトの鍵とトラストストア、ストア型、およびストアパスワードのカスタマイズ

SSLSocketFactory.getDefaultSSLServerSocketFactory.getDefault を呼び出すことでデフォルトの SSLSocketFactorySSLServerSocketFactory が作成され、このデフォルトの SSLSocketFactory (または SSLServerSocketFactory) が JSSE リファレンス実装に由来するものであれば、デフォルトの SSLContext は必ずソケットファクトリに関連付けられます。デフォルトのソケットファクトリは、JSSE 実装に由来します。

デフォルトの SSLContext は、デフォルトの KeyManager および TrustManager で初期化されます。javax.net.ssl.keyStore システムプロパティーおよび適切な javax.net.ssl.keyStorePassword システムプロパティーでキーストアを指定すると、デフォルトの SSLContext で作成した KeyManager は、指定したキーストアを管理する KeyManager 実装になります。実際には「デフォルト鍵とトラストマネージャー」で説明したとおりに実装されます。システムプロパティーが指定されない場合は、KeyManager が管理するキーストアは新しい空のキーストアです。

一般に、ハンドシェークでサーバーとして動作するピアには、クライアントへの認証の資格を取得するため、KeyManager のキーストアが必要です。ただし、匿名の暗号群を選択する場合、サーバーの KeyManager キーストアは必要ありません。また、サーバーがクライアント認証を要求しないかぎり、クライアントとして動作するピアには、KeyManager キーストアは必要ありません。したがって、このような状況では、javax.net.ssl.keyStore のシステムプロパティー値が定義されていない場合もあります。

同様に、トラストストアを javax.net.ssl.trustStore システムプロパティーで指定すると、デフォルトの SSLContext で作成した TrustManager が、指定したトラストストアを管理する TrustManager 実装になります。この場合、プロパティーが存在しても指定するファイルが存在しなければ、トラストストアは使用されません。javax.net.ssl.trustStore プロパティーが存在しない場合は、デフォルトのトラストストアを検索します。<java-home>/lib/security/jssecacerts というトラストストアが見つかった場合、これを使用します。このトラストストアが見つからない場合、<java-home>/lib/security/jssecacerts というトラストストアを検索し、見つかればこれを使用します。<java-home> については「インストールディレクトリ <java-home>」を参照してください。トラストストアが見つからない場合、TrustManager は新しい空のトラストストアを管理します。


重要: JDK には、少数の信頼されたルート証明書を含む <java-home>/lib/security/cacerts ファイルが付属しています。「keytool」 に記載したとおり、このファイルをトラストストアとして使用する場合は、このファイルに含まれる証明書の管理 (追加または削除) を行う必要があります。

接続先のサーバーの証明書構成によっては、ルート証明書を新たに追加しなければならない場合もあります。適切なベンダーから必要なルート証明書を入手してください。


システムプロパティー javax.net.ssl.keyStoreTypejavax.net.ssl.keyStorePassword の両方またはどちらか一方が指定されている場合、それぞれがデフォルトの KeyManager キーストア型とパスワードとして扱われます。型が指定されていない場合、デフォルトの型は KeyStore.getDefaultType() が返す keystore.type セキュリティープロパティーの値です。 また、そうしたセキュリティープロパティーが指定されていない場合は「jks」になります。キーストアのパスワードが指定されていない場合は "" とみなされます。

同様に、システムプロパティー javax.net.ssl.trustStoreTypejavax.net.ssl.trustStorePassword の両方またはどちらか一方が指定されている場合、それぞれがデフォルトのトラストストア型とパスワードとして扱われます。型が指定されていない場合、KeyStore.getDefaultType() によってデフォルト型が返されます。トラストストアのパスワードが指定されていない場合は "" とみなされます。

重要: この節では、現在の JSSE リファレンス実装の動作を説明します。この節で説明するシステムプロパティーの名前と型 (システムかセキュリティーか) が今後も使用されるという保証はありません。また、今後のリリースで存在するという保証もありせん。また、他の JSSE 実装での検証や使用も保証されていません。実装で検証された場合、個々で説明した JSSE リファレンス実装と同じ方法で処理してください。

デフォルトのキーマネージャーおよびトラストマネージャーのカスタマイズ

デフォルトの鍵とトラストストア、ストア型、およびパスワードのカスタマイズ」で説明したように、デフォルトの SSLSocketFactorySSLServerSocketFactory が作成され、このデフォルトの SSLSocketFactory (または SSLServerSocketFactory) が JSSE リファレンス実装に由来する場合は、常にデフォルトの SSLContext はソケットファクトリに関連付けられます。

このデフォルトの SSLContext は、デフォルトの KeyManager および TrustManager で初期化されます。デフォルトの SSLContext に提供された KeyManagerTrustManager の両方またはどちらか一方は、指定したキーストアまたはトラストストアを管理する KeyManager または TrustManager の実装になります。これについては、後の節で説明します。

選択される KeyManager 実装は、まず

ssl.KeyManagerFactory.algorithm
セキュリティープロパティーを確認して決定されます。そのようなプロパティー値が指定されていると、指定したアルゴリズムの KeyManagerFactory 実装が検索されます。実装を提供する最初のプロバイダの実装が使用されます。実装の getKeyManagers メソッドが呼び出され、デフォルトの SSLContext に提供する KeyManager が決定されます。技術的には、getKeyManagersKeyManager の配列を返します。これは鍵データの型ごとの KeyManager です。そのようなセキュリティープロパティー値が指定されていない場合、「SunX509」のデフォルト値を使って検索します。注:「SunX509」アルゴリズムの KeyManagerFactory 実装は SunJSSE プロバイダが提供します。プロバイダが指定する KeyManagerjavax.net.ssl.X509KeyManager 実装です。

同様に、選択される TrustManager 実装は、まず

ssl.TrustManagerFactory.algorithm
セキュリティープロパティーを確認して決定されます。そのようなプロパティー値が指定されていると、指定したアルゴリズムの TrustManagerFactory 実装が検索されます。実装を提供する最初のプロバイダの実装が使用されます。実装の getTrustManagers メソッドが呼び出され、デフォルトの SSLContext に提供する TrustManager が決定されます。技術的には、getTrustManagersTrustManager の配列を返します。これは鍵データの型ごとの TrustManager です。そのようなセキュリティープロパティー値が指定されていない場合、「PKIX」のデフォルト値を使って検索します。注:「PKIX」アルゴリズムの TrustManagerFactory 実装は SunJSSE プロバイダが提供します。プロバイダが指定する TrustManagerjavax.net.ssl.X509TrustManager 実装です。

重要: この節では、現在の JSSE リファレンス実装の動作を説明します。この節で説明するシステムプロパティーの名前と型 (システムかセキュリティーか) が今後も使用されるという保証はありません。また、今後のリリースで存在するという保証もありせん。また、他の JSSE 実装での検証や使用も保証されていません。実装で検証された場合、個々で説明した JSSE リファレンス実装と同じ方法で処理してください。

暗号化アルゴリズムプロバイダのカスタマイズ

Java SE 5 のリリースから、SunJSSE プロバイダは、暗号化の必要すべてを満たすために SunJCE 実装を使用しています。Sun プロバイダは通常の位置に置くことが推奨されていますが、SunJCE プロバイダよりに登録することにより、他の JCA/JCE プロバイダからの実装を使用することもできます。 プロバイダの構成には、標準 JCA 機構を使用できます。まず、以下のセキュリティープロパティーファイルを利用して静的に行う方法があります。

<java-home>/lib/security/java.security
次に、java.security.Security クラスの addProvider メソッドまたは insertProviderAt メソッドを利用して動的に行う方法があります。<java-home> の詳細については、「インストールディレクトリ <java-home>」を参照してください。

プロバイダの実装を行うユーザーへの注記

SunJSSE が Cipher.getInstance() を呼び出すとき、使用される変換文字列は "RSA/ECB/PKCS1Padding"、"RC4"、"DES/CBC/NoPadding"、"DESede/CBC/NoPadding" になります。Cipher クラスと変換文字列の詳細については、「Java 暗号化アーキテクチャーリファレンスガイド」を参照してください。

JCE およびハードウェア高速化/スマートカードのサポート

JCE の使用法

Java 暗号化拡張機能 (JCE) は、暗号化、鍵生成と鍵協定、およびメッセージ認証コード (MAC) アルゴリズム用のフレームワークおよび実装となるパッケージセットです。Java SE 5 より前の SunJSSE プロバイダは、構成されていれば JCE プロバイダを利用することができましたが、依然として JCE を使用しない内部暗号化コードが含まれていました。Java SE 6 の SunJSSE プロバイダは、すべての暗号化操作のために JCE を排他的に使用するので、JCE に新しく追加された PKCS#11 のサポートを含め、JCE の特長や拡張機能の利点を自動的に活用することができます。これにより Java SE 6 の SunJSSE プロバイダは、ハードウェア暗号化アクセラレータを使用してパフォーマンスを著しく向上させ、キーストアとしてスマートカードを使用し、鍵および信頼性管理の柔軟性を高めることができます。

ハードウェアアクセラレータ

基盤となるアクセラレータハードウェアを使用するように SUN PKCS#11 プロバイダが構成され、その PKCS#11 プロバイダを使用するように JCE が構成されていれば、ハードウェア暗号化アクセラレータは自動的に使用されます。PKCS#11 プロバイダは、プロバイダリストにある他の JCE/JCA プロバイダより前に構成する必要があります。Sun PCCS#11 プロバイダの構成方法については、「PKCS#11 リファレンスガイド」を参照してください。

スマートカードをキーストアおよびトラストストアとして使用するための JSSE の構成

JCE での PKCS#11 のサポートにより、キーストアとしてスマートカードにアクセスすることもできます。JSSE によって使用されるキーストアの型と場所の構成方法については、「カスタマイズ」を参照してください。スマートカードをキーストアまたはトラストストアとして使用するには、javax.net.ssl.keyStoreType および javax.net.ssl.trustStoreType システムプロパティーをそれぞれ「pkcs11」に設定し、javax.net.ssl.keyStore および javax.net.ssl.trustStore システムプロパティーをそれぞれ「NONE」に設定します。特定のプロバイダを使用するように指定するには、javax.net.ssl.keyStoreProvider および javax.net.ssl.trustStoreProvider システムプロパティーを使用します (例:「SunPKCS11-joe」)。 これらのプロパティーを使用することにより、以前はファイルベースのキーストアにアクセスするためにこれらのプロパティーに依存していたアプリケーションを構成して、アプリケーションに変更を加えずにスマートカードのキーストアを使用できます。

アプリケーションによっては、キーストアをプログラムで使用する必要があります。こうしたアプリケーションでは、引き続き既存の API を使用して Keystore をインスタンス化し、キーマネージャーとトラストマネージャーに渡すことができます。Keystore インスタンスがスマートカードによる PKCS#11 キーストアを参照する場合は、JSSE アプリケーションがスマートカードキーにアクセスすることになります。

複数の動的キーストア

スマートカードおよび他の取り外し可能トークンには、X509KeyManager の場合に要件が追加されます。Java アプリケーションが存続する間には、異なるスマートカードがスマートカードリーダーに挿入され、それらのスマートカードは異なるパスワードを使用して保護されます。J2SE 5 以前の API および SunX509 キーマネージャーは、これらの要件を十分に満たしていませんでした。 そのため、Java SE 5 には新しい API が組み込まれており、新しい X509KeyManager 実装が SunJSSE プロバイダに追加されました。

java.security.KeyStore.Builder クラスは、KeyStore オブジェクトの構造と初期化データを抽象化します。パスワードのプロンプトに CallbackHandlers を使用でき、サブクラス化してアプリケーションにとって望ましい追加機能をサポートできます。たとえば、ビルダーを実装して、個々の KeyStore エントリを異なるパスワードで保護することが可能です。その後、javax.net.ssl.KeyStoreBuilderParameters クラスを使用し、これらのビルダーオブジェクトを 1 つ以上使用して KeyManagerFactory を初期化することができます。

「NewSunX509」と呼ばれる、SunJSSE プロバイダの新しい X509KeyManager 実装は、これらのパラメータをサポートしています。複数の証明書が使用可能な場合は、鍵の使用法が適切な証明書を選択し、期限切れの証明書より有効な証明書を優先させます。

スマートカードを使用する PKCS#11 ファイルベースキーストアと PCKS#12 ファイルベースキーストアの両方を使用するよう JSSE に指示する方法の例を次に示します。

import javax.net.ssl.*;
import java.security.KeyStore.*;
...

// Specify keystore builder parameters for PKCS#11 keystores
Builder scBuilder = Builder.newInstance("PKCS11", null,
    new CallbackHandlerProtection(myGuiCallbackHandler));

// Specify keystore builder parameters for a specific PKCS#12 keystore
Builder fsBuilder = Builder.newInstance("PKCS12", null,
    new File(pkcsFileName), new PasswordProtection(pkcsKsPassword));

// Wrap them as key manager parameters
ManagerFactoryParameters ksParams =
    new KeyStoreBuilderParameters(
	Arrays.asList(new Builder[] { scBuilder, fsBuilder }));

// Create KeyManagerFactory
KeyManagerFactory factory = KeyManagerFactory.getInstance("NewSunX509");

// Pass builder parameters to factory
factory.init(ksParams);

// Use factory
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(factory.getKeyManagers(), null, null);

Kerberos 符号化方式

Java SE 6 の SunJSSE プロバイダは、RFC 2712 で規定される Kerberos 符号化方式をサポートします。以下の符号化方式がサポートされていますが、デフォルトでは有効になっていません。
TLS_KRB5_WITH_RC4_128_SHA
TLS_KRB5_WITH_RC4_128_MD5
TLS_KRB5_WITH_3DES_EDE_CBC_SHA
TLS_KRB5_WITH_3DES_EDE_CBC_MD5
TLS_KRB5_WITH_DES_CBC_SHA
TLS_KRB5_WITH_DES_CBC_MD5
TLS_KRB5_EXPORT_WITH_RC4_40_SHA
TLS_KRB5_EXPORT_WITH_RC4_40_MD5
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
これらの符号化方式を使用可能にするには、明示的に指定する必要がります。詳細については、SSLEngine.setEnabledCipherSuites() および SSLSocket.setEnabledCipherSuites() を参照してください。その他のすべての SSL/TLS 符号化方式同様、符号化方式がピアの側でサポートされていない場合は、暗号のネゴシエーション時に選択されません。また、アプリケーションまたはサーバーが必要な Kerberos 資格を取得できない場合は、Kerberos 符号化方式も選択されません。

TLS_KRB5_WITH_DES_CBC_SHA 符号化方式のみを使用する TLS クライアントの例を示します。

// Create socket
SSLSocketFactory sslsf = (SSLSocketFactory) SSLSocketFactory.getDefault();
SSLSocket sslSocket = (SSLSocket) sslsf.createSocket(tlsServer, serverPort);

// Enable only one cipher suite
String enabledSuites[] = { "TLS_KRB5_WITH_DES_CBC_SHA" };
sslSocket.setEnabledCipherSuites(enabledSuites);

Kerberos 要件

JSSE で Kerberos 符号化方式を使用する前に、配備されている環境で Kerberos インフラストラクチャーを設定しておく必要があります。特に、TLS クライアントとサーバーの両方に、Kerberos Key Distribution Center (KDC) によるアカウントが設定されていことが必要です。実行時に Kerberos 符号化方式の 1 つ以上が有効化されると、TLS クライアントとサーバーは、それぞれのアカウントに関連付けられている自身の Kerberos 資格を KDC から取得します。たとえば、Keberos 領域 IMC.ORG のマシン mach1.imc.org で動作する TLS サーバーは、host/mach1.imc.org@IMC.ORG という名前のアカウントを持ち、IMC.ORG 用の KDC を使用するように構成されている必要があります。Java SE での Kerberos の使用法の詳細は、「Kerberos 要件」を参照してください。

アプリケーションは、Java 認証・承認サービス (JAAS) と Kerberos ログインモジュールを使用して、自身の Kerberos 資格を取得できます。Java SE Development Kit 6 は、Kerberos ログインモジュールに付属しています。JSSE での Kerberos 符号化方式は、Java Generic Security Services (Java GSS) の使用法と同様に、JAAS プログラムがある場合とない場合に使用できます。

JAAS プログラムなしで Kerberos 符号化方式を使用するには、JAAS 構成入力用に 「com.sun.net.ssl.server」または「other、および TLS クライアント用に「com.sun.net.ssl.client」または「other」というインデックス名を使用し、システムプロパティー javax.security.auth.useSubjectCredsOnly を false に設定する必要があります。たとえば、JAAS プログラムを使用しない TLS サーバーには以下の JAAS 構成ファイルがあります。

com.sun.net.ssl.server {
  com.sun.security.auth.module.Krb5LoginModule required
        principal="host/mach1.imc.org@IMC.ORG"
        useKeyTab=true
        keyTab=mach1.keytab
	storeKey=true;
};
JAAS プログラミングを行わずに Java GSS および Kerberos を使用する方法の例は、「Java GSS チュートリアル」で説明されています。Java GSS 呼び出しを JSSE 呼び出しに置き換えることにより、JSSE の使用例に適応できます。

JAAS プログラムによって Kerberos 符号化方式を使用するには、任意のインデックス名を使用できます。 これは、アプリケーションに、インデックス名を使用して JAAS LoginContext を作成し、JSSE 呼び出しを Subject.doAs() または Subject.doAsPrivileged() 呼び出しの内部にラップする役割があるからです。Java GSS および Kerberos で JAAS を使用する方法の例は、「Java GSS チュートリアル」で説明されています。Java GSS 呼び出しを JSSE 呼び出しに置き換えることにより、JSSE の使用例に適応できます。

JSSE アプリケーションで Kerberos を使用する場合の使用法または構成方法に関する問題については、Java GSS チュートリアルの 「トラブルシューティング」を参照してください。

ピアのアイデンティティー情報

SSL 接続のピアのアイデンティティーを判別するには、javax.net.ssl.SSLSessionjavax.net.ssl.HttpsURLConnection、および javax.net.HandshakeCompletedEvent クラスで、getPeerPrincipal() メソッドを使用します。同様に、(ローカルエンティティーを識別するために) ピアに送信されたアイデンティティーを取得するには、これらのクラスで getLocalPrincipal() を使用します。X509 ベースの暗号化方式の場合、これらのメソッドは javax.security.auth.x500.X500Principal のインスタンスを返します。Kerberos 暗号化方式の場合、これらのメソッドは javax.security.auth.kerberos.KerberosPrincipal のインスタンスを返します。

Java SE 5 より前は、JSSE アプリケーションは、getPeerCertificates() および同様のメソッドを javax.net.ssl.SSLSessionjavax.net.ssl.HttpsURLConnection、および javax.net.HandshakeCompletedEvent で使用して、ピアに関する情報を取得しました。ピアに証明書がない場合、SSLPeerUnverifiedException がスローされます。これらのメソッドの動作は、Java SE 6 でも変わっていません。つまり、接続が Kerberos 暗号化方式を使用して保護された場合、これらのメソッドは SSLPeerUnverifiedException をスローします。

アプリケーションがピアのアイデンティティーまたはピアに送信されたアイデンティティーのみを判別する必要がある場合は、それぞれ getPeerPrincipal() および getLocalPrincipal() メソッドを使用する必要があります。getPeerCertificates() および getLocalCertificates() は、それらの証明書の内容を調べる必要がある場合にのみ使用します。また、認証されたピアに証明書がない場合の処理の準備が必要です。

セキュリティーマネージャー

セキュリティーマネージャーが有効な場合、ピアとの通信に必要な SocketPermission 以外に、Kerberos 暗号化方式を使用する TLS クライアントアプリケーションには次のアクセス権も必要です。
javax.security.auth.kerberos.ServicePermission(serverPrincipal, "initiate");
serverPrincipal は、TLS クライアントが通信する TLS サーバーの Kerberos 主体名です。host/mach1.imc.org@IMC.ORG などです。TLS サーバーアプリケーションには、次のアクセス権が必要です。
javax.security.auth.kerberos.ServicePermission(serverPrincipal, "accept");
serverPrincipal は、TLS サーバーの Kerberos 主体名です。host/mach1.imc.org@IMC.ORG などです。サーバーまたはクライアントが KDC にコンタクトする必要がある場合 (その資格がローカルにキャッシュされていない場合など)、次のアクセス権も必要です。
javax.security.auth.kerberos.ServicePermission(tgtPrincipal, "initiate");
tgtPrincipal は KDC の主体名です。krbtgt/IMC.ORG@IMC.ORG などです。

その他のキーストア形式 (PKCS12)

PKCS#12 (Personal Information Exchange Syntax Standard) では、移植可能な保存形式、およびユーザーの非公開鍵、証明書、その他の秘密およびほかの項目の転送について規定されています。SunJSSE プロバイダは、pkcs12 ファイルの読み書きのための PKCS12 java.security.KeyStore 形式の実装を提供します。この形式は、Netscape/Mozilla、Microsoft の Internet Explorer、OpenSSL などほかのツールキットやアプリケーションでもサポートされ、鍵と証明書をインポートおよびエクスポートします。たとえば、これらの実装は、クライアントの証明書と鍵を「.p12」ファイル名拡張子を使用してファイルにエクスポートできます。

SunJSSE プロバイダでは、キーストア型「pkcs12」(または PKCS12、大文字と小文字は区別されません) を使って、KeyStore API を介して PKCS12 にアクセスできます。さらに keytool コマンドと、pkcs12 に設定された -storetype オプションを使用して、インストールされた鍵および関連する証明書を表示できます。keytool については「セキュリティーツール」を参照してください。

トラブルシューティング

構成上の問題点

CertificateException:(ハンドシェーク時)

問題:SSL 接続のネゴシエーション中に、クライアントまたはサーバーが CertificateException をスローします。

原因 1: 多くの場合、リモートサイドがローカルサイドにとって不明な証明書を送信することが原因です。

解決法 1: このような問題を解決するには、デバッグをオンにして、証明書のロード時、およびネットワーク接続からの受信時を観察します。デバッグについては、「デバッグユーティリティー」を参照してください。多くの場合、間違ったトラストファイルをロードしたため、受信した証明書がトラスト機構にとって不明です。詳細については、以下の節を参照してください。

原因 2: システムクロックが正しく設定されていません。

解決法 2: クロックが正しく設定されていない場合、認識された時間が証明書の有効期間外になっている可能性があります。トラストストアの有効な証明書と置き換えない限り、システムはこの証明書を無効とみなし、例外をスローします。

java.security.KeyStoreException:TrustedCertEntry not supported

問題: 信頼できる証明書を PKCS12 キーストアに格納しようとすると、java.security.KeyStoreException: TrustedCertEntry not supported がスローされます。

原因 1: 信頼できる証明書の pkcs12 キーストアへの格納はサポートしていません。PKCS12 は、主に非公開鍵と関連する証明書チェーンの配信に使用されます。「信頼できる」証明書の概念はありません。相互運用性の観点から、ほかの pkcs12 ベンダーにも同じ制限があります。Mozilla や Internet Explorer などのブラウザは、信頼できる証明書のみを持つ pkcs12 ファイルは受け入れません。

解決法 1: 信頼できる証明書の格納には、JKS (または JCEKS) キーストアを使用します。

実行時例外: SSL Service Not Available

問題:JSSE を使うプログラムを実行すると、SSL サービスが利用できないという例外が発生します。たとえば、次のような例外が発生します。

    Exception in thread "main"
java.net.SocketException: no SSL Server Sockets

Exception in thread "main":
SSL implementation not available

原因:SSLContext の初期化時に問題が発生しています。たとえば、キーストアに正しいパスワードが入力されなかったか、キーストアが破損している可能性があります。なお、この種のエラーが発生するのは、以前に未知の形式のキーストアを提供する JDK ベンダーがあったためです。

解決法: 初期化パラメータを確認します。指定したキーストアが有効であり、指定したパスワードが正しいことを確認します。keytool を使うと、キーストアとその内容を調べることができます。

例外 "No available certificate corresponding to the SSL cipher suites which are enabled"

問題: 単純な SSL Server プログラムを実行しようとすると、以下の例外がスローされます。

Exception in thread "main" javax.net.ssl.SSLException:
No available certificate corresponding to the SSL
cipher suites which are enabled...

原因: 必要な鍵データの型は暗号群によって異なります。たとえば、RSA 暗号群が有効になっている場合、キーストアで RSA の keyEntry を有効にする必要があります。該当する鍵を使用できない場合、その暗号群を使用することはできません。有効になっているすべての暗号群の鍵のエントリが使用できない場合、この例外がスローされます。

解決法: 暗号群の型にあった鍵エントリを作成します。または匿名の暗号群を使用します。匿名の暗号群には、"man-in-the-middle" 攻撃に対して脆弱であるという潜在的な危険性があります。詳細については RFC 2246 を参照してください。正しいキーストアおよび証明書を渡す方法については、以下の節を参照してください。

実行時例外: No Cipher Suites in Common

問題 1: ハンドシェーク時にクライアントやサーバーがこの例外をスローします。

原因 1:SSL 接続の両側が共通の暗号群について合意している必要があります。クライアントの暗号群セットとサーバーの暗号群セットの共通点がない場合、この例外がスローされます。

解決法 1: 有効な暗号群セットを構成し、共通の暗号群を追加します。さらに、非対称の暗号群に適切な keyEntry が提供されるようにします。この節の「例外、"No available certificate..."」を参照してください。

問題 2:DSA ベースの証明書しかないサーバーのファイルに Netscape Navigator や Microsoft Internet Explorer (IE) で アクセスすると、共通の暗号群がないという実行時例外が発生します。

原因 2: デフォルトでは、keytool で作成された keyEntries は DSA 公開鍵を使用します。キーストア内に DSA の keyEntries が存在する場合、使用できるのは DSA ベースの暗号群のみです。デフォルトでは、Navigator と IE は RSA ベースの暗号群のみを送信します。クライアントとサーバーの暗号群セットの共通点がないため、この例外がスローされます。

解決法 2:Navigator や IE を使う場合は、RSA ベースの鍵を使う証明書を作成します。そのためには、keytool 使用時に -keyalg RSA オプションを指定する必要があります。例を示します。

    keytool -genkeypair -alias duke \
	-keystore testkeys -keyalg rsa

JSSE の最初のアクセスが遅い

問題: 最初のアクセスで JSSE が停止したように見えます。

原因:JSSE には乱数の安全なソースが必要です。初期化には時間がかかります。

解決法: 別の乱数発生関数を使用するか、オーバーヘッドが通知されない場合は次の方法で先に初期化します。

SecureRandom sr = new SecureRandom();
sr.nextInt();
SSLContext.init(..., ..., sr);
<java-home>/lib/security/java.security ファイルは、SecureRandom のシードデータのソースを指定する方法も提供します。詳細は、ファイルを参照してください。

HttpsURLConnection クラスを使用するコードが JSSE 1.0.x で ClassCastException をスローする

問題: 以下のコード (抜粋) は、JSSE 1.0.x の com.sun.net.ssl.HttpsURLConnection で作成されたものです。

import com.sun.net.ssl.*;
...deleted...
HttpsURLConnection urlc = new URL("https://foo.com/").openConnection();
現在のリリースで実行すると、このコードは javax.net.ssl.HttpsURLConnection を返し、ClassCastException をスローします。

原因: デフォルトでは、"https" URL を開くと javax.net.ssl.HttpsURLConnection が作成されます。

解決法: 以前のリリースの JDK (Java SE 6 SDK 以前) には、「https」URL の実装が付属していません。JSSE 1.0.x 実装は、"https" URL ハンドラを提供します。インストールガイドにも、URL ハンドラの検索パスを設定して JSSE 1.0.x の com.sun.net.ssl.HttpsURLConnection 実装を取得する方法が記載されています。

現在のリリースでは、URL ハンドラのデフォルトの検索パスに "https" ハンドラが指定されています。その結果、javax.net.ssl.HttpsURLConnection のインスタンスが返されます。java.protocol.handler.pkgs 変数を使って、以前の JSSE 1.0.x 実装パスを URL 検索パスに追加することにより、com.sun.net.ssl.HttpsURLConnection を取得できます。この場合、上記のコードが例外をスローすることはありません。

% java -Djava.protocol.handler.pkgs=\
com.sun.net.ssl.internal.www.protocol YourClass
または
System.setProperty("java.protocol.handler.pkgs", 
"com.sun.net.ssl.internal.www.protocol");

ClientHello メッセージの送信後ソケットが切断される

問題: 接続するために ClientHello メッセージを送信したあと、ただちにソケットが切断されます。

原因:SSL/TLS サーバーの中には、受信した ClientHello メッセージの形式を判断できない場合や、このメッセージのプロトコルのバージョンがサポート対象外である場合、接続を切断するものがあります。

解決法:SSLSocket.setEnabledProtocols でプロトコルの調整を試みてください。たとえば、従来のサーバー実装には、SSLv3 のみに対応し、TLS に対応していないものがあります。理論的に言えば、こうした実装は SSLv3 でネゴシエーションを行うはずですが、実際にはハングアップするだけです。後方互換性のため、一部のサーバー実装 (SunJSSE など) は SSLv3 /TLS の ClientHello を SSLv2 の ClientHello パケットにカプセル化して送信します。しかし、この形式をサポートしないサーバーもあります。この場合は、setEnabledProtocols を使って、送信時の SSLv2 の ClientHello パケットへのカプセル化を無効にします。

必要なアルゴリズムをサポートする JCA/JCE プロバイダを SunJSSE が見つけられず、NoSuchAlgorithmException が発生する

問題: ハンドシェークが試行され、必要なアルゴリズムが見つからない場合は失敗します。例は次のとおりです。

Exception in thread ...deleted...
     ...deleted...
     Caused by java.security.NoSuchAlgorithmException: Cannot find any
provider supporting RSA/ECB/PKCS1Padding
または
     Caused by java.security.NoSuchAlgorithmException: Cannot find any
provider supporting AES/CBC/NoPadding

原因:SunJSSE は、その暗号化アルゴリズムすべてで JCE を使用します。デフォルトでは、Sun JDK は Standard Extension ClassLoader を使用して、<java-home>/lib/ext/sunjce_provider.jar にある SunJCE プロバイダをロードします。ファイルが見つからないかロードできない場合、または SunJCE プロバイダが Provider 機構から登録解除されており、JCE からの代替実装を利用できない場合、この例外が発生します。

解決法: ファイルがロード可能であることをチェックして SunJCE が使用可能であることを確認し、プロバイダが Provider インタフェースに登録されていることを確認します。SSL 接続のコンテキストで次のコードを実行してみます。

    import javax.crypto.*;

    System.out.println("=====Where did you get AES=====");
    Cipher c = Cipher.getInstance("AES/CBC/NoPadding");
    System.out.println(c.getProvider());

デバッグユーティリティー

JSSE には、動的デバッグのトレースをサポートする機能があります。これは、Java SE 6 プラットフォームでデバッグのアクセス制御に失敗した場合に使用するサポート機能に似ています。総称 Java 動的デバッグトレースサポートにはシステムプロパティー java.security.debug でアクセスしますが、JSSE 固有の動的デバッグトレースサポートにはシステムプロパティー javax.net.debug でアクセスします。

注: デバッグユーティリティーは、公式にサポートされている JSSE 機能ではありません。

JSSE 動的デバッグユーティリティーのオプションを表示するには、java コマンドで次のコマンド行オプションを使用します。

    -Djavax.net.debug=help

注: デバッグ用に設計されたユーティリティーでクラスを使用しないプログラムを実行しているとき、どちらの動的デバッグユーティリティーで help を指定しても、デバッグオプションは使用できません。

デバッグオプションのリストを表示させる方法の例を、次に示します。

    java -Djavax.net.debug=help MyApp 
MyApp は、JSSE クラスを使用するアプリケーションです。MyApp は、デバッグのヘルプ情報が表示されると動作しなくなります。ヘルプコードによりアプリケーションが終了するためです。

現在のオプションは次のとおりです。

        all        turn on all debugging
        ssl        turn on ssl debugging

        The following can be used with ssl:
            record          enable per-record tracing
            handshake       print each handshake message
            keygen          print key generation data
            session         print session activity
            defaultctx      print default SSL initialization
            sslctx          print SSLContext tracing
            sessioncache    print session cache tracing
            keymanager      print key manager tracing
            trustmanager    print trust manager tracing

        handshake debugging can be widened with:
            data            hex dump of each handshake message
            verbose         verbose handshake message printing

        record debugging can be widened with:
            plaintext       hex dump of record plaintext
            packet          print raw SSL/TLS packets
    
javax.net.debug プロパティー値は、all または ssl を指定する必要があり、デバッグ指定子がその後に続く場合もあります。1 つまたは複数のオプションが使用できます。オプションをセパレータで区切る必要はありませんが、「:」や「,」を使用すると読みやすくなります。どのセパレータも使用でき、オプションキーワードの順序も重要ではありません。

このデバッグ情報の見方の説明は、ガイド「SSL/TLS 接続のデバッグ」を参照してください。

  • デバッグメッセージをすべて表示する場合は、次のように入力します。
        java -Djavax.net.debug=all MyApp

  • ハンドシェークメッセージを 16 進ダンプで表示するには、次のように入力します。コロンは省略できます。
        java -Djavax.net.debug=ssl:handshake:data MyApp

  • ハンドシェークメッセージを 16 進ダンプで表示し、さらにトラストマネージャーのトレース状態を表示するには、次のように入力します。カンマは省略できます。
        java -Djavax.net.debug=SSL,handshake,data,trustmanager MyApp

コード例

以下の節では、次のコード例について説明します。

安全でないソケットから安全なソケットへの変換

この節では、JSSE を使って、安全でないソケット接続を安全なソケット接続に変換するソースコードの例を説明します。この節のコードは『Java SE 6 Network Security』(Marco Pistoia ほか著) から引用したものです。

まず、「SSL を使用しないソケットの例」で、安全でないソケットを使ってクライアントとサーバー間の通信を設定するサンプルコードを示します。次に、「SSL を使用するソケットの例」ではこのコードを変更し、JSSE を使用して安全なソケット通信を設定します。

SSL を使用しないソケットの例

安全でないソケット通信のサーバーコード

サーバーとして動作し、ソケットを使ってクライアントと通信する Java プログラムを作成する場合、次のようなコードでソケット通信を設定します。

import java.io.*;
import java.net.*;

. . .

int port = availablePortNumber;

ServerSocket s;

try {
s = new ServerSocket(port);
Socket c = s.accept();

OutputStream out = c.getOutputStream();
InputStream in = c.getInputStream();

// Send messages to the client through
// the OutputStream
// Receive messages from the client
// through the InputStream
}

catch (IOException e) {
}

安全でないソケット通信のクライアントコード

ソケットを使ってサーバーとの通信を設定するクライアントコードの例を、次に示します。

import java.io.*;
import java.net.*;

. . .

int port = availablePortNumber;
String host = "hostname";

try {
s = new Socket(host, port);

OutputStream out = s.getOutputStream();
InputStream in = s.getInputStream();

// Send messages to the server through
// the OutputStream
// Receive messages from the server
// through the InputStream
}

catch (IOException e) {
}

SSL を使用するソケットの例

安全なソケット通信のサーバーコード

サーバーとして動作し、安全なソケットでクライアントと通信する Java プログラムを作成する場合、次のようなコードでソケット通信を設定します。安全でないソケットを使った通信のプログラムとこのプログラムとの違いは、太字で示されています。

import java.io.*;
import javax.net.ssl.*;

. . .

int port = availablePortNumber;

SSLServerSocket s;

try {
SSLServerSocketFactory sslSrvFact =
(SSLServerSocketFactory)
SSLServerSocketFactory.getDefault();
s =(SSLServerSocket)sslSrvFact.createServerSocket(port);
SSLSocket c = (SSLSocket)s.accept();

OutputStream out = c.getOutputStream();
InputStream in = c.getInputStream();

// Send messages to the client through
// the OutputStream
// Receive messages from the client
// through the InputStream
}

catch (IOException e) {
}

安全なソケット通信のクライアントコード

安全なソケットを使ってサーバーとの通信を設定するクライアントコードの例を、次に示します。安全でないソケットとの違いは、太字で示されています。

import java.io.*;
import javax.net.ssl.*;

. . .

int port = availablePortNumber;
String host = "hostname";

try {
SSLSocketFactory sslFact =
(SSLSocketFactory)SSLSocketFactory.getDefault();
SSLSocket s =
(SSLSocket)sslFact.createSocket(host, port);
OutputStream out = s.getOutputStream(); InputStream in = s.getInputStream(); // Send messages to the server through // the OutputStream // Receive messages from the server // through the InputStream } catch (IOException e) { }

JSSE サンプルコードの実行

JSSE サンプルプログラムでは、JSSE を使って次の処理を行う方法を示します。

サンプルコードを使用する場合、サンプルプログラムは JSSE の使い方を示すためのものである点に注意してください。堅牢なアプリケーションを開発するためのものではありません。

注: 安全な通信を設定すると、アルゴリズムが複雑になります。サンプルプログラムでは、設定プロセス中のフィードバックがありません。プログラム実行時には、一定時間待っても結果が表示されない場合があります。システムプロパティー javax.net.debug の設定を all にして、プログラムを実行すると、フィードバックが表示されます。このデバッグ情報の見方の説明は、ガイド「SSL/TLS 接続のデバッグ」を参照してください。

サンプルコードの場所

ほとんどのサンプルコードは、このドキュメントと同じディレクトリの samples サブディレクトリに格納されています。以下のリンクから、すべてのサンプルファイルのリストとテキストファイルを表示できます。このページから、すべてのサンプルファイルが含まれた zip ファイルもダウンロードできます。zip ファイルは、このドキュメントを Web 経由で表示している場合に便利です。

以下の節では、サンプルについて説明します。詳細については、README を参照してください。

クライアントとサーバーの安全なソケット接続を表すサンプルコード

samples/sockets ディレクトリにあるサンプルプログラムは、クライアントとサーバーとの間で安全なソケット接続を設定する方法を示しています。

サンプルのクライアントプログラムを実行中に、商用 Web サーバーなどの既存のサーバーと通信できます。また、サンプルのプログラムサーバー ClassFileServer と通信することもできます。サンプルのクライアントプログラムとサーバープログラムは、同じネットワークに接続された別個のマシンで実行することも、別々のターミナルウィンドウから同一マシン上で実行することもできます。

samples/sockets/client ディレクトリのサンプル SSLSocketClient* プログラム (および HTTPS 接続のサンプルコードで説明する URLReader* プログラム) は、すべて ClassFileServer サンプルサーバープログラムで実行できます。この例は、ClassFileServer を使った SSLSocketClientWithClientAuth の実行」に示されています。URLReaderSSLSocketClient、または SSLSocketClientWithTunnelingClassFileServer で実行する場合も、同様の変更ができます。

クライアントとサーバーとの間でメッセージを送信しようとすると認証エラーが発生する場合、Web サーバーと ClassFileServer のどちらを使用しているとしても、必要な鍵がトラストストア (トラスト鍵データベース) にない可能性があります。たとえば、ClassFileServer は「testkeys」というキーストアを使用します。これには、SSL ハンドシェーク中に必要な「localhost」の公開鍵が含まれています。「testkeys」は ClassFileServer ソースと同じディレクトリ samples/sockets/server にあります。参照するトラストストアで、「localhost」の公開鍵に対応する証明書をクライアントが検索できない場合、認証エラーが発生します。次の節で説明するように、samplecacerts トラストストア (「localhost」公開鍵がある) の扱いには注意してください。

設定要件

クライアントとサーバーとの間の安全なソケット接続を作成するサンプルプログラムを実行する場合は、適切な証明書ファイル (トラストストア) を利用できるようにしておく必要があります。クライアントプログラムとサーバープログラムの両方で、samples ディレクトリの samplecacerts 証明書ファイルを使用します。この証明書ファイルを使うと、クライアントがサーバーを認証できるようになります。このファイルには、JDK (cacerts ファイルにある) に付属する、一般的な証明書発行局の発行した証明書がすべて含まれており、また、サンプルサーバー ClassFileServer との通信時にクライアントが「localhost」を証明するのに必要な「localhost」の証明書も含まれています。(ClassFileServer は、「localhost」の公開鍵を含むキーストアを使用します。これは、samplecacerts の公開鍵に対応しています。 )

クライアントとサーバーの両方で samplecacerts ファイルを使用するには、ファイルを <java-home>/lib/security/jssecacerts ファイルにコピーして名前を cacerts に変更し、<java-home>/lib/security/cacerts ファイルと置き換えるか、クライアントとサーバーの java コマンドを実行中に、次のオプションをコマンド行に追加します。

-Djavax.net.ssl.trustStore=path_to_samplecacerts_file

<java-home> の詳細については、「インストールディレクトリ <java-home>」を参照してください。

samplecacerts トラストストアのパスワードは changeit です。keytool を使って、サンプルに独自の証明書を置き換えることができます。

Netscape Navigator や Internet Explorer などのブラウザを使用して ClassFileServer にあるサンプルの SSL サーバーにアクセスすると、ダイアログボックスが開いて、証明書が認識されないというメッセージが表示されます。これは、サンプルプログラムで使用する証明書は自己署名付きのもので、テスト用にすぎないためです。現在のセッションで証明書に同意できます。SSL サーバーのテストが終了した後、ブラウザを終了し、ブラウザの名前空間からテスト用証明書を削除します。

クライアント認証の場合、適切なディレクトリの別の「duke」証明書を使用できます。公開鍵/証明書も、samplecacerts ファイルに格納されています。

注: samples ディレクトリの「duke」証明書は、http://java.sun.com/security/signExample12/ のセキュリティーサンプルで使用する「duke」証明書とは異なります。両方の「duke」証明書をインストールすると、サンプルコードは正しく動作しません。証明書ファイルで利用できる証明書を表示するには、keytool コマンドを使用します。

SSLSocketClient の実行

SSLSocketClient.java プログラムは、SSLSocket を使うクライアントを作成し、HTTP 要求を送信して HTTP サーバーから応答を受け取る方法を実際に示します。このプログラムの出力が、https://www.verisign.com/index.html の HTML ソースです。

ファイアウオールの外側で、このプログラムを出荷時の状態で実行しないでください。ファイアウォールの外側で実行すると、JSSE はファイアウォールを通じた www.verisign.com へのパスを検出できないので、UnknownHostException を受け取ります。ファイアウォールの外側から実行できる同等のクライアントを作成するには、サンプルプログラム SSLSocketClientWithTunneling で示すように、プロキシトンネリングを設定します。

SSLSocketClientWithTunneling の実行

SSLSocketClientWithTunneling.java プログラムは、ファイアウォールの外側から安全な Web サーバーにアクセスするプロキシトンネリングの方法を示します。このプログラムを実行するには、次の Java システムプロパティーに適切な値を設定する必要があります。

java -Dhttps.proxyHost=webproxy
     -Dhttps.proxyPort=ProxyPortNumber

     SSLSocketClientWithTunneling

注: プロキシを指定する際、-D オプション (青字) はオプションです。webproxy は使用するプロキシホスト名に、ProxyPortNumber は適切なポート番号に置き換えてください。

プログラムは https://www.verisign.com/index.html の HTML ソースファイルを返します。

SSLSocketClientWithClientAuth の実行

SSLSocketClientWithClientAuth.java プログラムは、サーバーから要求された場合にキーマネージャーを設定し、クライアント認証を行う方法を示します。このプログラムも、クライアントがファイアウォールの外側にはいないことを前提にしています。SSLSocketClientWithTunneling の例に従ってプログラムを変更すれば、ファイアウォールの内側から接続することもできます。

このプログラムを実行するには、次の 3 つのパラメータを指定する必要があります。ホスト、ポート番号、および要求されたファイルパスです。前回の例を反映させるため、このプログラムをクライアント認証なしで実行できます。ホストに www.verisign.com、ポート番号に 443、要求されたファイルパスに https://www.verisign.com/ を設定します。これらのパラメータを使用したときの出力が、https://www.verisign.com/ の HTML ソースです。

SSLSocketClientWithClientAuth を実行してクライアント認証を行うには、クライアント認証を要求するサーバーにアクセスする必要があります。このサーバーには、サンプルプログラム ClassFileServer を使用できます。これについては、次の節で説明します。

ClassFileServer の実行

ここで ClassFileServer と呼ばれているプログラムは、ClassFileServer.javaClassServer.java の 2 つのファイルで構成されています。

これらを実行するには、ClassFileServer.class を実行します。その際は次のパラメータが必要です。

  • port - ポートのパラメータは、利用できる未使用のポート番号です。たとえば、2001 のような数字を使うことができます。

  • docroot - このパラメータは、検索するファイルを含むサーバーのディレクトリを表します。たとえば、Solaris では /home/userid/ (userid は特定のユーザー ID)、Microsoft Windows では c:\ となります。

  • TLS - オプションのパラメータです。サーバーが SSL または TLS を使用することを表します。

  • true - オプションのパラメータです。クライアント認証が必要なことを表します。このパラメータは、TLS パラメータが設定されているかどうかだけを参照します。

注意 1:TLS および true パラメータはオプションです。使用しない場合は、TLS ではない通常のファイルサーバーだけが認証なしで使用され、何も起こりません。これは、片方の側 (クライアント) が TLS とネゴシエーションを行おうとしても、もう一方の側 (サーバー) はネゴシエーションを行おうとしないため、通信ができないからです。

注意 2: サーバーは "GET /..." の形式で GET 要求を期待します。"..." はファイルへのパスを表します。

ClassFileServer を使った SSLSocketClientWithClientAuth の実行

サンプルプログラム SSLSocketClientWithClientAuth および ClassFileServer を使って、認証済みの通信を設定できます。この通信では、クライアントとサーバーが相互に認証します。両方のサンプルプログラムを同じネットワークに接続された別個のマシン上で実行することも、同じマシン上の別のターミナルウィンドウまたはコマンドプロンプトウィンドウから実行することもできます。クライアントとサーバーを設定するには、次の操作を実行します。

  1. ClassFileServer プログラムを、1 台のマシンやターミナルウィンドウから実行します。ClassFileServer の実行」を参照してください。

  2. SSLSocketClientWithClientAuth プログラムを別のマシンやターミナルウィンドウで実行します。SSLSocketClientWithClientAuth には、次のパラメータが必要です。

    • host - ClassFileServer を実行するマシンのホスト名です。

    • port - ClassFileServer に指定したのと同じポートです。

    • requestedfilepath - サーバーから検索するファイルのパスです。このパラメータには、/filepath を使用します。GET 文の一部として使用されるので、ファイルパスにはフォワードスラッシュが必要です。GET 文には、稼動中のオペレーティングシステムの種類にかかわらず、フォワードスラッシュが必要です。文の構成は次のようになります。
      "GET " + requestedfilepath + " HTTP/1.0"
注: 他の SSLCient* アプリケーションの "GET" コマンドを変更すると、ClassFileServer が動作しているローカルマシンに接続できます。

HTTPS 接続を表すサンプルコード

JSSE を介して安全な通信にアクセスするための主要な API は 2 つあります。1 つは任意の安全な通信に使用できるソケットレベルの APIで、SSLSocketClientSSLSocketClientWithTunneling、および SSLSocketClientWithClientAuth (ClassFileServer を使用する場合と使用しない場合がある) のサンプルプログラムに示されています。

もう 1 つはもっと簡単な方法で、標準の Java URL API を使う方法です。java.net.URL クラスを使った "https" URL プロトコルまたはスキーマを使って、SSL が使用できる Web サーバーと安全に通信できます。

"https" URL スキーマへのサポートは一般的なブラウザの多くに実装されており、JSSE に付属のソケットレベル API を必要とせずに安全な通信にアクセスできます。

URL の例を次に示します。

"https://www.verisign.com"

"https" URL 実装のトラストおよび鍵の管理は、環境に固有です。JSSE 実装は、"https" URL 実装を提供します。別の https プロトコル実装を使用する場合は、パッケージ名に java.protocol.handler.pkgs システムプロパティーを設定できます。詳細については、java.net.URL クラスを参照してください。

JSSE でダウンロードできるサンプルには、HTTPS 接続の作成方法を示すサンプルプログラムが 2 つ含まれています。サンプルプログラム URLReader.javaURLReaderWithOptions.java は、どちらも urls ディレクトリにあります。

URLReader の実行

URLReader.java プログラムは、安全なサイトにアクセスする URL クラスの使い方を示します。このプログラムの出力は、https://www.verisign.com/ の HTML ソースです。デフォルトで、JSSE に付属の HTTPS プロトコル実装が使用されます。別の実装を使用する場合は、システムプロパティー java.protocol.handler.pkgs の値を、実装を含むパッケージ名に設定する必要があります。

ファイアウォールの外側でサンプルコードを実行している場合は、システムプロパティー https.proxyHost および https.proxyPort を設定する必要があります。たとえば、ポート 8080 でプロキシホスト "webproxy" を使う場合は、java コマンドで次のオプションを使用します。

-Dhttps.proxyHost=webproxy

-Dhttps.proxyPort=8080

または、ソースコードのシステムプロパティーに java.lang.System のメソッド setProperty を設定することもできます。たとえば、オプションでコマンド行を使う代わりに、使用するプログラムに次の行を含めることができます。

System.setProperty("java.protocol.handler.pkgs",
"com.ABC.myhttpsprotocol");

System.setProperty("https.proxyHost",
"webproxy");

System.setProperty("https.proxyPort",
"8080");

注: Windows 95 または Windows 98 で実行している場合、コマンド行オプションをすべて含めるには、MS-DOS プロンプトで使用できる文字数では足りない場合があります。その場合、entire コマンドを使用して .bat ファイルを作成するか、ソースコードにシステムプロパティーを追加して、ソースコードを再コンパイルします。

URLReaderWithOptions の実行

URLReaderWithOptions.java プログラムは基本的には URLReader と同じですが、実行時にプログラムの引数として次のシステムプロパティーのどれか、または全部をオプションで入力できる点が異なります。

  • java.protocol.handler.pkgs

  • https.proxyHost

  • https.proxyPort

  • https.cipherSuites

URLReaderWithOptions を実行するには、次のコマンドを 1 行で入力します。

java URLReaderWithOptions
[-h proxyhost -p proxyport]
[-k protocolhandlerpkgs]
[-c ciphersarray]
myApp

注: 複数のプロトコルハンドラを、縦線で区切った項目のリストで protocolhandlerpkgs に含めることができます。複数の SSL 暗号群名を、カンマで区切った項目のリストで ciphersarray に含めることができます。可能な暗号群名は SSLSocket.getSupportedCipherSuites() 呼び出しで返されたものと同じです。暗号群は SSL および TLS プロトコルの仕様から命名されています。

米国 Sun Microsystems, Inc. が提供するデフォルトのプロトコルハンドラ実装以外の HTTPS プロトコルハンドラ実装を使う場合は、protocolhandlerpkgs 引数だけが必要です。

ファイアウォールの外側で実行している場合は、プロキシホストおよびプロキシポートの引数を含める必要があります。また、使用できる暗号群のリストを含めることもできます。

次に、URLReaderWithOptions の実行例と、ポート 8080 にプロキシポート "webproxy" を指定する場合の例を示します。

java URLReaderWithOptions
-h webproxy -p 8080

安全な RMI 接続を表すサンプルコード

samples/rmi ディレクトリのサンプルコードは、安全な RMI 接続の作成方法を示しています。サンプルコードは、RMI のサンプルに基づいています。基本的には "Hello World" のサンプルを変更し、カスタム RMI ソケットファクトリをインストールして使用します。

RMI については、Java RMI ドキュメントを参照してください。この Web ページは、RMI のチュートリアルと RMI に関する他の情報を記載した Web ページです。

SSLEngine の使用を表すサンプルコード

SSLEngine は、アプリケーション開発者に I/O および計算戦略を選択するときの柔軟性を提供するために、Java 2 プラットフォームの Java SE 5 リリースに導入されました。SSLEngine は、SSL/TLS 実装を特定の I/O 抽象化 (シングルスレッド SSLSockets など) に結びつけるのではなく、I/O および計算の制約を SSL/TLS 実装から除外します。

前述したように、SSLEngine は高度な API であり、不用意に使用することはできません。ここでは、その使用を説明するのに役立つ入門用サンプルコードを示します。最初のデモは、ほとんどの I/O およびスレッドの発行を除外し、SSLEngine メソッドの多くに重点を置きます。2 番目のデモは、より現実的な例であり、SSLEngine がどのように Java NIO と結合して基本的な HTTP/HTTPS サーバーを作成するかを示します。

SSLEngineSimpleDemo の実行

SSLEngineSimpleDemo は単純なアプリケーションであり、I/O およびスレッドの発行を単純化して SSLEngine の操作に重点を置いています。このアプリケーションは、一般的な ByteBuffer によって SSL/TLS メッセージを交換する 2 つの SSLEngine を作成します。1 つのループがすべてのエンジン操作を順番に実行して、安全な接続の確立 (ハンドシェーク)、アプリケーションデータの転送、およびエンジンのクローズを示します。

SSLEngineResult は、SSLEngine の現在の状態に関して多くの情報を提供します。この例では、すべての状態を調べてはいません。I/O およびスレッドの発行を適度に単純化しているため本番稼動環境に適した例ではありませんが、SSLEngine の全体的な機能の説明に有用です。

NIO ベースのサーバーの実行


注: この項で説明するサーバーの例は、Java SE Development Kit 6 に含まれています。コードは、<jdk-home>/samples/nio/server ディレクトリにバンドルされています。
SSLEngine によって提供される柔軟性を十分に利用するには、最初に I/O やスレッドのモデルなどの相補的な API を理解します。

大規模なアプリケーションの開発者が有用と考える I/O モデルは、NIO SocketChannel です。NIO は、java.net.Socket API に内在するスケーリングの問題のいくつかを解決するために部分的に導入されました。SocketChannel には、次のようなさまざまな操作モードがあります。

  • ブロック
  • 非ブロック
  • セレクタによる非ブロック
最小限の HTTP サーバーのサンプルコードが提供されています。このコードは、新しい NIO API の多くを示すだけでなく、SSLEngine を使用して安全な HTTPS サーバーを作成する方法も示します。サーバーは本番稼動の品質ではありませんが、これらの新しい API の多くを実際に示しています。

サンプルディレクトリには README.txt ファイルがあり、サーバーの紹介、構築および構成方法の説明、コードレイアウトの概要が含まれています。SSLEngine のユーザーにとってもっとも重要なファイルは、ChannelIO.java および ChannelIOSecure.java です。

JSSE で使用するキーストアの作成

単純なキーストアとトラストストアの作成

この節では、keytool を使って、JSSE での使用に適した単純な JKS キーストアを作成します。キーストア内に (公開/非公開鍵を持つ) keyEntry を作成し、トラストストア内に対応する trustedCertEntry (公開鍵のみ) を作成します。クライアント認証の場合、クライアントの証明書に対して同じ処理を行う必要があります。注: 信頼できるアンカーの PKCS12 での格納はサポートされていません。信頼できるアンカーの格納には JKS、非公開鍵の格納には PKCS12 を使用する必要があります。
注: ここでは、各ステップに関する詳しい解説は省略します。詳細については、Solaris または Microsoft Windows の keytool に関するドキュメントを参照してください。
ユーザー入力は太字で示します。
  1. 対応する公開/非公開鍵とともに、新しいキーストアと自己署名付き証明書を作成します。
    % keytool -genkeypair -alias duke -keyalg RSA \
    -validity 7 -keystore keystore
    Enter keystore password: password What is your first and last name? [Unknown]: Duke What is the name of your organizational unit? [Unknown]: Java Software What is the name of your organization? [Unknown]: Sun Microsystems, Inc. What is the name of your City or Locality? [Unknown]: Palo Alto What is the name of your State or Province? [Unknown]: CA What is the two-letter country code for this unit? [Unknown]: US
    Is CN=Duke, OU=Java Software, O="Sun Microsystems, Inc.",
    L=Palo Alto, ST=CA, C=US correct?
    [no]: yes Enter key password for <duke> (RETURN if same as keystore password): <CR>
    これが、サーバーの使用するキーストアです。

  2. キーストアを調べます。エントリタイプが keyEntry (赤字) になっている点に注目してください。これは、このエントリに非公開鍵が関連付けられていることを示します。
    % keytool -list -v -keystore keystore
    Enter keystore password:  password
    
    Keystore type: jks
    Keystore provider: SUN
    
    Your keystore contains 1 entry
    
    Alias name: duke
    Creation date: Dec 20, 2001
    Entry type: keyEntry
    Certificate chain length: 1
    Certificate[1]:
    Owner: CN=Duke, OU=Java Software, O="Sun Microsystems, Inc.",
    L=Palo Alto, ST=CA, C=US
    Issuer: CN=Duke, OU=Java Software, O="Sun Microsystems, Inc.", L=Palo Alto, ST=CA, C=US
    Serial number: 3c22adc1
    Valid from: Thu Dec 20 19:34:25 PST 2001 until: Thu Dec 27 19:34:25 PST 2001
    Certificate fingerprints:
        MD5: F1:5B:9B:A1:F7:16:CF:25:CF:F4:FF:35:3F:4C:9C:F0
        SHA1: B2:00:50:DD:B6:CC:35:66:21:45:0F:96:AA:AF:6A:3D:E4:03:7C:74
          

  3. 自己署名付き証明書をエクスポートし、内容を調べます。
    % keytool -export -alias duke -keystore keystore -rfc \
    -file duke.cer
    Enter keystore password: password Certificate stored in file <duke.cer> % cat duke.cer -----BEGIN CERTIFICATE----- MIICXjCCAccCBDwircEwDQYJKoZIhvcNAQEEBQAwdjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNB MRIwEAYDVQQHEwlQYWxvIEFsdG8xHzAdBgNVBAoTFlN1biBNaWNyb3N5c3RlbXMsIEluYy4xFjAU BgNVBAsTDUphdmEgU29mdHdhcmUxDTALBgNVBAMTBER1a2UwHhcNMDExMjIxMDMzNDI1WhcNMDEx MjI4MDMzNDI1WjB2MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExEjAQBgNVBAcTCVBhbG8gQWx0 bzEfMB0GA1UEChMWU3VuIE1pY3Jvc3lzdGVtcywgSW5jLjEWMBQGA1UECxMNSmF2YSBTb2Z0d2Fy ZTENMAsGA1UEAxMERHVrZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1loObJzNXsi5aSr8 N4XzDksD6GjTHFeqG9DUFXKEOQetfYXvA8F9uWtz8WInrqskLTNzwXgmNeWkoM7mrPpK6Rf5M3G1 NXtYzvxyi473Gh1h9k7tjJvqSVKO7E1oFkQYeUPYifxmjbSMVirWZgvo2UmA1c76oNK+NhoHJ4qj eCUCAwEAATANBgkqhkiG9w0BAQQFAAOBgQCRPoQYw9rWWvfLPQuPXowvFmuebsTc28qI7iFWm6BJ TT/qdmzti7B5MHOt9BeVEft3mMeBU0CS2guaBjDpGlf+zsK/UUi1w9C4mnwGDZzqY/NKKWtLxabZ 5M+4MAKLZ92ePPKGpobM2CPLfM8ap4IgAzCbBKd8+CMp8yFmifze9Q== -----END CERTIFICATE-----
    この例では説明しませんが、-certreq を指定して証明書署名要求 (CSR) を生成し、証明書発行局 (CA) に送付して署名を求めることもできます。

  4. 証明書を新しいトラストストアにインポートします。
    % keytool -import -alias dukecert -file duke.cer \
    -keystore truststore
    Enter keystore password: trustword Owner: CN=Duke, OU=Java Software, O="Sun Microsystems, Inc.", L=Palo Alto, ST=CA, C=US Issuer: CN=Duke, OU=Java Software, O="Sun Microsystems, Inc.", L=Palo Alto, ST=CA, C=US Serial number: 3c22adc1 Valid from: Thu Dec 20 19:34:25 PST 2001 until: Thu Dec 27 19:34:25 PST 2001 Certificate fingerprints: MD5: F1:5B:9B:A1:F7:16:CF:25:CF:F4:FF:35:3F:4C:9C:F0 SHA1: B2:00:50:DD:B6:CC:35:66:21:45:0F:96:AA:AF:6A:3D:E4:03:7C:74 Trust this certificate? [no]: yes Certificate was added to keystore
  5. トラストストアを調べます。エントリタイプが trustedCertEntry (赤字) になっている点に注目してください。これは、このエントリに非公開鍵が関連付けられていることを示します。このエントリタイプから、このファイルが KeyManager のキーストアとして適切でないこともわかります。
    % keytool -list -v -keystore truststore 
    Enter keystore password: trustword Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry Alias name: dukecert Creation date: Dec 20, 2001 Entry type: trustedCertEntry Owner: CN=Duke, OU=Java Software, O="Sun Microsystems, Inc.", L=Palo Alto, ST=CA, C=US Issuer: CN=Duke, OU=Java Software, O="Sun Microsystems, Inc.", L=Palo Alto, ST=CA, C=US Serial number: 3c22adc1 Valid from: Thu Dec 20 19:34:25 PST 2001 until: Thu Dec 27 19:34:25 PST 2001 Certificate fingerprints: MD5: F1:5B:9B:A1:F7:16:CF:25:CF:F4:FF:35:3F:4C:9C:F0 SHA1: B2:00:50:DD:B6:CC:35:66:21:45:0F:96:AA:AF:6A:3D:E4:03:7C:74
    ここで、適切なキーストアを使ってアプリケーションを実行します。この例では、デフォルトの X509KeyManager および X509TrustManager を使用するものとします。したがって、「カスタマイズ」で説明したシステムプロパティーを使用してキーストアを選択します。
    % java -Djavax.net.ssl.keyStore=keystore \
    -Djavax.net.ssl.keyStorePassword=password Server

    % java -Djavax.net.ssl.trustStore=truststore \
    -Djavax.net.ssl.trustStorePassword=trustword Client


注: この例では、サーバーの認証のみを行なっています。クライアントの認証が必要な場合は、クライアントの鍵に対して同様のキーストアを用意し、サーバーに対して適切なトラストストアを提供する必要があります。

付録 A: 標準名

JDK Security API は、さまざまなアルゴリズム、証明書、およびキーストアのタイプの標準名を必要とし、これらを使用します。以前にこの付録 A およびほかの仕様 (JCA/CertPath/その他) にあった仕様名は、標準名のドキュメントにまとめられました。特定のプロバイダの情報は、「Sun Provider Documentation」にあります。

付録 B: プロバイダのプラグイン可能性

Java SE 6 の JSSE はプラグイン可能であり、サードパーティーの JSSE プロバイダの使用には何の制限もありません。


Copyright © 1995, 2010, Oracle and/or its affiliates. All rights reserved.

Please send comments using this Feedback page.
Oracle Corporation and/or its affiliates
Java Technology