自堕落な技術者の日記

JavaでSSL/TLS通信をしたい時に通常はJSSE(Java Secure Socket Extension)という仕組み使うんですが、これ使えば、実装色々切り替えたり、追加したりなんてことができます。Apache Tomcat(+Sun Java JSSE)だとCamellia系のCipherSuitesに対応してないそうで、何か対応してるもの、追加で対応できそうなものを調べてみました。

Sun Javaで使えるJSSEってあんまり選択肢がないのね

下の例のようにJSSEプロバイダ名を指定することによりJSSEを切り替えればいろんなSSLエンジンを試せるわけですが、

SSLContext ctx = SSLContext.getInstance(アルゴリズム名, プロバイダ名);
SSLContext ctx = SSLContext.getInstance("SSL", "SunJSSE");
SSLContext ctx = SSLContext.getInstance("TLS", "HarmonyJSSE");

Sun Javaで使えそうなJSSEの選択肢って少ないんだなぁってことが調査してみるとわかりました。Sun Javaで使えそうなのは標準品を含めて以下の3つぐらいしかなさそう。

• Sun(Oracle) - SunJSSE
• RSA - RSA BSAFE SSL-J Toolkit
• IAIK - IAIK iSaSiLk Toolkit

暗号アルゴリズム系のためのJCE対応のライブラリは潤沢にある中、JSSEの方は選択肢がすくないですね。

なんか調べてみるとJSSEはJava VMに依存している方が多いんじゃないかって 感じがします。

• IBM Java - IBM JSSE
• GNU classpath - JESSIE (オープンソース)
• Apache Harmony - HarmonyJSSE (BouncyCastle JCEベース)

新しいCipher Suitesを追加したいと思ったら、Sun Java用にJSSEを書き起こすっていう 手もありですが、コード署名しないと何かと面倒なのでおススメではありません。 JESSIEでやろうとするとGNU classpathなんでちょっとなぁ、、、と。JESSIE自体、 あんまりメンテナンスしてないみたいだし。 で、最終的にApache Harmonyを調べてみるのがいいのかな、、と思ったわけです。 Apache HarmonyはオープンソースでフリーなJavaの実装だそうです。

Apache HarmonyとTomcatを試してみる

Apahce HarmonyのSSL/TLSの機能というか、JSSEの機能は暗号ライブラリとしてBouncyCastle JCE Libraryを使用しており、SunJCEは使えません。 従ってHTTPSのためのSSLサーバー証明書と鍵はJKS形式はSun独自の形式なので使えなくてBouncyCastle JCEがサポートしている PKCS#12かBKS(BouncyCastle Key Store)形式を使う必要があります。 ただ、OpenSSLで生成したPKCS#12でやってみたところMacエラーだったりで読み込めず BKSを使うのがよいのかもしれません。 JKSからBKSへの変換ツールは「ここ」に置いてみたので使ってみてください。

conf/server.xmlファイルにはこんな感じでkeystoreFile、keystorePass 、keystoreTypeを設定します。

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
 maxThreads="150" scheme="https" secure="true"
 clientAuth="false" sslProtocol="TLS"
 keystoreFile="conf/zzz.bks"
 keystorePass="changeit"
 keystoreType="BKS" />

あとはbin/catalina.batに以下のようなパス設定をしとけばApache Tomcat + Apache Harmonyは動くと思います。

set CATALINA_HOME=C:\Java\apache-tomcat-6.0.30-wharmony
set JAVA_HOME=C:\harmony-6.0-jdk-991881
set JRE_HOME=C:\harmony-6.0-jdk-991881\jre

ウェブブラウザ等でHTTPSでつなぐことはできたでしょうか？

で、OpenSSLで繋いでみる

openssl s_client機能を使ってApache Tomcat + Harmonyのサーバーに接続してみましょう。

% openssl s_client -host zzz.com -port 8443
CONNECTED(00000003)
depth=1 /C=JP/O=HOGE
verify error:num=19:self signed certificate in certificate chain
verify return:0
14052:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:209:
14052:error:1408D07B:SSL routines:SSL3_GET_KEY_EXCHANGE:bad signature:s3_clnt.c:1447:

とJava実装やブラウザだと出てこないエラーが出てきてしまいました。ググってみるに-cipherを設定しないことが 原因のようで-cipher 'ALL:!kEDH'を指定してちょっと絞り込みをしないといけないそうです。

% openssl s_client -host zzz.com -port 8443 -cipher 'ALL:!kEDH'
CONNECTED(00000003)
中略
depth=1 /C=JP/O=HOGE
verify error:num=19:self signed certificate in certificate chain
verify return:0
read R BLOCK
DONE

これでApache Tomcat + HarmonyにOpenSSL s_clientで繋ぐことができるようになりました。

Apache HarmonyのJSSEのコード

Apache HarmonyのJSSEはjre/lib/boot/x-net{.jar,-src.jar}にある org.apache.harmony.xnet.provider.jsse パッケージがそれに当たります。 x-net.jar自体はコード署名されてないようなので、 CipherSuiteを追加し放題で x-net.jarに入れ替えても動きそうな雰囲気です。

JSSEプロバイダの定義はJSSEProvider.javaにあります。 コメントのところに割と詳しい説明があって以下のようなものが書かれています。

• サポートしているCipherSuites：別表
• 使用する共通鍵暗号アルゴリズム：IDEA,RC2,RC4,DES,3DES
• 使用するMacアルゴリズム:MD5, SHA-1
• 使用する鍵交換アルゴリズム: RSA, DH, DHE

Apache Harmony 6.0 build 991881のHarmonyJSSEプロバイダーで提供されているアルゴリズムとその値の一覧は以下の通りのようです。

SSLContext = TLS(=TLSv1)
KeyManagementFactory = X509
TrustManagementFactory = X509

HarmonyJSSEがサポートしているCipherSuiteの一覧は以下の通りです。

TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_WITH_IDEA_CBC_SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_WITH_DES_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_RSA_WITH_DES_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

そして、そのうちデフォルトの設定で提供するCipherSuiteは以下の通りです。

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

今晩はこんなところで、、、
ではでは

