用語と定義
- はじめに
- 特長と利点
- 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 要件
- ピアのアイデンティティー情報
- セキュリティーマネージャー
- トラブルシューティング
- 構成上の問題点
- デバッグユーティリティー
付録 A: 標準名
- コード例
- 安全でないソケットから安全なソケットへの変換
- JSSE サンプルコードの実行
- JSSE で使用するキーストアの作成
ネットワークを通じてやり取りされるデータには、意図された受信者以外の人も、簡単にアクセスできます。データにパスワードやクレジットカード番号などの個人情報が含まれる場合、権限のない者がデータを理解できないよう、手段を講じる必要があります。また、意図的であるかどうかに関わらず、通信中にデータが変更されないようにすることも重要です。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 には次のような重要な特長があります。
- JRE 1.4 以降の標準のコンポーネントとして含まれている
- 拡張可能なプロバイダベースのアーキテクチャー
- 100% Pure Java に実装される
- SSL バージョン 2.0 と 3.0 および TLS 1.0 以降の API をサポートし、SSL 3.0 および TLS 1.0 を実装する
- 安全なチャネルを作成するためにインスタンス化可能なクラスを含む (
SSLSocket
、SSLServerSocket
、およびSSLEngine
)- 安全な通信を開始し、検証するのに使用される SSL ハンドシェーク機能の一部として、暗号群ネゴシエーションをサポートする
- 通常の SSL ハンドシェーク機能の一部として、クライアントとサーバーの認証をサポートする
- SSL プロトコル (HTTPS) でカプセル化された Hypertext Transfer Protocol (HTTP) をサポートする。これにより、HTTPS を使用する Web ページなどのデータにアクセスできる
- メモリ常駐型の SSL セッションを管理するためのサーバーセッション管理 API を提供する
- 暗号群で一般的に使用される複数の暗号化アルゴリズムをサポートする。次の表に示すアルゴリズムが含まれる
JSSE で利用できる暗号化機能
暗号化アルゴリズム *
暗号化処理
鍵の長さ (ビット)
RSA
認証と鍵交換
512 以上
RC4
バルク暗号化
128
128 (40 が有効)DES
バルク暗号化
64 (56 が有効)
64 (40 が有効)Triple DES
バルク暗号化
192 (112 が有効)
AES
バルク暗号化
256
128Diffie-Hellman
鍵の承認
1024
512DSA
認証
1024
* Note:SunJSSE 実装では、暗号化アルゴリズムのすべてにおいて JavaTM 暗号化拡張機能 (JCE) を使用します。
JSSE 標準 API
JSSE 標準 API は、
javax.net
およびjavax.net.ssl
パッケージで利用できる API で、次の点をカバーします。
- 安全なソケット (SSL) およびサーバーソケット
- SSL/TLS データを生成および消費する非ブロックエンジン (SSLEngine)
- ソケット、サーバーソケット、SSL ソケット、および SSL サーバーソケットを作成するファクトリ。ソケットの作成および構成をカプセル化できるソケットファクトリの使用
- 安全なソケットファクトリとエンジンのファクトリとして動作する安全なソケットコンテキストを表すクラス
- X.509 固有のキーマネージャーやトラストマネージャーなどの鍵およびトラストマネージャーインタフェース、およびそれらのインタフェースを作成するために使用可能なファクトリ
- 安全な HTTP URL 接続用のクラス (HTTPS)
SunJSSE
プロバイダSun の Java SE の実装には、「
SunJSSE
」という名前の JSSE プロバイダが含まれています。このプロバイダはあらかじめインストールされ、JCA に登録されています。このプロバイダが提供する暗号化サービスは次のとおりです。このプロバイダの詳細は、「SunJSSE」の項を参照してください。
SSL 3.0 および TLS 1.0 セキュリティープロトコルの実装
もっとも一般的な SSL および TLS 暗号群の実装。一組の認証、鍵の承認、暗号化、および整合性保護を含む
X.509 ベースのキーマネージャーの実装。標準的な JCA KeyStore から適切な認証キーを選択する
証明書チェーンパスを検証する規則を実装する、X.509 ベースのトラストマネージャーの実装
JCA キーストア型「pkcs12」として PKCS12 を実装PKCS12 の信頼できるアンカーの格納は未サポート。ユーザーは、JKS 形式で信頼できるアンカーを格納し、PKCK12 形式で非公開鍵を保存する
関連ドキュメント
Java Secure Socket Extension 関連ドキュメント
JSSE ホームページ。 JavaOneSM カンファレンスのスライドへのリンク、JSSE FAQ、法律上の問題など:
http://java.sun.com/products/jsse/- Sun の Java セキュリティーチーム (java-security@sun.com) に寄せられた API に関する質問と回答 -
http://archives.java.sun.com/archives/java-security.html注: 上記のメーリングリストは、購読リストやサポート機構ではありません。これは、Java SE 6 Standard Edition セキュリティーチームへのコメントの送付のみを目的としています。
- JSSE API 関連ドキュメント -
Java プラットフォームのセキュリティー関連ドキュメント
Java セキュリティーホームページ -
http://java.sun.com/security/JavaTM Certification Path API プログラマーズガイド: http://java.sun.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html
その他の Java SE 6 プラットフォームセキュリティードキュメント -
http://java.sun.com/javase/6/docs/technotes/guides/security/Java プラットフォームセキュリティーのチュートリアル -
http://java.sun.com/docs/books/tutorial/security/- Java SE プラットフォームセキュリティーに関する文書 -
Inside Java 2 Platform Security:Architecture, API Design, and Implementation (Li Gong 著)Addison Wesley Longman, Inc., 1999. ISBN:0201310007. http://java.sun.com/docs/books/security/index.html暗号化に関する輸出上の問題
米国の暗号政策については、次のサイトを参照してください。
米国商務省:
http://www.commerce.gov輸出規制に関するページ -
http://www.crypto.com/Computer Systems Public Policy (CSPP) -
http://www.cspp.org/連邦情報処理標準出版物 (FIPS PUBS) のホームページ。 データ暗号化規格 (DES) へのリンクあり: http://www.itl.nist.gov/fipspubs/
米国暗号化輸出規制 (改訂版) -
http://www.epic.org/crypto/export_controls/regs_1_00.html暗号化に関するドキュメント
オンラインリソース
- Rivest 博士の暗号化とセキュリティーのページ -
http://theory.lcs.mit.edu/~rivest/crypto-security.html書籍:
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 関連ドキュメント
オンラインリソース
Sun™ ONE ソフトウェアからの SSL の導入:
http://docs.sun.com/source/816-6156-10/contents.htmSSL プロトコルバージョン 3.0 インターネットドラフト:
http://wp.netscape.com/eng/ssl3/ssl-toc.htmlTLS プロトコルバージョン 1.0 RFC:
http://www.ietf.org/rfc/rfc2246.txt"HTTP Over TLS" の RFC 情報:
http://www.ietf.org/rfc/rfc2818.txt書籍:
『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) は、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 メッセージは、次の順序で送信されます。
- Client hello - クライアントはサーバー情報を送信します。この情報には、自分がサポートする最上位バージョンの SSL と暗号群のリストが含まれます。TLS 1.0 は SSL 3.1 と表示されます。暗号群の情報には、暗号化アルゴリズムと鍵のサイズが含まれます。
- Server hello - サーバーは、クライアントとサーバーの両方がサポートする最上位バージョンの SSL と最適な暗号群を選択し、この情報をクライアントに送信します。
- Certificate - サーバーはクライアントに証明書または証明書チェーンを送信します。証明書チェーンは通常、サーバーの公開鍵証明書で始まり、認証局のルート証明書で終わります。このメッセージはオプションで、サーバー認証を求められた場合に使用します。
- Certificate request - サーバーがクライアントを認証する必要がある場合、クライアントに証明書要求を送信します。インターネットアプリケーションでは、このメッセージが使われることはほとんどありません。
- Server key exchange - 上記の 3 で送信した公開鍵情報が鍵交換を行うのに不十分な場合、サーバーはクライアントにサーバー鍵交換メッセージを送信します。
- Server hello done - サーバーは、最初のネゴシエーションメッセージを終了したことをクライアントに伝えます。
- Certificate - メッセージ 4 でサーバーがクライアントに証明書を要求すると、クライアントはメッセージ 3 でサーバーが行なったようにして、証明書チェーンを送信します。
注: クライアントに証明書を要求するのは、ごく一部のインターネットサーバーアプリケーションだけです。
- Client key exchange - クライアントは、対称暗号方式で使用する鍵を作成する情報を生成します。RSA では、クライアントはサーバーの公開鍵でこの鍵情報を暗号化してサーバーに送信します。
- Certificate verify - このメッセージは、上述のとおりクライアントが証明書を提示する場合に送信されます。このメッセージは、サーバーにクライアントの認証処理を完了させるためのものです。このメッセージが使用されると、クライアントは暗号化ハッシュ関数で電子的に署名した情報を送信します。サーバーがクライアントの公開鍵でこの情報を復号化すれば、サーバーはクライアントを認証できます。
- Change cipher spec - クライアントはメッセージを送信し、暗号化モードを変更するようサーバーに伝えます。
- Finished - クライアントはサーバーに、安全なデータ通信を開始する準備ができたことを伝えます。
- Change cipher spec - サーバーはメッセージを送信し、暗号化モードを変更するようクライアントに伝えます。
- Finished - サーバーはクライアントに、安全なデータ通信を開始する準備ができたことを伝えます。SSL ハンドシェークが終了します。
- Encrypted data - クライアントとサーバーは、メッセージ 1 と 2 で取り決めた対称暗号化アルゴリズムと暗号化ハッシュ関数、およびメッセージ 8 でクライアントがサーバーに送信した秘密鍵を使って通信します。
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
はSSLSocketFactory
またはインバウンド接続を受け取るSSLServerSocket
によって作成されます。SSLServerSocket
はSSLServerSocketFactory
で作成されます。SSLSocketFactory
およびSSLServerSocketFactory
オブジェクトはどちらもSSLContext
で作成されます。SSLEngine は、SSLContext によって直接作成され、アプリケーションに依存してすべての入出力を処理します。
重要: rawSSLSockets/SSLEngines
を使用する場合は、データの送信前に必ずピアの資格をチェックしてください。たとえばSSLSocket/SSLEngine
クラスは、URL のホスト名がピアの資格にあるホスト名と一致するかどうかを自動的に検証しません。ホスト名が検証されなければ、URL 不正行為によって被害を受ける可能性があります。
SSLContext
を取得して初期化するには、次の 2 通りの方法があります。
- もっとも簡単な方法は、
SSLSocketFactory
またはSSLServerSocketFactory
クラスでgetDefault
static メソッドを呼び出すことです。これらのメソッドは、デフォルトのKeyManager
、TrustManager
、および安全な乱数発生関数を使ってデフォルトのSSLContext
を作成します。デフォルトのKeyManagerFactory
およびTrustManagerFactory
を使うと、KeyManager
およびTrustManager
がそれぞれ作成されます。使用する鍵データはデフォルトのキーストアおよびトラストストアにあり、「デフォルトの鍵とトラストストア、ストア型、およびストアパスワードのカスタマイズ」で説明するシステムプロパティーで設定します。- 作成したコンテキストの動作を呼び出し側でもっともよく管理できる方法は、
SSLContext
クラスでgetInstance
static メソッドを呼び出し、さらにそのインスタンスの適切なinit
メソッドを呼び出してコンテキストを初期化することです。init
メソッドの派生関数は、次の 3 つの引数を取ります。KeyManager
オブジェクトの配列、TrustManager
オブジェクトの配列、およびSecureRandom
乱数発生関数です。適切なインタフェースを実装するか、KeyManagerFactory
クラスとTrustManagerFactory
クラスを使って実装を生成することにより、KeyManager
オブジェクトとTrustManager
オブジェクトが作成されます。次に、KeyManagerFactory
およびTrustManagerFactory
クラスを、TrustManagerFactory/KeyManagerFactory
のinit
メソッドで引数として渡されたKeyStore
に含まれる鍵データで初期化します。最後に、TrustManagerFactory
のgetTrustManagers
メソッドとKeyManagerFactory
のgetKeyManagers
メソッドを呼び出して、トラストマネージャーまたはキーマネージャーの配列を取得します。どちらもトラストデータや鍵データの型の 1 つです。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 つあります。入出力を抽象化し、データをバイトのストリームとして処理することによってこれらの問題を解決した結果、新しい API は既存または将来のどんな入出力モデルでも使用できるようになりました。このソリューションでは、入出力と CPU の処理が開発者に任されますが、構成不能または変更不能な内部の詳細設定によって JSSE 実装を使用できなくなるような状況を防止しています。
- クラス階層、および
Selector
や他のタイプのSocketChannel
との相互動作方法など、SSLSocketChannel
をどのような API にすべきかということに関して、難問が数多くありました。SSL/TLS に対応するために拡張された新しい API 抽象化は、どれも同じほど重要な分析が必要となり、大規模で複雑な API になる可能性のあることが判明しました。
- 新しい API のすべての JSSE 実装では、最善の入出力および計算戦略を自由に選択することになりましたが、これらの詳細事項を隠すことは、全面的な制御権を必要とするアプリケーションにとっては不適切です。どんな固有の実装方法も、アプリケーションセグメントによっては適さない場合があります。
JGSS や SASL など、他の Java プログラミング言語 API のユーザーは、アプリケーションがデータをトランスポートする機能を果たすという類似点があることに気付くでしょう。
SSLEngine
この新しい抽象化方法のコアクラスは、javax.net.ssl.SSLEngine です。このコアクラスは、SSL/TLS 状態マシンをカプセル化し、SSLEngine のユーザーによって供給されるインバウンドとアウトバウンドのバイトバッファー上で動作します。次の図は、アプリケーションから送り出され、SSLEngine とトランスポート機構を経て再び戻ってくるデータフローの様子を示しています。左側に示されるアプリケーションは、アプリケーションのプレーンテキストデータをアプリケーションバッファーに供給し、SSLEngine に渡します。SSLEngine は、バッファーに格納されているデータまたはハンドシェークデータを処理して SSL/TLS 符号化データを生成し、アプリケーションによって提供されるネットワークバッファーに格納します。次にアプリケーションは、右側に示されている適切なトランスポートを使用して、ネットワークバッファーの内容をピアに送信する役割を実行します。トランスポートを介してピアから SSL/TLS 符号化データを受け取ると、アプリケーションはそのデータをネットワークバッファーに格納し、SSLEngine に渡します。SSLEngine は、ネットワークバッファーの内容を処理し、ハンドシェークデータまたはアプリケーションデータを生成します。
SSLEngine は、全体として次に示す 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 フィールドは、ハンドシェークを続行するために実行する必要のある以下の動作を決定するために使用されます。
標準的なハンドシェークでは次のような動作が行われます。
これでハンドシェークが完了します。 さらに wrap() への別の呼び出しがあると、アプリケーションデータおよびパッケージを消費してトランスポートしようとします。 unwrap() は反対の動作を試みます。
クライアント
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
ピアにデータを送信するには、まずアプリケーションが送信するデータを SSLEngine.wrap() を介して SSLEngine に送信し、対応する SSL/TLS 符号化データを取得します。次にアプリケーションは、選択したトランスポート機構を使用して符号化データをピアに送信します。アプリケーションは、トランスポート機構を介してピアから SSL/TLS 符号化データを受け取ると、SSLEngine.unwrap() を介してそのデータを SSLEngine に送り、ピアによって送信されたプレーンテキストデータを取得します。
非ブロック SocketChannel を使用してピアと通信する SSL アプリケーションの例を次に示します。SSL アプリケーションは、非ブロック SocketChannel を組み込んだ Selector を使用することにより、堅牢性と拡張性を高めることができます。以下のサンプルコードは、前の例で作成した SSLEngine を使用して符号化することにより、ピアに文字列 「hello」 を送信します。バイトバッファーのサイズは、SSLSession からの情報を使用して決定されます。
以下のコードは、非ブロック SocketChannel からデータを読み取り、前に作成した SSLEngine を使用して、そのデータからプレーンテキストを抽象化します。このコードが反復されるごとに、ハンドシェーク処理が進行しているかどうかに応じて、プレーンテキストが生成されたり、生成されなかったりします。// 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 ... }// 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 からクローズメッセージを取得し、トランスポート機構を使用してそれらのメッセージをピアに送信して、最後にトランスポート機構をシャットダウンします。次に例を示します。SSLEngine を明示的にクローズするアプリケーションに加え、SSLEngine は、ハンドシェークデータを処理している間にクローズメッセージを受け取ることにより、ピアによってクローズされます。 または、アプリケーションデータまたはハンドシェークデータを処理している間にエラーが発生した SSLEngine によってクローズされます。そのエラーは、SSLException がスローされることによって示されます。 そのような場合アプリケーションは、SSLEngine.wrap() を呼び出してクローズメッセージを取得し、前の例に示されるように SSLEngine.isOutboundDone() が true 値を返すまで、または SSLEngineResult.getStatus() が CLOSED を返すまでそのメッセージをピアに送信します。// 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();正常なシャットダウンに加え、クローズメッセージが交換される前にトランスポートリンクを切断する非常シャットダウン方法があります。前の例では、非ブロック 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.HttpsURLConnection
はjava.net.HttpsURLConnection
クラスを拡張し、https に固有の機能をサポートします。https URL の構造と使用法の詳細については、java.net.URL
,java.net.URLConnection
、java.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
パッケージに含まれています。この節で説明するクラスは
SSLContext
、KeyManagerFactory
、およびTrustManagerFactory
の 3 つで、いずれもエンジンクラスです。エンジンクラスとは、特定のアルゴリズムの API クラス (SSLContext
の場合はプロトコル) です。1 つまたは複数の暗号化サービスプロバイダ (プロバイダ) パッケージで実装が提供されることがあります。プロバイダとエンジンクラスの詳細は、「JavaTM 暗号化アーキテクチャーリファレンスガイド」の「設計方針」と「概念」のセクションを参照してください。JSSE に標準で付属する
SunJSSE
プロバイダは、SSLContext
、KeyManagerFactory
、および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 にすることができます。その場合、デフォルト実装が使用されます。内部のデフォルトコンテキストが使用される場合 (
SSLContext
はSSLSocketFactory.getDefault()
またはSSLServerSocketFactory.getDefault()
によって作成されるなど) は、デフォルトのKeyManager
とTrustManager
が作成されます。また、デフォルトのSecureRandom
実装も選択されます。
TrustManager
InterfaceTrustManager
は、提示された認証クレデンシャルの信頼性を判定します。信頼できないクレデンシャルの場合、接続は切断されます。安全なソケットピアのリモート識別情報を認証するには、1 つまたは複数のTrustManager
でSSLContext
オブジェクトを初期化する必要があります。サポートされる認証機構のそれぞれに対し、TrustManager
を 1 つ渡す必要があります。SSLContext
の初期化中に NULL が渡されると、トラストマネージャーが作成されます。通常は、X.509 公開鍵証明書 (X509TrustManager
など) に基づく認証をサポートする単一のトラストマネージャーが存在しています。安全なソケット実装には、共有の秘密鍵、Kerberos、またはその他の機構に基づく認証をサポートするものもあります。
TrustManager
はTrustManagerFactory
によって、またはインタフェースの具体的な実装を行うことによって作成されます。
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
メソッドを呼び出すのが適切です。
TrustManagerFactory
はKeyStore
に、認証チェック中に信頼すべきリモート証明書の情報を問い合わせます。場合によっては、
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.checkRevocation
をtrue
に設定します。この設定では、CertPath 実装自身が取り消し情報の場所を検出する必要があります。SUN プロバイダの PKIX 実装では多くの場合にこの動作を実行できますが、システムプロパティーcom.sun.security.enableCRLDP
をtrue
に設定する必要があります。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
に渡される場合、ファクトリは次の手順でトラストデータを検索します。
- システムプロパティー
が定義されている場合、javax.net.ssl.trustStoreTrustManagerFactory
は、このシステムプロパティーで指定したファイル名を使ってファイルを検索し、このファイルをキーストアで使用します。システムプロパティーjavax.net.ssl.trustStorePassword
が同様に定義されている場合は、ファイルを開く前に、その値を使ってトラストストアのデータの整合性をチェックします。
javax.net.ssl.trustStore
が定義されているものの、指定したファイルが存在しない場合、空のキーストアを使用するデフォルトのTrustManager
が作成されます。javax.net.ssl.trustStore
システムプロパティーが指定されておらず、さらにファイルが存在すれば、そのファイルを使用します。<java-home>/lib/security/jssecacerts<java-home>
の詳細については、「インストールディレクトリ <java-home>」を参照してください。それ以外の場合、- ファイル
が存在すれば、そのファイルを使用します。<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 つまたは複数のKeyManager
でSSLContext
オブジェクトを初期化する必要があります。 サポートされる各認証機構に、KeyManager
を 1 つ渡す必要があります。
SSLContext
の初期化中に NULL が渡されると、空のKeyManager
が作成されます。内部のデフォルトコンテキストが使用される場合 (SSLContext
はSSLSocketFactory.getDefault()
またはSSLServerSocketFactory.getDefault()
によって作成されるなど) は、デフォルトのKeyManager
が作成されます。通常は、X.509
公開鍵証明書に基づく認証をサポートするキーマネージャーが 1 つあります。安全なソケット実装には、共有の秘密鍵、Kerberos、またはその他の機構に基づく認証をサポートするものもあります。
KeyManager
はKeyManagerFactory
によって、またはインタフェースの具体的な実装を行うことによって作成されます。
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
メソッドを呼び出すのが適切です。KeyManagerFactory
はKeyStore
に、リモートのソケットピアを認証するために使用する非公開鍵、および対応する公開鍵証明書について問い合わせます。パスワードパラメータは、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
を作成できます。
TrustManager
とKeyManager
の関連性これまでは、TrustManager
とKeyManager
の機能がしばしば混同されてきました。 ここでは、各マネージャー型の主な機能を要約します。
型 機能 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());HostnameVerifier
をHttpsURLConnection
に割り当てる方法については、「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
クラスを使用するコード」を参照してください。
インストールディレクトリ<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> は、JRE ランタイムソフトウェアのインストールディレクトリです。インストールディレクトリ <java-home> を参照してください。<java-home>/lib/security/java.securityセキュリティープロパティーファイルでセキュリティープロパティー値を指定するには、次の行を追加します。
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.MyX509CertificateImplHTTPS プロトコルの代替実装
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 のエンジンクラスはSSLContext
、KeyManagerFactory
、および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.getDefault
やSSLServerSocketFactory.getDefault
を呼び出すことでデフォルトのSSLSocketFactory
やSSLServerSocketFactory
が作成され、このデフォルトの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.keyStoreType
とjavax.net.ssl.keyStorePassword
の両方またはどちらか一方が指定されている場合、それぞれがデフォルトのKeyManager
キーストア型とパスワードとして扱われます。型が指定されていない場合、デフォルトの型はKeyStore.getDefaultType()
が返すkeystore.type
セキュリティープロパティーの値です。 また、そうしたセキュリティープロパティーが指定されていない場合は「jks」になります。キーストアのパスワードが指定されていない場合は "" とみなされます。同様に、システムプロパティー
javax.net.ssl.trustStoreType
とjavax.net.ssl.trustStorePassword
の両方またはどちらか一方が指定されている場合、それぞれがデフォルトのトラストストア型とパスワードとして扱われます。型が指定されていない場合、KeyStore.getDefaultType()
によってデフォルト型が返されます。トラストストアのパスワードが指定されていない場合は "" とみなされます。重要: この節では、現在の JSSE リファレンス実装の動作を説明します。この節で説明するシステムプロパティーの名前と型 (システムかセキュリティーか) が今後も使用されるという保証はありません。また、今後のリリースで存在するという保証もありせん。また、他の JSSE 実装での検証や使用も保証されていません。実装で検証された場合、個々で説明した JSSE リファレンス実装と同じ方法で処理してください。
デフォルトのキーマネージャーおよびトラストマネージャーのカスタマイズ
「デフォルトの鍵とトラストストア、ストア型、およびパスワードのカスタマイズ」で説明したように、デフォルトの
SSLSocketFactory
やSSLServerSocketFactory
が作成され、このデフォルトのSSLSocketFactory
(またはSSLServerSocketFactory
) が JSSE リファレンス実装に由来する場合は、常にデフォルトのSSLContext
はソケットファクトリに関連付けられます。このデフォルトの
SSLContext
は、デフォルトのKeyManager
およびTrustManager
で初期化されます。デフォルトのSSLContext
に提供されたKeyManager
とTrustManager
の両方またはどちらか一方は、指定したキーストアまたはトラストストアを管理するKeyManager
またはTrustManager
の実装になります。これについては、後の節で説明します。選択される
KeyManager
実装は、まずセキュリティープロパティーを確認して決定されます。そのようなプロパティー値が指定されていると、指定したアルゴリズムのssl.KeyManagerFactory.algorithmKeyManagerFactory
実装が検索されます。実装を提供する最初のプロバイダの実装が使用されます。実装のgetKeyManagers
メソッドが呼び出され、デフォルトのSSLContext
に提供するKeyManager
が決定されます。技術的には、getKeyManagers
はKeyManager
の配列を返します。これは鍵データの型ごとのKeyManager
です。そのようなセキュリティープロパティー値が指定されていない場合、「SunX509」のデフォルト値を使って検索します。注:「SunX509」アルゴリズムのKeyManagerFactory
実装はSunJSSE
プロバイダが提供します。プロバイダが指定するKeyManager
はjavax.net.ssl.X509KeyManager
実装です。同様に、選択される
TrustManager
実装は、まずセキュリティープロパティーを確認して決定されます。そのようなプロパティー値が指定されていると、指定したアルゴリズムのssl.TrustManagerFactory.algorithmTrustManagerFactory
実装が検索されます。実装を提供する最初のプロバイダの実装が使用されます。実装のgetTrustManagers
メソッドが呼び出され、デフォルトのSSLContext
に提供するTrustManager
が決定されます。技術的には、getTrustManagers
はTrustManager
の配列を返します。これは鍵データの型ごとのTrustManager
です。そのようなセキュリティープロパティー値が指定されていない場合、「PKIX」のデフォルト値を使って検索します。注:「PKIX」アルゴリズムのTrustManagerFactory
実装はSunJSSE
プロバイダが提供します。プロバイダが指定するTrustManager
はjavax.net.ssl.X509TrustManager
実装です。重要: この節では、現在の JSSE リファレンス実装の動作を説明します。この節で説明するシステムプロパティーの名前と型 (システムかセキュリティーか) が今後も使用されるという保証はありません。また、今後のリリースで存在するという保証もありせん。また、他の JSSE 実装での検証や使用も保証されていません。実装で検証された場合、個々で説明した JSSE リファレンス実装と同じ方法で処理してください。
暗号化アルゴリズムプロバイダのカスタマイズ
Java SE 5 のリリースから、SunJSSE プロバイダは、暗号化の必要すべてを満たすために SunJCE 実装を使用しています。Sun プロバイダは通常の位置に置くことが推奨されていますが、SunJCE プロバイダより前に登録することにより、他の JCA/JCE プロバイダからの実装を使用することもできます。 プロバイダの構成には、標準 JCA 機構を使用できます。まず、以下のセキュリティープロパティーファイルを利用して静的に行う方法があります。
次に、<java-home>/lib/security/java.securityjava.security.Security
クラスのaddProvider
メソッドまたはinsertProviderAt
メソッドを利用して動的に行う方法があります。<java-home>
の詳細については、「インストールディレクトリ <java-home>」を参照してください。プロバイダの実装を行うユーザーへの注記
SunJSSE が
Cipher.getInstance()
を呼び出すとき、使用される変換文字列は "RSA/ECB/PKCS1Padding"、"RC4"、"DES/CBC/NoPadding"、"DESede/CBC/NoPadding" になります。Cipher クラスと変換文字列の詳細については、「Java 暗号化アーキテクチャーリファレンスガイド」を参照してください。
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);
Java SE 6 の SunJSSE プロバイダは、RFC 2712 で規定される Kerberos 符号化方式をサポートします。以下の符号化方式がサポートされていますが、デフォルトでは有効になっていません。これらの符号化方式を使用可能にするには、明示的に指定する必要がります。詳細については、SSLEngine.setEnabledCipherSuites() および SSLSocket.setEnabledCipherSuites() を参照してください。その他のすべての SSL/TLS 符号化方式同様、符号化方式がピアの側でサポートされていない場合は、暗号のネゴシエーション時に選択されません。また、アプリケーションまたはサーバーが必要な Kerberos 資格を取得できない場合は、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_MD5TLS_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 構成ファイルがあります。
JAAS プログラミングを行わずに Java GSS および Kerberos を使用する方法の例は、「Java GSS チュートリアル」で説明されています。Java GSS 呼び出しを JSSE 呼び出しに置き換えることにより、JSSE の使用例に適応できます。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 プログラムによって 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.SSLSession、javax.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.SSLSession、javax.net.ssl.HttpsURLConnection、および javax.net.HandshakeCompletedEvent で使用して、ピアに関する情報を取得しました。ピアに証明書がない場合、SSLPeerUnverifiedException がスローされます。これらのメソッドの動作は、Java SE 6 でも変わっていません。つまり、接続が Kerberos 暗号化方式を使用して保護された場合、これらのメソッドは SSLPeerUnverifiedException をスローします。
アプリケーションがピアのアイデンティティーまたはピアに送信されたアイデンティティーのみを判別する必要がある場合は、それぞれ getPeerPrincipal() および getLocalPrincipal() メソッドを使用する必要があります。getPeerCertificates() および getLocalCertificates() は、それらの証明書の内容を調べる必要がある場合にのみ使用します。また、認証されたピアに証明書がない場合の処理の準備が必要です。
セキュリティーマネージャー
セキュリティーマネージャーが有効な場合、ピアとの通信に必要な SocketPermission 以外に、Kerberos 暗号化方式を使用する TLS クライアントアプリケーションには次のアクセス権も必要です。serverPrincipal は、TLS クライアントが通信する TLS サーバーの Kerberos 主体名です。host/mach1.imc.org@IMC.ORG などです。TLS サーバーアプリケーションには、次のアクセス権が必要です。javax.security.auth.kerberos.ServicePermission(serverPrincipal, "initiate");serverPrincipal は、TLS サーバーの Kerberos 主体名です。host/mach1.imc.org@IMC.ORG などです。サーバーまたはクライアントが KDC にコンタクトする必要がある場合 (その資格がローカルにキャッシュされていない場合など)、次のアクセス権も必要です。javax.security.auth.kerberos.ServicePermission(serverPrincipal, "accept");tgtPrincipal は KDC の主体名です。krbtgt/IMC.ORG@IMC.ORG などです。javax.security.auth.kerberos.ServicePermission(tgtPrincipal, "initiate");
PKCS#12 (Personal Information Exchange Syntax Standard) では、移植可能な保存形式、およびユーザーの非公開鍵、証明書、その他の秘密およびほかの項目の転送について規定されています。SunJSSE
プロバイダは、pkcs12 ファイルの読み書きのための PKCS12java.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 rsaJSSE の最初のアクセスが遅い
問題: 最初のアクセスで 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 YourClassSystem.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/PKCS1PaddingCaused 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 MyAppMyApp は、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 packetsjavax.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 サンプルコードの実行
- JSSE で使用するキーストアの作成
安全でないソケットから安全なソケットへの変換
この節では、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
の実行」に示されています。URLReader
、SSLSocketClient
、またはSSLSocketClientWithTunneling
をClassFileServer
で実行する場合も、同様の変更ができます。クライアントとサーバーとの間でメッセージを送信しようとすると認証エラーが発生する場合、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.java と ClassServer.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
を使って、認証済みの通信を設定できます。この通信では、クライアントとサーバーが相互に認証します。両方のサンプルプログラムを同じネットワークに接続された別個のマシン上で実行することも、同じマシン上の別のターミナルウィンドウまたはコマンドプロンプトウィンドウから実行することもできます。クライアントとサーバーを設定するには、次の操作を実行します。注: 他の SSLCient* アプリケーションの "GET" コマンドを変更すると、
ClassFileServer
プログラムを、1 台のマシンやターミナルウィンドウから実行します。「ClassFileServer
の実行」を参照してください。SSLSocketClientWithClientAuth
プログラムを別のマシンやターミナルウィンドウで実行します。SSLSocketClientWithClientAuth
には、次のパラメータが必要です。
host
-ClassFileServer
を実行するマシンのホスト名です。port
-ClassFileServer
に指定したのと同じポートです。requestedfilepath
- サーバーから検索するファイルのパスです。このパラメータには、/filepath
を使用します。GET 文の一部として使用されるので、ファイルパスにはフォワードスラッシュが必要です。GET 文には、稼動中のオペレーティングシステムの種類にかかわらず、フォワードスラッシュが必要です。文の構成は次のようになります。"GET " + requestedfilepath + " HTTP/1.0"ClassFileServer
が動作しているローカルマシンに接続できます。HTTPS 接続を表すサンプルコード
JSSE を介して安全な通信にアクセスするための主要な API は 2 つあります。1 つは任意の安全な通信に使用できるソケットレベルの APIで、
SSLSocketClient
、SSLSocketClientWithTunneling
、および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.java
とURLReaderWithOptions.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 に関するドキュメントを参照してください。ユーザー入力は太字で示します。
- 対応する公開/非公開鍵とともに、新しいキーストアと自己署名付き証明書を作成します。
これが、サーバーの使用するキーストアです。% 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>
- キーストアを調べます。エントリタイプが
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
- 自己署名付き証明書をエクスポートし、内容を調べます。
この例では説明しませんが、% 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) に送付して署名を求めることもできます。
- 証明書を新しいトラストストアにインポートします。
% 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- トラストストアを調べます。エントリタイプが
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:74X509KeyManager
および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
注: この例では、サーバーの認証のみを行なっています。クライアントの認証が必要な場合は、クライアントの鍵に対して同様のキーストアを用意し、サーバーに対して適切なトラストストアを提供する必要があります。
JDK Security API は、さまざまなアルゴリズム、証明書、およびキーストアのタイプの標準名を必要とし、これらを使用します。以前にこの付録 A およびほかの仕様 (JCA/CertPath/その他) にあった仕様名は、標準名のドキュメントにまとめられました。特定のプロバイダの情報は、「Sun Provider Documentation」にあります。
Java SE 6 の JSSE はプラグイン可能であり、サードパーティーの JSSE プロバイダの使用には何の制限もありません。
Copyright © 1998-2006, Sun Microsystems, Inc. 4150 Network Circle Santa Clara, California 95054 All Rights Reserved. コメントの送付先: java-security@sun.com。これは購読リストではありません。 |