フリーのJavaの暗号ライブラリRSA BSAFE Shareがバージョンアップされたそうです。

変更点は以下のようです。

- EC DRBGアルゴリズムの乱数生成器
- 乱数生成器の場合にHSMが使える
- JCE APIを使ったCSRの生成 (PKCS#10, Certificate Request Message Format)
- JCE APIを使ったCertificate Management Protocolの利用
- 外部セッションキャッシュにおけるセッション情報保持のサポート
- RFC 5430に準拠したSuite-Bのサポート

うぅ〜〜む、PKCS#10ぐらいですかね？

あまり、注目するところは他には無いかと、、、、

忘れた頃にやってくるBSAFE Shareの連載ですが、前回に引き続き証明書のパス検証関連で、今回は「BSAFE Shareの事前生成されたOCSPを使ったパス検証機能」を試してみたいと思います。

Java JCEのパス検証に対応したプロバイダ

Java JCE の証明書のパス構築(CertPathBuilder)、パス検証(CertPathValidator)をサポートしている一般に入手やすそうなJCEプロバイダとして

・SUN (Sun Java J2SE 1.4以降に含まれる)
・RSA BSAFE Share
・BouncyCastle
・IBM Java

の3つがあります。(IAIKやEntrust Toolkitはパス構築・検証についてJCEとは別のAPIを提供しています。)

RSA BSAFE Shareには、フツーのPKIXパス検証のオプションとして、OCSPを使った検証にも対応しているんですが、他のプロバイダには無い機能として

事前に取得していたOCSPレスポンスのデータを使ってパス検証ができる

っていうのがあります。Windows Vista以降はやっていますがOCSPレスポンスをキャッシュしておき再利用して検証するなんていう芸当がJavaでもできるっていうわけです。

これは、特にCAdESやXAdES長期署名をやっている人は食付いてきますよね（−−；CAdESやXAdESでは署名者証明書の検証情報(ルートまでの証明書のチェーン、CRL、OCSPレスポンス)を一緒にいれておいて将来検証に使ったりするのでデータとして渡されたOCSPレスポンスを使ってパス検証する必要があるわけです。ところが、SUNのプロバイダはオンライン取得しかサポートしていないのでこれができなかったわけです。

OCSPに対応したCAdESやXAdESの実装をやってらっしゃる方は、OCSPレスポンスのデータを使ってパス検証する仕組みを(どれくらい真面目にやっているかは別にして)実装されているんじゃないかと思います。(私もそうです)

OCSP応答ファイルを使った検証サンプル

BSAFE Shareのサンプル(sample/src/jce/certpath/ValidatePathUsingOCSPResponse.java)というのがあります。サンプルでは

・サブCA証明書(CAphoenix.crt)
・EE証明書(janet.crt)
・EE証明書検証用のOCSPレスポンス(ocspResponse.rsp)

が使われています。例によって(Javaで書くよりも余計な飾りが無い分全体の動きが見やすいと思うので)Jythonでサックリ書いてみると、、、、

# (0) BSAFE Share JCEプロバイダ設定して...

Security.insertProviderAt(JsafeJCE(), 1)

# (1) ファイル読んで...

cf = CertificateFactory.getInstance("X.509", "JsafeJCE")

caCert = cf.generateCertificate(FileInputStream("CAphoenix.crt"))

eeCert = cf.generateCertificate(FileInputStream("janet.crt"))

ocspBytes = 何らかの方法でOCSP応答"ocspResponse.rsp"をbyte配列で読んで

# (2) CertPath作って...

chain = ArrayList()

chain.add(eeCert)

certPath = cf.generateCertPath(chain)

# (3) CertPathParameter作って...

#  (3.1) トラストアンカ作って...

ta = TrustAnchor(caCert, None)

trustAnchors = HashSet()

trustAnchors.add(ta)

pkixParams = PKIXParameters(trustAnchors)

#  (3.2) OCSPパラメータ作って..

ocspParams = OCSPWithResponseParameters(ocspBytes, caCert)

#  (3.3) CertPathパラメータ作って...

certPathParams = CertPathWithOCSPParameters(pkixParams, ocspParams)

# (4) 検証っと、、、、

certPathValidator = CertPathValidator.getInstance("PKIX", "JsafeJCE")

print  certPathValidator.validate(certPath, certPathParams)

こんな流れになります。

(1) 証明書やOCSPを読み込んで
(2) CertPathオブジェクトを生成
(3) 検証用のPKIXParameterとOCSPパラメータを生成
(4) 検証

検証に使うOCSPレスポンス

OCSPのデータを使って検証する場合に、OCSPResponseを使うのか、BasicOCSPResponseなのかというのは気になるところです。詳しくはRFC 2560を見てもらうとしてざっくりこんな違いがあります。

・OCSPResponse
　・BSAFE OCSPWithResponseParameters ではこれを用いる
　・OCSPで返されるメッセージの全体
　・中に成功したかどうかという状態情報(responseStatus)を含む
　・通常は中にBasicOCSPResponseを含む
　・XAdESではOCSP検証情報としてこれを用いる
　・OpenSSLでもファイルとして検証できる
・BasicOCSPResponse
　・単数または複数の証明書の有効状態
　・OCSPResponseに含まれる
　・CAdESではOCSP検証情報としてこれを用いる
　・OpenSSLではファイルとして検証できない

このように、書いてしまった通り、BSAFE Share で検証させる場合にはOCSPResponseを使わなければなりません。CAdESの検証に使う場合にはBasicOCSPResponseからresponseStatus: successful をくっつけてラップしてOCSPResponseを作ってやらないといけません。

OCSPResponseかBasicOCSPResponseかを見分けるには dumpasn1 で表示させたときに先頭の辺にENUMERATED 0とあればOCSPResponse

SEQUENCE { ← OCSPResponseの始まり

  ENUMERATED 0 ← responseStatus: successful

  [0] {

    SEQUENCE {

      OBJECT IDENTIFIER ocspBasic (1 3 6 1 5 5 7 48 1 1)

      OCTET STRING, encapsulates {

        SEQUENCE { ← BasicOCSPResponseの始まり

          SEQUENCE {

            [1] { ← ResponderID.ByName

              SEQUENCE {

                SET {

                  SEQUENCE {

                    OBJECT IDENTIFIER countryName (2 5 4 6)

                    PrintableString 'FR'

　　：以下略

無ければ BasicOCSPResponse

SEQUENCE { ← BasicOCSPResponseの始まり

  SEQUENCE {

    [1] { ← ResponderID.ByName

      SEQUENCE {

        SET {

          SEQUENCE {

            OBJECT IDENTIFIER countryName (2 5 4 6)

            PrintableString 'FR'

            }

　　：以下略

ということになります。

ちょっと残念なところ

最初サンプルコードを見たときちょっと怪しいなぁ、、と思ったんですが、サンプルでは検証対象が

・SubCAがトラストアンカ
・SubCA→EEの一段のみ
・OCSPレスポンダ証明書はSubCA証明書と同じ

となっているんです。サンプルを見てみると

ocspParams = OCSPWithResponseParameters(ocspBytes, caCert)

つまり、パス中に入れられるOCSPレスポンスは高々一つだけって事です。Root→SubCA1→SubCA2→EEみたいな多段の証明書チェーンの場合にSubCA1、SubCA2の検証にはOCSPは使えないってことを意味しますし、OCSPレスポンダ証明書が事前にわかっているケースでしか使えないってことがわかります。

どうやら、証明書とOCSPレスポンスをごそっと投げて「検証お願いっっ！（はぁと）」というわけにはいかないようです。

途中までCRLでいいや、、、って場合にはPKIXParametersにCollectionStoreを追加してCRLをぶちこんでやれば検証できると思います。

まとめると

・OCSPレスポンダ証明書のパス検証はしない
・事前にOCSPレスポンダ証明書がわかっていなければいけない
・多段のOCSPは使えない

っていうことなんで前処理をしっかりやらないと汎用的なパス検証に使うのは面倒くさい感じですよね。

今、自前でもっているパス検証のやつは

・OCSPレスポンダ証明書を事前に知っておく必要はない
・OCSPレスポンダ証明書のトラストアンカからのパス検証を行う
・コレクションストアに入れていれば適切なOCSPレスポンスを選ぶ
・中間CAのOCSPレスポンスデータによる検証にも対応する
・OCSPのモデル(直接、委譲等)は問わない

というようになっているので、う〜〜〜む、最初はよさげと思ったんですが、結局当面は自前のを使うことになりそう、、、

NIST PKITSと似たやつでOCSPを含むパス検証でまともなテストケースが欲しいなぁ、、、、、時間を見つけて作るかなぁ、、、、

前回からいい感じに回数が開きましたが、またRSA BSAFE Shareの話を、、、、

PKIX CertPathBuilderはかなり良い感じ

前回はNIST PKITSを使ってRSA BSAFE ShareのPKIX CertPathValidator(パス検証)を試してみましたが、今回はPKIX CertPathBuilder(パス構築)の方をためしてみました。

RSA BSAFE ShareのPKIX CertPathValidatorはSUNと比べてエラーの理由がわからんとダメ出しをしてしまい、同様にSUNのPKIX CertPathBuilderにも失敗の原因がさっぱりわからん！！！とダメ出しをしているですが今度はどうかな、、、、、

結果的に言うとBSAFEのPKIX CertPathBuilderは失敗の理由がバッチリわかるのでSUNなんかより良いです。

テストに使うパスは昔つかったスイカ型メッシュモデル風のパスです。



RSA BSAFEのCertPathBuilder、CertPathValidatorの困ったところは"-Djava.security.debug=cerpath"フラグを使ってもデバッグメッセージを全く吐かないところです。中の動きが見えにくいし、、、、、

一応デバッグフラグをつけておくと、SunのX509CertSelectorのログだけは出力されます。でデバッグ出力からパスの繋ぎ方を見る方法ですが、

certpath: X509CertSelector.match(SN: 証明書シリアル
Issuer: 発行者DN
Subject: 主体者DN)
certpath: X509CertSelector.match returning: true

の行があれば、この証明書がパス構築に使われたことを示します。それをログの上から順に見ていきます。

で、そのスイカ型モデルでパス検証をしてログを見てると、こんな感じの順序で証明書を使っているのがわかります。





つまり、RSA BSAFE Share for JavaのPKIX CertPathBuilder実装は：
・SUNと同じエンドエンティティからルートに向けた構築
・SUNと同じ深さ優先探索
であることがわかります。

図のGGGから辿るパスは3通りあるわけですが、SUNの場合には2本辿ってダメで次に成功だったわけですが、RSAの場合には1回失敗した後で成功のパスを辿っています。

CollectionStoreの格納元にはArrayListを使っていたんですが、その格納順序で3本中のどれを選ぶかが変わるのかなと思って試してみましたが、どうもそうではないようです。

で、私の気になっているパス構築失敗時のエラーメッセージですが、ちゃんとエラーメッセージ出力するんですよ。当たり前だけど、それがSUNではできてないので、エライじゃないですか（＾＾ｖ先ほどのスイカモデルで途中の証明書をなくしておいて失敗するように設定してみると、、、、

■有効なパス中のROOT→CCCの証明書を削った場合：
　java.security.cert.CertPathBuilderException:
　　Sat May 02 10:26:08 JST 2009 is before Sun Jan 02 09:00:00 JST 2000
　　ちゃんと有効期限のエラーが表示されます。
■上からさらにROOT→AAAの証明書を削った場合：
　java.security.cert.CertPathBuilderException:
　　Expected a CA certificate.
　　基本制約cAフラグのエラーっぽい感じがしますよね。

■SUNの場合ならいずれも全く無意味な以下の例外（−−；
　sun.security.provider.certpath.SunCertPathBuilderException:
　　unable to find valid certification path to requested target
　　こりゃなんの事かさっぱりわからん

Java実装のSSLのクライアントで「繋がんね〜〜〜」とか悩んでいる場合には、SUNのはやめてRSA BSAFEを使うよう優先して調べるといいんじゃないっすかね。

前回に引き続きRSA BSAFE Share for Javaのお話を、、、、

NIST PKITSをやってみると

BSAFE Shareには"JsafeJCE"という名前のJCE(Java Cryptography Extension)プロバイダがあって、その中で証明書が信頼するルート証明書から辿って有効であることを検証する認証パスの構築や検証の実装が含まれています。

証明書のパス検証については米国標準技術局(NIST)がPKITSというテストケースとデータのセットを公開していてSUNのJCEプロバイダだとどうなんだ？みたいな話は4月13日に書きました。

じゃぁ、JsafeJCEプロバイダのCertPathValidatorのPKIXアルゴリズムの実装はどうなんだろうって、、、、気になりますよねぇ、、、ならないか、、、、

個人的に気になったのでやってみました。で、結果は、、、、、、

：
：
：
（−−；

拍子抜けというか、期待が大きかっただけにがっかりというか、実装に問題があったとかそういうのではなく結果としてSUN JCEの実装と殆どサポート範囲も含めてうり二つなんです。(だから、ブログに書きにくい、、、、結果が違ってたのはDeltaCRLのテスト1つだけ)

NIST PKITSのテスト結果からSUNとJsafeJCEのJCEプロバイダには以下のような共通の特徴があります。
・あるCAが証明書とCRLの発行を別の鍵(と証明書)で行う事の非サポート
・NewWithOldのテストの不具合(詳細は見てない)
・IndirectCRLの非サポート
・DeltaCRLの非サポート
間違ったテストも全く同じなので同じ開発元が作ってるのかな？とさえ思えてしまいます。

SUNよりもJsafeJCEの方が例外のメッセージも不親切気味なので、エラーが起きたときの原因の究明には手間取るかもしれません。以下が同じテストケースにおける例外メッセージの例です。

SUN: signature check failed: Signature does not match.
JsafeJCE: Certificate verify failed!
SUN: timestamp check failed: NotBefore: Jan 01 2047
JsafeJCE: Apr 29 2009 is after Jan 01 2047 (これは互角)
SUN: CA key usage check failed: keyCertSign bit is not set
JsafeJCE: Certificate verify failed!

どうです？「Certificate verify failed!」の一言で片付けられちゃうケースが多くて微妙な感じですよね（＾＾；CertPathValidatorに関しては、積極的にこれを利用する理由がいまひとつ見えてきませんでした。

楕円暗号の鍵生成ができない？！

RSA BSAFE Share for Javaでは楕円暗号の署名や証明書の検証、鍵交換(ECDSAやECDH)なんかができるんですが、JCEのサポートアルゴリズムのリストを見た限りでは楕円の鍵生成機能を提供していないようです。

楕円の証明書発行要求もできないのでは？！と思うんですが、どうでしょう、、、、


今日は、休日なんでこの辺で、、、、（−−；

＜お詫びと訂正 2009.04.29 17:48＞
私がアルゴリズム名を集計した表に誤りがありJsafeJCEでもちゃんと楕円の鍵生成はできます。混乱させてしまい申し訳ありませんでした。

今日は、その他雑多なわかった事、前に書き忘れていた事をつらつらと書いてみたいと思います。

サンプルのビルド

そういえば、サンプルプログラムのビルドについて説明してませんでしたね。

結構豊富なサンプルが用意されています。

サンプルのビルドはEclipseで行います。サンプルが使用するデータファイルのパスが絶対パスで"/data/..." だったりするようなので、Unix系でないとサンプルが動かないかもしれないです。(面倒なので試してない、、、)

Eclipseのメニューから「ファイル＞インポート」を選びウィザードで「一般＞既存プロジェクトをワークスペースへ」でできたと思います。

サンプルのビルドは同じくメニューから「プロジェクト＞プロジェクトのビルド」でビルドできたと思います。

なんでAntじゃないんだろう、、、プンプン、、、、

FIPS 140-2 Level1認定は無い

RSA BSAFE ShareはFIPS 140-2 Level1認定は無いそうで、これが必要ならば商用ライセンスが必要なんだそうです。RSA BSAFE ShareでもFIPSモードみたいなのはあるみたいなんですが、これを設定するとエラーになったりするんでしょうか。

時間がある時、調べてみたいと思います。

そもそもDevelopper's Guideは読め

さすが基本的にちゃんとした商用ライブラリなんでIAIKやBouncyCastleなんかと違ってドキュメントは充実してました。まずはDevelopper's Guide("doc/dev_guide/index.html")を読むべきでしたね。

SSLのCipherSuiteやサポートする暗号アルゴリズム、鍵長なんかもちゃんと記載されています。(JCEのアルゴリズム名はありませんが、、、)

TLSv1.2用のSuite-B AES-GCMを使ったCipherSuiteもちゃんとサポートされていました。(疑ってゴメンよ)

ちなみに、このガイドはdoxygenを使って書かれてるみたいです。

パス検証でEV証明書のチェッカーも付属

HTTPSで接続したときブラウザのアドレスバーが緑色になるEV(Extended Validation)証明書であるかどうかチェックするためのAPIもついていました。EV Guidelineで規定された証明書プロファイルに準拠しているか(アルゴリズム、鍵長も含めて)チェックしているみたいです。

ASN.1、CMS、PKCS#7なんかは無い

RSA BSAFE Share for Javaは

・暗号プリミティブ(暗号,署名,ハッシュ,メッセージ認証,乱数)
・SSL/TLS通信
・証明書検証

のためのライブラリであって

・CMS署名/暗号フォーマット
・PKCS#7署名/暗号フォーマット
・XML署名/暗号
・ASN.1
・証明書拡張の情報の取得

は守備範囲外みたいです。

CMS、PKCS#7はわかりますが、証明書ポリシのpolicyQualifierとか証明書の拡張を取り出して中身を見るには別のライブラリを使う必要があります。

JavaのJurisdiction Policyのチェック

ちょっとオモシロイと思ったので、これも紹介、、、、

Sun Javaは暗号ライブラリを含みワッセナー条約の輸出規制にかかるため、配布時点では管轄ポリシー(jurisdiction policy)ファイルで制限されています。

規制の対象外の殆どの国では、このポリシーファイル(jre/lib/security/{local,US_export}_policy.jar)を無制限強度(unlimited strength)のものに置き換えることで、鍵の長い強固な暗号を使えたりします。

BSAFEではこのポリシーのチェックのためのクラスがあって

# Jythonでスンマソン
from com.rsa.jsafe.crypto import *
print PolicyChecker.JurisdictionPolicyLevel.getJurisdictionPolicyLevel()

を実行してみると "UNLIMITED" と表示されたりします。

ちゃんとこれをプログラムでチェックできるのは本当にいいですよね。Java関係のいろんな製品のサポートとかでもJurisdiction Policyファイルを入れ替えてなかったせいでエラーや動かなかった報告はよく聞きますから、、、、

なんか、脈絡なくてごめんなさいね。今日は、この辺で、、、、、、

前回はRSA BSAFE Share for Javaを使えるように、プロバイダの設定や簡単なサンプルなんかを紹介しました。

前回、手持ちのJCEプロバイダで実装しているアルゴリズムの一覧表を作っていて、RSA BSAFE Shareについても加えてみたっていう話をしましたが、他のJCEプロバイダと比較してみて、各インタフェースクラスのRSA BSAFE Share for Java JCEプロバイダ実装の特徴をまとめるとこんな感じ、、、、

・署名/Signature: 代表的なものはカバー、SHA2、楕円もサポート
・暗号/Cipher: 代表的なものはカバー、珍しいとこではECIESwith*
・ハッシュ/MessageDigest: SHA2を含め代表的なものはカバー。RIPEMDは160のみ。
・安全な乱数生成器/SecureRandom: 他プロバイダと比較できない程種類が多い
・パス構築/CertPathBuilder: 他プロバイダには無いPKIX-SuiteB*, X.509V1をサポート
・パス検証/CertPathValidator: 他プロバイダには無いPKIX-SuiteB*, X.509V1をサポート
・メッセージ認証/Mac: HmacMD*, HmacSHA* などメジャーどこは全てカバー
・SSL通信内容/SSLContent: SSL*, TLSv1 など主要はサポート。TLSv1.2がある。
・SSL用トラストアンカ管理/TrustManagerFactory: PKIX-SuiteB*ある。

というわけで、暗号アルゴリズムはメジャーどこは全て押さえてあり、そつがない印象で幅広いケースで安心して使えるJCEライブラリになっています。

SecureRandomは種類が多いのはイイですが、優れたものが一つあれば十分で、交換したり、生成、検証したりしないので相互運用性が問題になることも無く、多かろうが少なかろうが、まぁ、あまり問題ではないかなと、、、、

やはり注目すべきなのは、他のJCEプロバイダにはない、パス構築・検証でのSuite-Bのサポートだと思います。

Suite-Bとは？

最近ちょっと話題になりつつある「Suite-B」とは、米国国家安全保障局(NSA)で定められた官民双方で利用できる一般的な機密保護のための仕様の公開された暗号アルゴリズムのセットです。さらに重要性の高い用途のためにNSAで開発された仕様非公開のアルゴリズムによる「Suite-A」というセットもあります。

・Suite-A
　・よりセンシティブな機密情報を扱うための暗号アルゴリズムのセット
　・NSAにより開発され仕様の公開されていない暗号アルゴリズムで構成される
　・ブロック暗号(Juniper)、非対称鍵暗号(MayFly)など
・Suite-B
　・一般的な機密情報を扱うための暗号アルゴリズムのセット
　・仕様の公開されている現在強度の高いとされる暗号アルゴリズムにより構成される

Suite-B は以下のパラメータの暗号アルゴリズムにより構成されています。

・共通鍵暗号: 鍵長128bitか256bitのAES-GCM暗号
・電子署名: ECDSA (楕円)
・鍵共有: ECDH (楕円Diffie-Hellman)
・ハッシュ関数: SHA-256とSHA-384

インターネットの標準であるRFCでは最近、IPsecでSuiteBを使うためにRFC 4969が出ていたり、S/MIME暗号メールでSuiteBを使うためのRFCが出ていたりします。

Windowsでは、Vista以降のCryptoAPIの後継であるCNGでSuiteBをサポートしていたり、Outlook2007でSuiteBしか使わないグループポリシにしたり、IPsecでSuiteBを使うようにしたり、認証局の証明書テンプレートでSuiteBを使うようにしたりできるようです。

BSAFE Shareのパス検証のSuiteB対応

指定された時刻に証明書のチェーンが正しく繋がっていて、失効しておらず、有効期限内であるかを確認するためにパス構築・検証を行います。

パス構築・検証でSuiteBの暗号しか使わないってことは、署名はSHA2と楕円暗号を使ったSHA256withECDSA or SHA384withECDSA署名アルゴリズムしか使えないってことになります。

鍵共有や共通鍵暗号についてはパス検証においては関係ありません。

ハッシュ関数については署名以外で直接的に使うところはあまり無いのですが、以下はSuiteBじゃなくてもいいんでしょうか、、、
・KeyIdentifierを生成する際、SHA-1のみしか使えないのは仕様なので仕方ない
・OCSPの識別名のハッシュを使う際SHA-1のみしか使えないのも仕方ない
・パス構築でCRLやOCSPを取得する際にHTTPS、LDAPSであった場合
　　TLSがSuiteBの暗号のみであることを必要とするのか？！
、、、んん〜〜っ、どうなんでしょうね、教えてエライ人（＾＾；


BSAFE Share for Javaではパス構築(CertPathBuilder)とパス検証(CertPathValidator)のために複数のアルゴリズムを提供しており、これは他のJCEプロバイダには無いところです。JCEアルゴリズム名の一覧は以下の通り。

・PKIX: RFC 3280に基づく証明書のパス構築・検証
・PKIX-SuiteB: 上記でSuiteBの暗号のみを使用
・PKIX-SuiteBTLS: TLS暗号化通信のパス構築・検証でSuiteBを使用
・X.509V1: X.509V1で規定されたパス構築・検証(証明書拡張が無い)

SuiteBかどうかは、パス検証後に署名アルゴリズムだけちゃちゃっとチェックすれば同じことのような気もしますが、JCEのアルゴリズムとして明示的に指定でき自動でやってくれちゃうっぽい、っていうのはスゴイところです。

SuiteBのTLSは？

暗号通信 TLS で SuiteB を使う時に、ハッシュやMacはまぁいいとして、共通鍵暗号として AES-GCM(Galois/Counter Mode)っていうのを使わなきゃいけないと思うんですが、BSAFEとか他のJCEプロバイダも含めてAES-GCMの対応ってどうなんでしょうか、、、単にAESのアルゴリズムパラメータで指定できるのかな、、、、

ここら辺は今後調査してみます。

BSAFE Share for Javaで足りないところ

BSAFE Share for Javaのサポートアルゴリズムの一覧をざっと見て思ったのは、RC2何とかやDES、TripleDESなんとかなど主要なものは一部ありますが、その派生のアルゴリズムでサポートしてないものが結構多いな、、、と感じました。後方互換性をバッサリ切っちゃうみたいなところはあるかと思います。

例えばこんなケースでサポートできなくて困らないかな、、、と心配します。

・PKCS#12形式の暗号化された秘密鍵
　　古い暗号アルゴリズムが使われており、鍵が取り出せないなんてことが
　　あるかもしれない。
・S/MIME暗号メールのメッセージ
　　古い暗号アルゴリズムが使われていて、メッセージを復号して見られない
　　なんてことがあるかも、、、

古いアルゴリズムのサポートに関してはIBMのJavaであるIBM J9に付いてくるJCEがかなり優秀だと思っていて古いものの扱いに困った時には、コレを使うといいと思います。S/MIMEは仕方ないですが、PKCS#12の方は、古いアルゴリズムが使われていたら新しい汎用的なアルゴリズムを使うように移行(マイグレーション)を考えておいた方がいいかもしれませんね。

というわけで、今回はBSAFE Share for JavaのSuiteB暗号スイート関連の話題を中心にサポートされている暗号アルゴリズムの紹介をしてみました。

ううむ、、、今回もマニアックな感じでしたね。すみません。

週末、RSA BSAFE Share for Javaをダウンロードしてみたので、いろいろ試してみました。

どんなアルゴリズムを実装しているか

JCEプロバイダの実装をゲットしたら、そのプロバイダがどんなアルゴリズムを実装しているのかを調べたくなるのが人情ってもの、、、、

製品紹介ページにアルゴリズムの一覧が書いてあったとしても、実際どうなの、、、とか、アルゴリズムの参照名がどうなっているの、、とかは気になりますし、それを知っとかないと後でアルゴリズム名が間違っているために障害起きたりして痛い目にあうので、日ごろからJCEプロバイダとアルゴリズム名の表はまめ手を入れて管理するようにしています。

現状手元にあるのが、
・IAIK JCE
・BouncyCastle
・Entrust Toolkit
・IBM J9 J2SE 1.6.0
そして新しく加わった
・RSA BSAFE Share

プロバイダ設定して、アルゴリズム一覧を出力するプログラムを使ってリストを出し、Excelで地味に表を更新します。

表を公開できればなぁ、、、とも思うんですが、26列×436行というHTMLでテーブル書くにはデカすぎるので、ちょっと出し方を考えておきます。

JCEプロバイダ毎にクセやら傾向があったりするんで、その辺りもいつかまとめて紹介したいと思います。

まず最初、プロバイダの設定

まず、2つのjarファイル、"lib/shareCrypto.jar"と"lib/shareTLS.jar"をJavaのクラスパスに入れてからRSA BSAFE ShareのJCEプロバイダを使えるようにするために方法が2つあります。

・設定ファイルに登録する方法
・動的に読み込む方法

利用できるJCEプロバイダは

$JAVA_HOME/jre/lib/security/java.security

のファイルの

security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
　：以下略

に登録しておけば使えます。番号が小さいほど優先して使われるので、

security.provider.1=com.rsa.jsafe.provider.JsafeJCE
security.provider.2=com.rsa.jsse.JsseProvider
　：以下略

のようにBSAFE Shareのものを先頭にもってきておき、他のは番号ずらしておけばBSAFEが優先して使われるようになります。

プログラムから動的にJCEプロバイダを使えるようにするにはプログラム中以下のような呼び出しをすれば、RSAのプロバイダが優先的に使えるようになります。

import java.security.Security;
import com.rsa.jsafe.provider.JsafeJCE;
import com.rsa.jsse.JsseProvider;

　：中略
try {
Security.insertProviderAt(new JsafeJCE(), 1);
Security.insertProviderAt(new JsseProvider(), 2);
} catch (Exception ex) { ex.printStackTrace(); }
　：中略

ここで注意しとかないといけないのが、JCEプロバイダ名とクラス名が合っていないところです。

・プロバイダ名："JsafeJCE" (こっちはクラス名と一致で安心。暗号関連の実装)
・プロバイダ名："RsaJsse" (こっちは違うので注意。SSLのためのプロバイダ)

例えばプロバイダを明示的に指定してSignatureオブジェクトをゲットしたい場合には、

import java.security.Signature;
Signature sig = Signature.getInstance("SHA1withRSA", "JsafeJCE");

先ほどRSA BSAFEを優先して登録したはずなので

Signature sig = Signature.getInstance("SHA1withRSA");

とプロバイダ指定しなくてもRSA BSAFEが使われます。

それでは、"JsafeJCE"プロバイダの"RIPEMD160"ハッシュアルゴリズムを使って文字列"aaa"に対するハッシュ値を計算してみましょう。

import java.math.*;

import java.security.*;

import com.rsa.jsafe.provider.*;

public class RipeTest1 {

  public static void main(String[] args) {

    try {

      MessageDigest md = MessageDigest.getInstance("RIPEMD160", "JsafeJCE");

      byte[] hash = md.digest("aaa".getBytes());

      System.out.println(new BigInteger(hash).toString(16));

    } catch (Exception ex) { ex.printStackTrace(); }

  }

}

ちなみにRSA BSAFE Share for Javaは JDK 1.4.x では使えないみたいで、

実行しようとすると

Exception in thread "main" java.lang.UnsupportedClassVersionError: RipeTest1 (Unsupported major.minor version 50.0)

コンパイルしようとすると

RipeTest1.java:7: com.rsa.jsafe.provider.JsafeJCE にアクセスできません。クラスファイル shareCrypto.jar(JsafeJCE.class) は不正です。
クラスファイルのバージョン 49.0 は不正です。48.0 であるべきです。
削除するか、クラスパスの正しいサブディレクトリにあるかを確認してください。

のようなエラーが出てしまいます。

今日は、初回なんでこの辺で、、、、

次回はRSA BSAFE Share for Javaの特徴みたいなところを紹介できれば、、、、と思っています。

RSA Makes RSA BSAFE��� EncryptionToolkits Available At No Cost Through RSA��� Share Project to Strengthen Ecosystem for Secure Application Development

Monday, April 20, 2009
RSA Makes RSA BSAFE��� EncryptionToolkits Available At No Cost Through RSA��� Share Project to Strengthen Ecosystem for Secure Application Development

昨日、会食したＭさんのブログを見ていたら、今週、4/20から米国サンフランシスコのモスコーンセンターでRSA Conference 2009をやっていますが、そこでRSA社のプレステやニンテンドーDSなんかにも使われている有名なセキュリティツールキットRSA BSAFEを無償提供することにしたというアナウンスがあったみたいです。製品名がRSA BSAFE Share for C/C++ or Java のようになるみたいです。

情報共有や製品へのフィードバックのためにBSAFE Share プロジェクト RSA Share っていうのがあるみたいです。

同時に、このツールキットを使ったセキュリティアプリケーションのコンテストが開催されるそうです。

早速アカウント登録してみたんですが、んん〜〜っ、どこからダウンロードしていいのかよくわかんないぞ〜〜〜〜。

結局ダウンロードできませんでした。トホホ、、、なんで？？？

しかし、前に行ったRSA Conferenceは楽しかったなぁ、、、、しみじみ、、、、もっかいぐらい行きたいなぁ、、、、チリクラブと飲茶行きたい、、、、

＃OracleのSun買収もビックリしましたが、
＃このニュースも結構ビックリです。
＃買収の話は他人事ではないわけですが（＾＾；

＜追記 2009.04.22＞
日本時間2009年4月22日午前6時20分に「RSA Share Product Download - Issue Resolved」という件名のメールが来て「直ったからまたダウンロードしてちょ」と書いてあったので、早速訪問してみたらファイルをダウンロードできるページそのものまでちゃんと辿りつけました。対応早くてエライなぁ、、、、、

あるデジタル証明書が信頼するルート証明書から辿って有効であるかどうか判定するために認証パス検証(Certification Path Validation)という処理を行います。

これは、HTTPSで保護されたサイトに接続する時やS/MIME署名メールを開く際に実は裏で行われているとっても重要な処理です。

Java ではCertPathBuilderとCertPathValidatorというクラスがあり、仕組み的にはX.509公開鍵証明書に限らず汎用的に証明書のパスが検証できたり、いろいろな会社の実装したアルゴリズム、実装方法が選択できるようになっています。

Sun Java にはRFC 3280準拠のパス検証実装が含まれており、これに基づくX.509証明書のパス検証ができるようになっています。

CertPathBuilderのSunプロバイダのPKIXアルゴリズム

検証対象証明書、中間証明書、CRL、証明書やCRLを取得するLDAPディレクトリ、OCSPレスポンダの設定、トラストアンカとなるルート証明書群を指定することにより、自動的にパス構築と(狭義の)パス検証を同時に行うことにより検証対象証明書のパスが有効であるかを判定します。内部でCertPathValidatorの実装が使われているわけではありません。

CertPathValidatorのSunプロバイダのPKIXアルゴリズム

検証対象証明書からトラストアンカとなるルート証明書の一つ手前までの証明書のチェーン(CertPath)を与えることにより、(狭義の)パス検証を行います。

Sun PKIXのCertPathBuilderのパス構築をザックリ図にしたのが以下、、、





SunプロバイダのCertPathBuilderのPKIXアルゴリズム実装なんですが、これが、またちょっとイケズな実装になっていてエラーメッセージというか例外処理がとても不親切なんです。

パスを構築するための証明書が不足していたり、CRLが取得できなかったり、失効していたり、期限切れだったり、鍵用途が間違っていたり、中間CA証明書にあるべき基本制約のcAフラグがTRUEでなかったりすると例外が発生しますが、どんな理由であっても全く同じ

sun.security.provider.certpath.SunCertPathBuilderException: 

unable to find valid certification path to requested target

という例外メッセージが表示されます。これじゃ何がエラー理由だったのかさっぱりわからない（＾＾；メッセージ "unable to find valid ..." でぐぐってみると皆さんエラー理由がわからず困っておられる様子、、、、

CertPathBuilderExceptionクラスではgetCause()メソッドにより、その例外が発生した元の原因となる例外を取得できるんですが、Sunの実装では深さ優先探索のせいか？！不親切なのか？！これが設定されていないため、パス構築・検証に失敗した原因がわからないんです。

パスの深さ優先探索とは

SunのCertPathBuilderのPKIXアルゴリズムの実装ではパスを見つける際、幅優先探索と深さ優先探索のうち深さ優先探索が使われています。(人工知能系の方、Prolog系の方はよくご存知、、、（＾＾；)

以下のような少し複雑なPKIモデルで考えて見ましょう。





ここでは信頼するルート証明書からエンドエンティティ証明書まで3通りのパスがあるんですが、そのうち2つは無効なパスになっています。

・ROOT→AAAのCA証明書は証明書有効期限が切れているので無効
・ROOT→BBBのCA証明書は基本制約にcA=TRUEが無いため無効

SunのCertPathBuilderでパス構築した場合の、パス構築で辿ってみた順序を図説したのが以下です。





Sun実装ではエンドエンティティ証明書から始めてトラストアンカであるルート証明書まで深さ優先探索でパス構築を試みます。深さ優先とは、ぶっちゃけちゃうと「行ける所まで行く」、

踏み出せばその一足が道となり、その一足が道となる。迷わず行けよ。行けばわかるさ。ありがとう！

的なアントニオ猪木の名言の様なアルゴリズムです。

(1) エンドエンティティ証明書HHH←GGGからパス構築開始
(2) CA証明書 GGG←EEE、EEE←BBB を辿る。
　　　その際に都度、個々の追加される証明書に対して署名値、
　　　識別名前の一致、鍵用途、各種制約の処理失効検証などを行う。
(3) BBB←ROOT証明書の基本制約拡張にcA=TRUEが無いのでGGGに戻る
(4) CA証明書 GGG←DDD、DDD←AAA を辿る。
(5) BBB←ROOT証明書は期限切れなのでGGGに戻る。
(6) CA証明書 GGG←FFF、FFF←CCC、CCC←ROOT を辿る。
(7) トラストアンカまで辿れたので(6)が有効なパスとなり
　　　パス構築・検証は完了。

幅優先の場合、途中選択肢を全て抱えたまま探索するので多くメモリを消費すると言われています。そうした意味では深さ優先はまぁ、妥当かなと、、、

Sun PKIX CertPathBuilder実装の例外のイケズ

ただ、次のようなケースの場合、パス構築を試みて結局は有効なパスが見つからないため「unable to find valid certification path to requested target(要求された対象(証明書)に対する有効な認証パスが見つかりません)」ということになります。





この際のCertPathBuilderException例外のgetCause()には何も入っていないので、何故パス構築・検証に失敗したのかは(普通は)謎のままです。せめてパス構築失敗の元を最後に起こした例外がgetCause()に設定されていれば結構理由がわかるもんなんですけど、残念ながらそうなってません。深さ優先探索なので「前の例外なんかいちいち保存しておくかぁ！！」という実装なんでしょう。

最後に発生した例外をgetCause()に設定するだけだと下のようなケースでは本質的な問題がわからないケースもあるんですが、まぁ、それは現状の何も無いよりはましみたいな感じで残しておいて欲しいなぁ、、、、

パス構築で辿った順序が何故わかるか？

では、何故上の方の図でSun PKIX CertPathBuilderが辿ったパス構築順序がわかったかというとログを見たからなんです。CertPathBuilderやCertPathValidatorでは、以下のように "-Djava.security.debug=certpath"のオプションを付ければデバッグログが標準出力に表示されます。

% java -Djava.security.debug=certpath [CertPathを使ったJavaプログラム]

ただ、ここから出てくるログは今まで見てきたログの中では「中の下」ぐらいのダメさ加減で、多分観てもうんざりするだけだと思います。

で、パス構築で辿った順を観るには以下ようなdepthFirstSearchForwardの部分を見ればよいです。

certpath: SunCertPathBuilder.depthFirstSearchForward(CN=HHH, C=JP, State [

  issuerDN of last cert: null

  traversedCACerts: 0

  init: true

  keyParamsNeeded: false

  subjectNamesTraversed: 

[]]

)

・・・中略・・・

certpath: SunCertPathBuilder.depthFirstSearchForward(CN=ROOT, C=JP, State [

  issuerDN of last cert: CN=ROOT, C=JP

  traversedCACerts: 3

  init: false

  keyParamsNeeded: false

  subjectNamesTraversed: 

[CN=GGG, C=JP, CN=HHH, C=JP, CN=CCC, C=JP, CN=FFF, C=JP]]

)

これを観ていくとHHH→GGG→EEE→BBB×後戻り→DDD→AAA×後戻り→FFF→CCC→ROOT○と二度の失敗にもめげずに辿ったんだぁなぁ、、、頑張ったなぁ、、、、よしよし、、、という風に感慨深いものがあります。

ログを観てもAAA←ROOTやBBB←ROOTの証明書で基本制限に違反しているからとか、期限切れだからとか、そうした理由はログには全く書かれていません。

3本パスがあるうち何故その順序で選んだか？

HHH→GGGと辿って、次にEEE、DDD、FFFのどれを選んでも良いような気がしますが、必ずEEE、DDD、FFFの順序になりました。

証明書を探す際の入れ物としてArrayListをベースにしたCollectionCertStoreを使っていたんですが、そこに中間証明書を加える順序に依存しているのかもしれません。

結局 CertPathBuilder が出す例外は全く役に立たない

というわけで、Sun PKIX CertPathBuilderの吐く例外やログはというのは、どのような理由でパス構築・検証の失敗したのかわからないため使い物にならず、、ただ「unable to find valid certification path to requested target」の例外メッセージが空しくも得られるだけということがおわかり頂けたかと思います。

ではパス構築・検証がダメ理由を知りたきゃどうするか？

SSLサーバー認証では多くの場合SSLサーバー証明書・必要な中間CA証明書・ルート証明書がチェーンの形でごっそり送られてきますし、S/MIME署名メールやCAdES/XAdES長期署名の場合なんかも検証すべき証明書チェーンが概ねわかっている時があります。

自分で証明書チェーンを
・主体者・発行者の名前の一致で
・署名値の一致で
作ることもできることがあります。

そんなときは、自分で簡易パス構築で証明書チェーン作ってCertPathオブジェクトを生成し、CertPathValidatorで(狭義の)パス検証だけを行うのがいいように思います。

例えば、今回のケースで言えば

自前でパス構築だけして、パス検証はCertPathValidatorを使えば、

HHH→GGG→DDD→AAA→ROOTのパスの期限切れエラーなら

×失敗： timestamp check failed
×失敗理由詳細： NotAfter: Sun Jan 02 09:00:00 JST 2000

HHH→GGG→EEE→BBB→ROOTのパスの基本制約のcA=TRUE不足エラーなら

×失敗： basic constraints check failed: this is not a CA certificate

と、例外CertPathValidatorExceptionのgetMessage()で理由がわかってスッキリします。

今回はこれまたマニアックなネタでごめんなさいね。

自分でもパス構築してみたくなったら今回の証明書セットはこちらからダウンロードできます。

＜参考リンク＞
・Sun J2SE 6 - Java PKI APIプログラマーズガイド
・Sun J2SE 6 - Java暗号化アーキテクチャー(JCA) リファレンスガイド
・Sun J2SE 6 - java.security.certパッケージ
・IPA: 電子政府情報セキュリティ相互運用支援技術の開発
　・GPKIアプリケーション実装ガイド報告書 (PDF 831KB)
　　　5章：Javaによる証明書パス構築・パス検証の実装の説明