• Oracle Technology Network
• ソフトウェアダウンロード
• ドキュメント

検索

• 概要
• • 謝辞
  • このドキュメントの対象読者
  • 関連項目
  • はじめに
• コアクラスとインタフェース
• • 基本クラス
  • • CertPath クラス
    • CertificateFactory クラス
    • CertPathParameters インタフェース
  • Certification Path 検証クラス
  • • CertPathValidator クラス
    • CertPathValidatorResult インタフェース
  • Certification Path 構築クラス
  • • CertPathBuilder クラス
    • CertPathBuilderResult インタフェース
  • 証明書/CRL ストレージクラス
  • • CertStore クラス
    • CertStoreParameters インタフェース
    • • LDAPCertStoreParameters クラス
      • CollectionCertStoreParameters クラス
    • CertSelector および CRLSelector インタフェース
    • • X509CertSelector クラス
      • X509CRLSelector クラス
  • PKIX クラス
  • • TrustAnchor クラス
    • PKIXParameters クラス
    • PKIXCertPathValidatorResult クラス
    • PolicyNode インタフェースおよび PolicyQualifierInfo クラス
    • PKIXBuilderParameters クラス
    • PKIXCertPathBuilderResult クラス
    • PKIXCertPathChecker クラス
    • 証明書パス検証での PKIXCertPathChecker の使用
• サービスプロバイダの実装
• 署名タイムスタンプのサポート
• 付録 A: 標準名
• 付録 B: 「SUN」プロバイダ
• 付録 C: OCSP (On-Line Certificate Status Protocol) サポート
• 付録 D: 暗号化アルゴリズムの無効化

概要

Java Certification Path API は、証明書パス (「証明書チェーン」とも呼ばれる) を扱うためのクラスとインタフェースで構成されます。証明書パスは、順序付けされた証明書リストです。証明書パスは、特定の検証規則を満たす場合に、公開鍵から主体へのマッピングを安全に確立するために使用されます。

この API は、証明書パスを作成、構築、および検証するためのインタフェースと抽象クラスを定義します。 実装は、プロバイダベースのインタフェースを使ってプラグインされます。API は、「Java 暗号化アーキテクチャーリファレンスガイド」で説明されている暗号化サービスプロバイダアーキテクチャーに基づいています。

また、API には、PKIX 標準に従って X 509 証明書パスを構築および検証するためのアルゴリズム固有のクラスが含まれます。PKIX 標準は、IETF PKIX ワーキンググループによって開発されます。

この API は、最初は Java Community ProcessSM プログラムを使用して指定されました (Java Specification Request (JSR) 000055)。この API は、Java 2 Standard Edition (JDK) バージョン 1.4 から Java SDK に含まれました。詳細については、「JSR 55: Certification Path API」を参照してください。

謝辞

エキスパートグループは、Java Community Process を使って API を改良し、調整を施す作業の一翼を担いました。このグループのメンバーは、次の方々です。

• Peter Hesse、CygnaCom Solutions、An Entrust Technologies Company
• Sean Mullan、Sun Microsystems (仕様リード)
• Anthony Nadalin、IBM
• Bob Naugle、Bluestone Software
• Hemma Prafullchandra、Verisign
• Ming Yung、DSTC

このドキュメントの対象読者

1. 証明書パスを構築または検証する、セキュリティー保護されたアプリケーションを設計する人

2. 証明書パスを構築または検証するためのサービスプロバイダ実装を記述する人

関連項目

• X.509 証明書と証明書の取り消しリスト (CRL)

• Java 暗号化アーキテクチャーリファレンスガイド

• Java 暗号化アーキテクチャー用プロバイダの実装方法

はじめに

公開鍵アプリケーションおよびシステムのユーザーは、主体の公開鍵が本物であること、つまり、関連する非公開鍵が主体によって所有されていることを確信している必要があります。公開鍵証明書は、この信頼を確立するのに使用されます。公開鍵 (またはアイデンティティー) 証明書は、公開鍵のアイデンティティーへのバインディングです。アイデンティティーは、別のエンティティー (多くの場合証明書発行局 (CA) と呼ばれる) の非公開鍵でデジタル署名されます。このセクションの残りの部分では、CA という用語は、証明書に署名するエンティティーの意味で使用されます。

ユーザーは、主体の公開鍵証明書に署名した CA の公開鍵の信頼できるコピーを持っていない場合、署名している CA を保証する別の公開鍵証明書が必要です。この論理は、証明書の連鎖 (または証明書パス) が信頼できるアンカーまたはもっとも信頼できる CA から検出されるまで、再帰的にターゲットの主体 (一般にエンドエンティティーと呼ばれる) に適用されます。通常、もっとも信頼できる CA は、ユーザーが直接信頼する CA に宛てて発行した証明書によって指定されます。一般に証明書パスは順序付けされた証明書のリストで、通常の場合、エンドエンティティーの公開鍵証明書と 0 個以上の付加的な証明書で構成されます。通常、証明書パスには 1 つ以上のエンコードがあります。これにより、証明書パスは、安全にネットワークを通じて伝送されたり、別のオペレーティングシステムアーキテクチャーへ送信されたりします。

図 1 は、もっとも信頼できる CA の公開鍵 (CA 1) からターゲットの主体 (Alice) への証明書パスを示しています。証明書パスは、CA2 という名前の中間 CA を介して、Alice の公開鍵との信頼を確立します。

証明書パスは、主体の公開鍵の信頼を確立するため、信頼する前に検証する必要があります。検証では、署名を検証したり、各証明書が取り消されていないことをチェックしたりするなど、証明書パスに含まれている証明書に対するさまざまなチェックを行います。PKIX 標準は、X.509 証明書で構成される証明書パスの検証に関するアルゴリズムを定義します。

ユーザーは、もっとも信頼できる CA から主体への証明書パスを持っていないことがあります。証明書パスを構築または検出するサービスの提供は、公開鍵に対応するシステムの重要な機能です。RFC 2587 は、LDAP (Lightweight Directory Access Protocol) スキーマ定義を定義します。LDAP スキーマ定義により、LDAP ディレクトリサービスプロトコルを使った X.509 証明書パスの検出が容易になります。

証明書パスの構築および検証は、SSL/TLS、S/MIME、IPSEC など、多くの標準セキュリティープロトコルの重要な一部です。 Java Certification Path API は、この機能をアプリケーションに統合する必要のある開発者に、クラスおよびインタフェースのセットを提供します。この API は、特定の証明書パスの構築、または検証アルゴリズム用にサービスプロバイダ実装を記述する必要がある開発者、および実装に依存しない方式による証明書パスの作成、構築、検証のために標準アルゴリズムにアクセスする必要のある開発者にとって便利です。

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

Java Certification Path API のコアクラスは、アルゴリズムおよび実装に依存しない方式の証明書パスの機能をサポートするインタフェースおよびクラスで構成されています。また、API には、PKIX 標準のアルゴリズム固有のクラスのセットが含まれています。PKIX 標準については、「PKIX クラス」セクションで説明します。API は、証明書を処理する既存の Java Standard Edition (JDK) java.security.cert パッケージに構築され、その機能を拡張します。コアクラスは、次のように基本、検証、構築、およびストレージという 4 つのクラスカテゴリに分けることができます。

• 基本の Certification Path クラス

  • CertPath, CertificateFactory, CertPathParameters

• Certification Path 検証クラス

  • CertPathValidator, CertPathValidatorResult

• Certification Path 構築クラス

  • CertPathBuilder, CertPathBuilderResult

• 証明書/CRL ストレージクラス

  • CertStore, CertStoreParameters, CertSelector, CRLSelector

次のセクションでは、各クラスおよびインタフェースのもっとも一般的に使用されているメソッドを説明します。いくつかのクラスの使用例は、このガイド全体を通じて、何度か出てきます。Certification Path API クラスの完全なリファレンスドキュメントは、次のとおりです。

• java.security.cert パッケージのサマリー

CertPath API のクラスおよびインタフェースの大半は、スレッドに対して安全ではありません。しかし、このガイドおよび API 仕様で言及される例外もあります。スレッドに対して安全でない単一のオブジェクトに同時にアクセスする必要のある複数のスレッドは、互いに同期して必要なロックを行うものとします。複数のスレッドがそれぞれ個別のオブジェクトを処理する場合、それらのスレッドは同期する必要はありません。

基本の Certification Path クラス

基本の証明書パスクラスは、証明書パスをエンコードおよび表示する基本的な機能を提供します。Java Certification Path API の主要な基本クラスは CertPath です。このクラスは、すべての型の証明書パスで共有される汎用的な部分をカプセル化します。アプリケーションは、CertificateFactory クラスのインスタンスを使って CertPath オブジェクトを生成します。

CertPath クラス

CertPath クラスは、証明書パスの抽象クラスです。すべての証明書パスオブジェクトが共有する機能を定義します。さまざまな証明書パスの型は、それが異なる内容および順序付けスキームを持っていても、CertPath クラスをサブクラス化することによって実装できます。すべての CertPath オブジェクトは、直列化可能、不変、かつスレッドに対して安全です。さらに、次の特徴を備えています。

• A 型
  
  これは、証明書パスの証明書の型と対応しています。たとえば、X.509 のようになります。CertPath の型は、次のメソッドを使って取得されます。
  
  

      public String getType()
  

  標準的な証明書の型の詳細は、「Java 暗号化アーキテクチャーリファレンスガイド」の付録 A を参照してください。
  
  

• 証明書リスト
  
  getCertificates メソッドは、証明書パスに含まれる証明書のリストを返します。  
  
  

      public abstract List<? extends Certificate> getCertificates()
  

  このメソッドは、0 個以上の java.security.cert.Certificate オブジェクトの List を返します。返される List およびその中に含まれる Certificates は、CertPath オブジェクトの内容を保護するため、変更できません。返される証明書の順序付けは、型に依存します。規則により、X.509 型の CertPath オブジェクト内の証明書は、ターゲットとなる証明書から順に並べられ、信頼できるアンカーによって発行された証明書が最後に置かれます。つまり、証明書の発行者は、その次に続く証明書の主体になります。TrustAnchor を表す証明書を証明書パスに含めることはできません。ただし、検証されていない X.509 の CertPath は、この規則に従っていないことがあります。PKIX CertPathValidator は、この規則の違反を検出することにより、証明書パスが無効になり CertPathValidatorException がスローされるのを防ぎます。
  
  

• 1 つ以上のエンコード
  
  各 CertPath オブジェクトは、1 つ以上のエンコードをサポートします。これらは証明書パスの外部エンコード形式で、ネットワークを通じてパスを別の組織に転送する際に、パスの標準表示が Java 仮想マシンの外部で必要なときに使用します。各パスはデフォルトの形式でエンコードされ、そのバイトは次のメソッドを使って返されます。
  
  

      public abstract byte[] getEncoded()
  

  一方、getEncoded(String) メソッドは、エンコード形式を String (例:「PKCS7」) で指定することにより、サポートされる特定のエンコード形式を返します。標準のエンコード形式のリストは、付録 A で定義されています。
  
  

      public abstract byte[] getEncoded(String encoding)
  

  また、getEncodings メソッドは、サポートされるエンコード形式 String でもイテレータを返します (デフォルトのエンコード形式が最初に返される)。
  
  

      public abstract Iterator<String> getEncodings()
  

すべての CertPath オブジェクトは Serializable でもあります。直列化中に CertPath オブジェクトは代替 CertPathRep オブジェクトに解釈処理されます。これにより、基本的な実装にかかわらず、CertPath オブジェクトを同等の表現に直列化できます。

CertPath オブジェクトは、CertificateFactory を使って、エンコードされたバイト配列または Certificate のリストから生成されます。一方、CertPathBuilder は、もっとも信頼できる CA から特定の主体への CertPath を探すために使用されます。CertPath オブジェクトが生成されると、それは CertPathValidator の validate メソッドに渡され、検証されます。これらの概念の詳細については、続くセクションで説明します。

CertificateFactory クラス

CertificateFactory クラスは、証明書ファクトリの機能を定義するエンジンクラスです。このクラスは、JDK, v 1.4 より前のリリースでは、Certificate および CRL オブジェクトの生成に使用されていました。JDK, v 1.4 では、クラスが拡張され、証明書パス (CertPath) オブジェクトの生成にも使用されるようになりました。CertificateFactory を CertPathBuilder と混同しないでください。CertPathBuilder (後述) は、証明書パスが存在しないときに、証明書パスの検出または発見に使用されます。それに対して CertificateFactory は、証明書パスがすでに検出されていて、エンコードされたバイト配列または Certificate の配列など、異なる形式で存在する内容から呼び出し側が CertPath オブジェクトのインスタンスを生成する必要があるときに使用されます。

CertificateFactory オブジェクトの作成

CertificateFactory オブジェクトの作成に関する詳細は、「Java 暗号化アーキテクチャーリファレンスガイド」の「CertificateFactory」セクションを参照してください。

CertPath オブジェクトの生成

CertificateFactory のインスタンスは、Certificate オブジェクトの List、または CertPath のエンコードされた形式を含む InputStream から、CertPath オブジェクトを生成します。CertPath と同様、それぞれの CertificateFactory は、証明書パス (PKCS#7 など) のデフォルトのエンコード形式をサポートします。CertPath オブジェクトを生成し、そのオブジェクトを入力ストリームから (デフォルトのエンコード形式で) 読み込まれたデータを使って初期化するには、generateCertPath メソッドを使用します。

    public final CertPath generateCertPath(InputStream inStream)

特定のエンコード形式から読み込まれたデータを使用する場合は次のようになります。

    public final CertPath generateCertPath(InputStream inStream, 
                                           String encoding)

サポートされているエンコード形式を調べるには、getCertPathEncodings メソッドを使用します (デフォルトのエンコードが最初に返される)。

    public final Iterator<String> getCertPathEncodings()

証明書パスオブジェクトを Certificate オブジェクトの List から生成するには、次のメソッドを使用します。

    public final CertPath generateCertPath(List<? extends Certificate> certificates)

CertificateFactory は、ファクトリと同じ型の Certificate で構成された CertPath オブジェクトを常に返します。たとえば、X.509 型の CertificateFactory は、java.security.cert.X509Certificate のインスタンスである証明書で構成された CertPath オブジェクトを返します。

次のコード例は、PKCS#7 でエンコードされた、ファイルに格納されている証明書応答から証明書パスを生成する方法を示しています。

    // open an input stream to the file
    FileInputStream fis = new FileInputStream(filename);
    // instantiate a CertificateFactory for X.509
    CertificateFactory cf = CertificateFactory.getInstance("X.509");
    // extract the certification path from
    // the PKCS7 SignedData structure
    CertPath cp = cf.generateCertPath(fis, "PKCS7");
    // print each certificate in the path
    List<Certificate> certs = cp.getCertificates();
    for (Certificate cert : certs) {
        System.out.println(cert);
    }
        

    // instantiate a KeyStore with type JKS
    KeyStore ks = KeyStore.getInstance("JKS");
    // load the contents of the KeyStore
    ks.load(new FileInputStream("./keystore"),
        "password".toCharArray());
    // fetch certificate chain stored with alias "sean"
    Certificate[] certArray = ks.getCertificateChain("sean");
    // convert chain to a List
    List certList = Arrays.asList(certArray);
    // instantiate a CertificateFactory for X.509
    CertificateFactory cf = CertificateFactory.getInstance("X.509");
    // extract the certification path from
    // the List of Certificates
    CertPath cp = cf.generateCertPath(certList);
        

generateCertificates という名前の CertificateFactory に、Certificate のシーケンスを構文解析する既存のメソッドがあることに注意してください。複数の証明書から成るエンコードでは、互いに関連性がないと思われる証明書のコレクションを解析する場合に、generateCertificates を使用します。それ以外では、CertPath を生成し、CertPathValidator (後述) で検証する場合に、generateCertPath を使用します。

CertPathParameters インタフェース

CertPathParameters インタフェースは、特定の証明書パスビルダーまたは検証アルゴリズムで使用される一連のパラメータの透明な表現です。このインタフェースの主な目的は、すべての証明書パスのパラメータの仕様をグループ化すること (およびそれらのパラメータに安全な型を提供すること) です。CertPathParameters インタフェースは、Cloneable インタフェースを拡張し、例外をスローしない clone() メソッドを定義します。このインタフェースのすべての固定実装は、必要に応じて Object.clone() メソッドを実装し、オーバーライドします。これにより、アプリケーションは、CertPathParameters オブジェクトを複製できます。

CertPathParameters インタフェースを実装しているオブジェクトは、CertPathValidator および CertPathBuilder クラスのメソッドに引数として渡されます。一般に、CertPathParameters インタフェースの固定実装は、特定の証明書パスの構築または検証アルゴリズムに固有の入力パラメータのセットを保持します。たとえば、PKIXParameters クラスは、PKIX 証明書パス検証アルゴリズムの入力パラメータのセットを保持する CertPathParameters インタフェースの実装です。このようなパラメータの 1 つに、呼び出し側が検証処理のアンカーについて信頼する、もっとも信頼できる CA のセットがあります。このパラメータについては特に、PKIXParameters クラスを扱ったセクションで詳しく説明します。

Certification Path 検証クラス

Java Certification Path API には、証明書パスを検証するクラスおよびインタフェースが含まれています。アプリケーションは、CertificateFactory クラスのインスタンスを使って CertPath オブジェクトを検証します。成功すると、CertPathValidatorResult インタフェースを実装するオブジェクトに、検証アルゴリズムの結果が返されます。

CertPathValidator クラス

CertPathValidator クラスは、証明書パスの検証に使用されるエンジンクラスです。

CertPathValidator オブジェクトの生成

ほかのエンジンクラスと同様に、特定の検証アルゴリズム用の CertPathValidator オブジェクトを取得するには、CertPathValidator クラスの getInstance static ファクトリメソッドの 1 つを呼び出します。

        public static CertPathValidator getInstance(String algorithm)
        public static CertPathValidator getInstance(String algorithm, 
                                                    String provider)
        public static CertPathValidator getInstance(String algorithm, 
                                                    Provider provider)

証明書パスの検証

CertPathValidator オブジェクトが生成されると、validate メソッドを呼び出して、検証する証明書パスおよびアルゴリズム固有のパラメータセットを渡すことによって、パスを検証できます。

        public final CertPathValidatorResult 
                validate(CertPath certPath, CertPathParameters params)
                throws CertPathValidatorException, 
                       InvalidAlgorithmParameterException

検証アルゴリズムが成功すると、CertPathValidatorResult インタフェースを実装するオブジェクトに結果が返されます。そうでない場合は、CertPathValidatorException がスローされます。CertPathValidatorException には、CertPath を返すメソッドが含まれます。また、必要に応じて、アルゴリズムの失敗を引き起こした証明書のインデックスや、エラーの根本となる例外または原因を返すメソッドが含まれます。

validate メソッドに渡される CertPath および CertPathParameters は、検証アルゴリズムによってサポートされた型である必要があります。それ以外の場合は、InvalidAlgorithmParameterException がスローされます。たとえば、PKIX アルゴリズムを実装する CertPathValidator インスタンスは、X.509 型の CertPath オブジェクト、および PKIXParameters のインスタンスである CertPathParameters を検証します。

CertPathValidatorResult インタフェース

CertPathValidatorResult インタフェースは、証明書パス検証アルゴリズムの成功結果または出力の透明な表現です。このインタフェースの主な目的は、すべての検証結果をグループ化すること (およびそれらの検証結果に安全な型を提供すること) です。CertPathParameters インタフェースと同様に、CertPathValidatorResult インタフェースは、Cloneable を拡張し、例外をスローしない clone() メソッドを定義します。これにより、アプリケーションは、CertPathValidatorResult オブジェクトを複製できます。

CertPathValidatorResult インタフェースを実装しているオブジェクトは、CertPathValidator の validate メソッドによって返されます (成功時のみ。そうでない場合は、CertPathValidatorException はエラーの記述とともにスローされます)。一般に、CertPathValidatorResult インタフェースの固定実装は、特定の証明書パス検証アルゴリズムに固有の出力パラメータのセットを保持します。たとえば、PKIXCertPathValidatorResult クラスは、PKIX 証明書パス検証アルゴリズムの出力パラメータを取得するメソッドを含む CertPathValidatorResult インタフェースの実装です。このようなパラメータの 1 つに、有効なポリシーツリーがあります。このパラメータについては特に、PKIXCertPathValidatorResult クラスを扱ったセクションで詳しく説明します。

次の簡単なコード例では、CertPathValidator を生成し、証明書パスの検証に使用する方法を示します。この例は、validate メソッドに渡される CertPath および CertPathParameters オブジェクトが事前に生成されていることを前提としています。より詳しい例は、PKIX クラスを説明したセクションにあります。

    // create CertPathValidator that implements the "PKIX" algorithm
    CertPathValidator cpv = null;
    try {
        cpv = CertPathValidator.getInstance("PKIX");
    } catch (NoSuchAlgorithmException nsae) {
        System.err.println(nsae);
        System.exit(1);
    }
    // validate certification path ("cp") with specified parameters ("params")
    try {
        CertPathValidatorResult cpvResult = cpv.validate(cp, params);
    } catch (InvalidAlgorithmParameterException iape) {
        System.err.println("validation failed: " + iape);
        System.exit(1);
    } catch (CertPathValidatorException cpve) {
        System.err.println("validation failed: " + cpve);
        System.err.println("index of certificate that caused exception: "
                + cpve.getIndex());
        System.exit(1);
    }

Certification Path 構築クラス

Java Certification Path API には、証明書パスを構築する (または検出する) ためのクラスが含まれています。アプリケーションは、CertPathBuilder クラスのインスタンスを使って CertPath オブジェクトを構築します。成功すると、CertPathBuilderResult インタフェースを実装するオブジェクトに、構築の結果が返されます。

CertPathBuilder クラス

CertPathValidator クラスは、証明書パスの構築に使用されるエンジンクラスです。

CertPathBuilder オブジェクトの生成

ほかのエンジンクラスと同様に、特定の構築アルゴリズム用の CertPathBuilder オブジェクトを取得するには、CertPathBuilder クラスの getInstance static ファクトリメソッドの 1 つを呼び出します。

        public static CertPathBuilder getInstance(String algorithm)
        public static CertPathBuilder getInstance(String algorithm, 
                                                  String provider)
        public static CertPathBuilder getInstance(String algorithm, 
                                                  Provider provider)

証明書パスの構築

CertPathBuilder オブジェクトが生成されると、build メソッドを呼び出して、アルゴリズム固有のパラメータ仕様を渡すことによって、パスを構築できます。

        public final CertPathBuilderResult build(CertPathParameters params)
                throws CertPathBuilderException, 
                       InvalidAlgorithmParameterException

構築アルゴリズムが成功すると、CertPathBuilderResult インタフェースを実装するオブジェクトに結果が返されます。失敗した場合は、たとえば、基になる例外 (存在する場合) とエラーメッセージなど、エラーについての情報を含む CertPathBuilderException がスローされます。

build メソッドに渡される CertPathParameters は、構築アルゴリズムによってサポートされた型である必要があります。それ以外の場合は、InvalidAlgorithmParameterException がスローされます。

CertPathBuilderResult インタフェース

CertPathBuilderResult インタフェースは、証明書パス構築アルゴリズムの結果または出力の透明な表現です。このインタフェースには、次に示すように、正常に構築された証明書パスを返すメソッドが含まれます。

        public CertPath getCertPath()

CertPathBuilderResult インタフェースの目的は、すべての構築結果をグループ化すること (およびそれらの構築結果に安全な型を提供すること) です。CertPathValidatorResult インタフェースと同様に、CertPathBuilderResult インタフェースは、Cloneable を拡張し、例外をスローしない clone() メソッドを定義します。これにより、アプリケーションは、CertPathBuilderResult オブジェクトを複製できます。

CertPathBuilderResult インタフェースを実装するオブジェクトは、CertPathBuilder の build メソッドによって返されます。

次の簡単なコード例では、CertPathBuilder を生成し、証明書パスの構築に使用する方法を示します。この例は、build メソッドに渡される CertPathParameters オブジェクトが事前に生成されていることを前提としています。より詳しい例は、PKIX クラスを説明したセクションにあります。

    // create CertPathBuilder that implements the "PKIX" algorithm
    CertPathBuilder cpb = null;
    try {
        cpb = CertPathBuilder.getInstance("PKIX");
    } catch (NoSuchAlgorithmException nsae) {
        System.err.println(nsae);
        System.exit(1);
    }
    // build certification path using specified parameters ("params")
    try {
        CertPathBuilderResult cpbResult = cpb.build(params);
        CertPath cp = cpbResult.getCertPath();
        System.out.println("build passed, path contents: " + cp);
    } catch (InvalidAlgorithmParameterException iape) {
        System.err.println("build failed: " + iape);
        System.exit(1);
    } catch (CertPathBuilderException cpbe) {
        System.err.println("build failed: " + cpbe);
        System.exit(1);
    }

証明書/CRL ストレージクラス

Java Certification Path API には、リポジトリから証明書および CRL を取得する CertStore クラスも含まれています。このクラスを使用すると、呼び出し側は、CertPathValidator または CertPathBuilder の実装が証明書および CRL の検出に使用するリポジトリを指定できます (例については、PKIXParameters の addCertStores メソッドを参照)。

CertPathValidator 実装は、呼び出し側がコールバックメカニズムとして指定した CertStore オブジェクトを使用して CRL をフェッチし、取り消しのチェックを行います。同様に、CertPathBuilder 実装は、CertStore をコールバックメカニズムとして使用して証明書をフェッチします。また、取り消しのチェックを行なっている場合は CRL をフェッチします。

CertStore クラス

CertStore クラスは、証明書および証明書の取り消しリスト (CRL) のリポジトリとして機能するエンジンクラスです。このクラスは、CertPathBuilder および CertPathValidator の実装によって、証明書および CRL の検索のため、または汎用の証明書および CRL の取得メカニズムとして使用されます。

CertStore は、非公開鍵および信頼できる証明書のキャッシュへのアクセスを提供する java.security.KeyStore クラスとは異なり、非常に大きくなる可能性がある、信頼されない証明書および CRL のリポジトリへのアクセスを提供するように設計されています。たとえば、CertStore の LDAP 実装は、1 つ以上のディレクトリに格納されている証明書および CRL に対するアクセスを、LDAP プロトコルを使って提供します。

CertStore オブジェクトのすべての public メソッドは、スレッドに対して安全です。つまり、単一の (または複数の) CertStore オブジェクト上で、複数のスレッドがこれらのメソッドを並行して呼び出しても、悪影響はありません。これにより、たとえば CertPathBuilder は、CRL を検索しながら同時にほかの証明書を検索できます。

CertStore オブジェクトの生成

ほかのエンジンクラスと同様に、特定のリポジトリ型用の CertStore オブジェクトを取得するには、CertStore クラスの getInstance static ファクトリメソッドの 1 つを呼び出します。

        public static CertStore getInstance(String type, 
                CertStoreParameters params)
        public static CertStore getInstance(String type,
                CertStoreParameters params, String provider)
        public static CertStore getInstance(String type,
                CertStoreParameters params, Provider provider)

初期化パラメータ (params) は、リポジトリ型に固有のものです。たとえば、サーバーベースのリポジトリの初期化パラメータは、サーバーのホスト名およびポートを含みます。パラメータがこの CertStore 型について無効な場合、InvalidAlgorithmParameterException がスローされます。getCertStoreParameters メソッドは、CertStore を初期化するために使用された CertStoreParameters を返します。

        public final CertStoreParameters getCertStoreParameters()

証明書の取得

CertStore オブジェクトを生成すると、getCertificates メソッドを使ってリポジトリから証明書を取得できます。このメソッドは、CertSelector オブジェクト (詳細は後述) を引数として取得します。この引数は、どの証明書が返されるかを決定する一連の選択条件を指定します。

        public final Collection<? extends Certificate> getCertificates(CertSelector selector) 
                throws CertStoreException

このメソッドは、選択条件を満たす java.security.cert.Certificate オブジェクトの Collection を返します。一致するものがない場合は、空の Collection が返されます。リモートリポジトリとの通信障害など、予期しないエラー状態が生じた場合は、通常、CertStoreException がスローされます。

ある種の CertStore 実装では、指定した選択条件に一致する証明書または CRL をリポジトリ全体で検索できません。これらのインスタンスでは、CertStore 実装は、証明書および CRL を検索するセレクタで指定された情報を使用します。たとえば、LDAP CertStore は、ディレクトリ内のすべてのエントリを検索しない場合があります。その代わりに、探している証明書を含んでいる可能性のあるエントリだけを検索します。LDAP CertStore がどのエントリを検索すべきかを判断するための十分な情報を CertSelector が提供しない場合、LDAP CertStore は CertStoreException をスローします。

CRL の取得

getCRLs メソッドを使ってリポジトリから CRL を取得することもできます。このメソッドは、CRLSelector オブジェクト (詳細は後述) を引数として取得します。この引数は、どの CRL が返されるかを決定する一連の選択条件を指定します。

        public final Collection<? extends CRL> getCRLs(CRLSelector selector) 
                throws CertStoreException

このメソッドは、選択条件を満たす java.security.cert.CRL オブジェクトの Collection を返します。一致するものがない場合は、空の Collection が返されます。

CertStoreParameters インタフェース

CertStoreParameters インタフェースは、特定の CertStore で使用されるパラメータのセットの透明な表現です。このインタフェースの主な目的は、すべての証明書ストレージのパラメータの仕様をグループ化すること (およびそれらのパラメータに安全な型を提供すること) です。CertStoreParameters インタフェースは、Cloneable インタフェースを拡張し、例外をスローしない clone メソッドを定義します。このインタフェースの実装は、必要に応じて Object.clone() メソッドを実装し、オーバーライドします。これにより、アプリケーションは、CertStoreParameters オブジェクトを複製できます。

CertStoreParameters インタフェースを実装しているオブジェクトは、CertStore クラスの getInstance メソッドに引数として渡されます。CertStoreParameters インタフェースを実装している LDAPCertStoreParameters と CollectionCertStoreParameters の 2 つのクラスは、この API で定義されます。

LDAPCertStoreParameters クラス

LDAPCertStoreParameters クラスは、CertStoreParameters インタフェースの実装で、証明書および CRL を LDAP 型の CertStore から取得するために最低限の初期化パラメータのセット (ディレクトリサーバーのホストおよびポート番号) を保持します。

このクラスの詳細については、LDAPCertStoreParameters の API ドキュメントを参照してください。

CollectionCertStoreParameters クラス

CollectionCertStoreParameters クラスは、CertStoreParameters インタフェースの実装で、証明書および CRL を Collection 型の CertStore から取得するための初期化パラメータのセットを保持します。

このクラスの詳細については、CollectionCertStoreParameters の API ドキュメントを参照してください。

CertSelector および CRLSelector インタフェース

CertSelector および CRLSelector インタフェースは、証明書および CRL のコレクションまたは大きなグループから、証明書および CRL を選択するための一連の条件の仕様です。インタフェースはグループ化され、すべてのセレクタの仕様に型の安全性を提供します。各セレクタインタフェースは、Cloneable を拡張し、例外をスローしない clone() メソッドを定義します。これにより、アプリケーションは、CertSelector または CRLSelector オブジェクトを複製できます。

CertSelector および CRLSelector インタフェースは、それぞれ match という名前のメソッドを定義します。match メソッドは、Certificate または CRL オブジェクトを引数として取得し、オブジェクトが選択条件を満たす場合、true を返します。そうでない場合は、false を返します。CertSelector インタフェースの match メソッドは、次のようにして定義されます。

        public boolean match(Certificate cert)

CRLSelector インタフェースについては、次のようにして定義されます。

        public boolean match(CRL crl)

一般に、これらのインタフェースを実装しているオブジェクトは、CertStore クラスの getCertificates および getCRLs メソッドにパラメータとして渡されます。これらのメソッドは、指定された選択条件に一致する CertStore リポジトリから、Certificate または CRL の Collection を返します。また、CertSelector は、証明書パスのターゲットまたはエンドエンティティー証明書で、検証の制約を指定するためにも使用されます ( PKIXParameters.setTargetCertConstraints メソッドの例を参照)。

X509CertSelector クラス

X509CertSelector クラスは、X.509 証明書を選択するための一連の条件を定義する CertSelector インタフェースの実装です。X509Certificate オブジェクトは、match メソッドによって選択されるには、指定された条件のすべてを満たす必要があります。この選択条件は、CertPathBuilder 実装が X.509 証明書パスを構築する際に、潜在的な証明書を検出するために使用するよう設計されています。

たとえば、X509CertSelector の setSubject メソッドを使用すると、PKIX CertPathBuilder は、部分的に完成された連鎖の中で、先行する X509Certificate の発行者名と一致しない X509Certificate をフィルタにかけることができます。X509CertSelector オブジェクトで、この条件とともにその他の条件を設定することにより、CertPathBuilder は、無関係な証明書を破棄して、CertPathParameters オブジェクトで指定した要件を満たす X.509 証明書パスをより簡単に探すことができます。

このセクションで説明した X.509 証明書の拡張機能の定義については、http://www.ietf.org/rfc/rfc3280.txt を参照してください。

X509CertSelector オブジェクトの生成

X509CertSelector オブジェクトは、次のようにしてデフォルトのコンストラクタを呼び出すことにより生成されます。

        public X509CertSelector()

最初は、条件は何も設定されていません (どの X509Certificate も一致)。

選択条件の設定

呼び出し側は、選択条件を使用して X.509 証明書の異なるコンポーネントを照合できます。ここでは、選択条件を設定するいくつかのメソッドについて説明します。その他のメソッドの詳細については、X509CertSelector の API ドキュメントを参照してください。

setIssuer メソッドは、発行者の条件を設定します。

        public void setIssuer(X500Principal issuer)
        public void setIssuer(String issuerDN)
        public void setIssuer(byte[] issuerDN)

指定された識別名 (X500Principal、RFC 2253 String、または ASN.1 DER エンコード形式) は、証明書にある発行者の識別名と一致する必要があります。null の場合、発行者の識別名は問われません。識別名の表現には、型定義が適切で効率的なため、X500Principal を使用することをお勧めします。

同様に、setSubject メソッドは主体の条件を設定します。

        public void setSubject(X500Principal subject)
        public void setSubject(String subjectDN)
        public void setSubject(byte[] subjectDN)

指定された識別名 (X500Principal、RFC 2253 String、または ASN.1 DER エンコード形式) は、証明書にある主体の識別名と一致する必要があります。null の場合、主体の識別名は問われません。

setSerialNumber メソッドは、serialNumber の条件を設定します。

        public void setSerialNumber(BigInteger serial)

指定されたシリアル番号は、証明書にある証明書シリアル番号と一致する必要があります。null の場合、証明書シリアル番号は問われません。

setAuthorityKeyIdentifier メソッドは、authorityKeyIdentifier の条件を設定します。

        public void setAuthorityKeyIdentifier(byte[] authorityKeyID)

証明書には、指定された値と一致する Authority Key Identifier 拡張機能が含まれている必要があります。null の場合、authorityKeyIdentifier 条件に関するチェックは行われません。

setCertificateValid メソッドは、certificateValid の条件を設定します。

        public void setCertificateValid(Date certValid)

指定された日付は、証明書の証明書有効期間内に収まる必要があります。null の場合、どの日付も有効です。

setKeyUsage メソッドは、keyUsage の条件を設定します。

        public void setKeyUsage(boolean[] keyUsage)

証明書の Key Usage Extension は、指定された keyUsage の値 (true に設定されている値) を許可する必要があります。null の場合、keyUsage の確認は行われません。

選択条件の取得

各選択条件の現在の値は、該当する get メソッドを使って取得できます。これらのメソッドの詳細については、X509CertSelector の API ドキュメントを参照してください。

例

ここでは、X509CertSelector クラスを使って LDAP CertStore から X.509 証明書を取得する例を取り上げます。

はじめに、LDAP サーバーのホスト名およびポートを含む CertStore オブジェクトの初期化に使用する LDAPCertStoreParameters オブジェクトを生成します。

        LDAPCertStoreParameters lcsp = new 
                LDAPCertStoreParameters("ldap.sun.com", 389);

次に、CertStore オブジェクトを生成し、次の文のようにして、LDAPCertStoreParameters オブジェクトを渡します。

        CertStore cs = CertStore.getInstance("LDAP", lcsp);

この呼び出しは、RFC 2587 で定義されたスキーマを使って、証明書および CRL を LDAP リポジトリから取得する CertStore オブジェクトを生成します。

次のコードのブロックは、有効期限内のエンドエンティティーの証明書をすべて取得する X509CertSelector を確立します。この証明書は、1) デジタル署名を許可する鍵の利用法、および 2) 特定の電子メールアドレスとともに主体の代替名を持つ特定の主体に発行されます。

        X509CertSelector xcs = new X509CertSelector();
        // select only unexpired certificates
        xcs.setCertificateValid(new Date());
        // select only certificates issued to
        // 'CN=alice, O=xyz, C=us'
        xcs.setSubject(new X500Principal("CN=alice, O=xyz, C=us"));
        // select only end-entity certificates
        xcs.setBasicConstraints(-2);
        // select only certificates with a digitalSignature
        // keyUsage bit set (set the first entry in the
        // boolean array to true)
        boolean[] keyUsage = {true};
        xcs.setKeyUsage(keyUsage);
        // select only certificates with a subjectAltName of
        // 'alice@xyz.example.com' (1 is the integer value of 
        // an RFC822Name)
        xcs.addSubjectAlternativeName(1, "alice@xyz.example.com");

次に、以前に生成した CertStore オブジェクトの getCertificates メソッドにセレクタを渡します。

        Collection<Certificate> certs = cs.getCertificates(xcs);

PKIX CertPathBuilder は、潜在的な証明書の検出およびソートを容易にするため、同様のコードを使用して、検証制約またはその他の条件を満たさない潜在的な証明書を破棄することがあります。

X509CRLSelector クラス

X509CRLSelector クラスは、X.509 CRL を選択する一連の条件を定義する CRLSelector インタフェースの実装です。X509CRL オブジェクトは、match メソッドによって選択されるには、指定された条件のすべてを満たす必要があります。選択条件は、リポジトリから CRL を取得する必要のある CertPathValidator または CertPathBuilder 実装が、X.509 証明書パスにある証明書の取り消しステータスをチェックするのに役立つよう設計されています。

たとえば、X509CRLSelector の setDateAndTime メソッドを使用すると、PKIX CertPathValidator は、指示された時間のあとに発行された、または指示された時間の前に期限が切れる X509CRL をフィルタにかけることができます。X509CRLSelector オブジェクトで、この条件とともにその他の条件を設定することにより、CertPathValidator は、無関係な CRL を破棄して、証明書が取り消されているかどうかをより簡単にチェックできます。

このセクションで説明した X.509 CRL フィールドおよび拡張機能の定義については、http://www.ietf.org/rfc/rfc3280.txt を参照してください。

X509CRLSelector オブジェクトの生成

X509CRLSelector オブジェクトは、次のようにしてデフォルトのコンストラクタを呼び出すことにより生成されます。

        public X509CRLSelector()

最初は、条件は何も設定されていません (どの X509CRL も一致)。

選択条件の設定

呼び出し側は、選択条件を使用して X.509 CRL の異なるコンポーネントを照合できます。ここでは、選択条件を設定するほとんどのメソッドについて説明します。残りのメソッドの詳細については、X509CRLSelector の API ドキュメントを参照してください。

setIssuers および setIssuerNames メソッドは、issuerNames の条件を設定します。

        public void setIssuers(Collection<X500Principal> issuers)
        public void setIssuerNames(Collection<?> names)

CRL にある発行者の識別名は、指定された識別名の少なくとも 1 つと一致する必要があります。X500Principal を使用する識別名の表現は型定義が適切で効率的なため、setIssuers メソッドをお勧めします。setIssuerNames メソッドの場合、names 引数の各エントリは、String またはバイト配列 (それぞれ、RFC 2253 または ASN.1 DER エンコード形式の名前を表す) のどちらかです。null の場合、発行者の識別名は問われません。

setMinCRLNumber および setMaxCRLNumber メソッドは、minCRLNumber および maxCRLNumber の条件を設定します。

        public void setMinCRLNumber(BigInteger minCRL)
        public void setMaxCRLNumber(BigInteger maxCRL)

CRL には、CRL Number 拡張機能が必要です。この拡張機能は、setMinCRLNumber メソッドが呼び出された場合に指定された値以上になり、setMaxCRLNumber メソッドが呼び出された場合に指定された値以下になる値を持ちます。これらのメソッドの 1 つに渡された値が null の場合、対応するチェックは行われません。

setDateAndTime メソッドは、dateAndTime の条件を設定します。

        public void setDateAndTime(Date dateAndTime)

指定された日付は、CRL の thisUpdate コンポーネントの値と同じかまたはそれよりあとで、さらに nextUpdate コンポーネントの値より前である必要があります。null の場合、dateAndTime のチェックは行われません。

setCertificateChecking メソッドは、取り消しステータスがチェックされている証明書を設定します。

        public void setCertificateChecking(X509Certificate cert)

これは、条件ではありません。特定の証明書の取り消しをチェックする際に、CertStore が関連する CRL を検索するのに役立つオプション情報です。null が指定された場合、このようなオプション情報は提供されません。アプリケーションは、特定の証明書の取り消しをチェックする際、常にこのメソッドを呼び出し、CertStore が正しい CRL を検索して無関係な CRL をフィルタすることができるよう、より多くの情報を提供する必要があります。

選択条件の取得

各選択条件の現在の値は、該当する get メソッドを使って取得できます。これらのメソッドの詳細については、X509CRLSelector の API ドキュメントを参照してください。

例

CRL を LDAP リポジトリから取得する X509CRLSelector の生成方法は、X509CertSelector の例と同様です。特定の CA によって発行され、最小の CRL 番号を持つ、現在 (現在の日付および時間) のCRL すべてを取得すると仮定します。まず、X509CRLSelector オブジェクトを生成し、適当なメソッドを呼び出して選択条件を設定します。

        X509CRLSelector xcrls = new X509CRLSelector();
        // select CRLs satisfying current date and time
        xcrls.setDateAndTime(new Date());
        // select CRLs issued by 'O=xyz, C=us'
        xcrls.addIssuerName("O=xyz, C=us");
        // select only CRLs with a CRL number at least '2'
        xcrls.setMinCRLNumber(new BigInteger("2"));

次に、X509CertSelector の例で生成された CertStore オブジェクトの getCRLs メソッドにセレクタを渡します。

        Collection<CRL> crls = cs.getCRLs(xcrls);

PKIX クラス

Java Certification Path API には、RFC 3280 (Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) で定義されている PKIX 証明書パス検証アルゴリズムで使用するためにモデル化された、アルゴリズム固有クラスのセットも含まれます。

TrustAnchor クラス

このクラスは、X.509 証明書パスの検証で信頼できるアンカーとして使用される「もっとも信頼できる CA」を表します。もっとも信頼できる CA には、CA の公開鍵、CA の名前、およびこの鍵を使って検証されるパスのセットに適用される制約が含まれます。これらのパラメータは、信頼できる X509Certificate の形式で、または個別のパラメータとして指定できます。

すべての TrustAnchor オブジェクトは、不変で、スレッドに対して安全です。つまり、単一の (または複数の) TrustAnchor オブジェクト上で、このクラスに定義されたメソッドを複数のスレッドが同時に呼び出しても、悪影響はありません。TrustAnchor オブジェクトは、不変かつスレッドに対して安全でなければならないので、アクセスの調整を心配することなく、オブジェクトをさまざまなコードに渡すことができます。

このクラスは PKIX クラスとして説明されていますが、その他の X.509 証明書パスの検証アルゴリズムで使用されることもあります。

TrustAnchor オブジェクトの生成

TrustAnchor オブジェクトのインスタンスを生成するには、呼び出し側は、信頼できる X509Certificate または公開鍵と識別名のペアとして、「もっとも信頼できる CA」を指定する必要があります。また、呼び出し側はオプションで、初期化の際に検証アルゴリズムが信頼できるアンカーに適用する名前の制約を指定することもできます。PKIX アルゴリズムでは、信頼できるアンカーに適用する名前の制約をサポートする必要がないため、PKIX CertPathValidator または CertPathBuilder は、このパラメータをサポートすることなく例外をスローすることもできます。次のコンストラクタのうちの 1 つを使って、TrustAnchor オブジェクトを生成します。

        public TrustAnchor(X509Certificate trustedCert, 
                byte[] nameConstraints)
        public TrustAnchor(X500Principal caPrincipal, PublicKey pubKey, 
                byte[] nameConstraints)
        public TrustAnchor(String caName, PublicKey pubKey, 
                byte[] nameConstraints)

nameConstraints パラメータは、NameConstraints 拡張機能の ASN.1 DER エンコードを含むバイト配列として指定されます。名前の制約がデコードできない (正しく書式設定されない) 場合、IllegalArgumentException がスローされます。

パラメータ値の取得

次のように、対応する get メソッドを使って、各パラメータを取得できます。

        public final X509Certificate getTrustedCert()
        public final X500Principal getCA()
        public final String getCAName()
        public final PublicKey getCAPublicKey()
        public final byte[] getNameConstraints()

PKIXParameters クラス

CertPathParameters インタフェースを実装するこのクラスは、PKIX 証明書パスの検証アルゴリズムにより定義された入力パラメータのセットを指定します。また、いくつかの有用な追加パラメータも含んでいます。

X.509 CertPath オブジェクトおよび PKIXParameters オブジェクトは、PKIX アルゴリズムを実装している CertPathValidator インスタンスの validate メソッドに引数として渡されます。CertPathValidator は、パラメータを使って、PKIX 証明書パスの検証アルゴリズムを初期化します。

PKIXParameters オブジェクトの生成

PKIXParameters オブジェクトのインスタンスを生成するには、呼び出し側は、PKIX 検証アルゴリズムによる定義に従って「もっとも信頼できる CA」を指定する必要があります。もっとも信頼できる CA は、次のように、2 つのコンストラクタのうちの 1 つを使って指定できます。

        public PKIXParameters(Set<TrustAnchor> trustAnchors) 
            throws InvalidAlgorithmParameterException
        public PKIXParameters(KeyStore keystore)
            throws KeyStoreException, InvalidAlgorithmParameterException

最初のコンストラクタを使用すると、呼び出し側は、もっとも信頼できる CA を TrustAnchor オブジェクトの Set として指定できます。代わりに、呼び出し側は 2 番目のコンストラクタを使って、信頼できる証明書のエントリを含む KeyStore インスタンスを指定できます。その各エントリは、もっとも信頼できる CA とみなされます。

パラメータ値の設定

PKIXParameters オブジェクトを作成すると、呼び出し側は、さまざまなパラメータを設定する (または現在の値を置き換える) ことができます。ここでは、パラメータを設定するためのいくつかのメソッドについて説明します。その他のメソッドの詳細については、PKIXParameters の API ドキュメントを参照してください。

setInitialPolicies メソッドは、PKIX 検証アルゴリズムによって指定されたとおりに、初期ポリシー識別子を設定します。Set の要素は、String として表現されたオブジェクト識別子 (OID) です。initialPolicies パラメータが null であるか、または設定されていない場合、どのポリシーも受入れ可能です。

        public void setInitialPolicies(Set<String> initialPolicies)

setDate メソッドは、パスの妥当性を判定するための時間を設定します。date パラメータが設定されていないか、または null である場合、現在の日付が使用されます。

        public void setDate(Date date)

setPolicyMappingInhibited メソッドは、ポリシーマッピング禁止フラグの値を設定します。指定されていない場合、フラグのデフォルト値は false です。

        public void setPolicyMappingInhibited(boolean val)

setExplicitPolicyRequired メソッドは、明示的なポリシー要求フラグの値を設定します。指定されていない場合、フラグのデフォルト値は false です。

        public void setExplicitPolicyRequired(boolean val)

setAnyPolicyInhibited メソッドは、ポリシー禁止フラグの値を設定します。指定されていない場合、フラグのデフォルト値は false です。

        public void setAnyPolicyInhibited(boolean val)

setTargetCertConstraints メソッドを使用すると、呼び出し側は、ターゲットまたはエンドエンティティーの証明書に制約を設定できます。たとえば、呼び出し側は、ターゲットの証明書に特定の主体名を含むよう指定できます。制約は、CertSelector オブジェクトとして指定されます。selector パラメータが null であるか、または設定されていない場合、ターゲットの証明書に制約は定義されません。

        public void setTargetCertConstraints(CertSelector selector)

setCertStores メソッドを使用すると、呼び出し側は、CertPathValidator の PKIX 実装がパス検証用 CRL を検索するために使用する CertStore オブジェクトの List を指定できます。これにより、CRL の位置を指定する拡張可能なメカニズムが提供されます。setCertStores メソッドは、CertStore オブジェクトの List をパラメータとして取得します。リスト中の最初の CertStore は、後のエントリに優先します。

        public void setCertStores(List<CertStore> stores)

setCertPathCheckers メソッドを使用すると、呼び出し側は、実装に固有の証明書パスのチェッカーを生成することによって PKIX 検証アルゴリズムを拡張できます。たとえば、このメカニズムは、非公開証明書の拡張情報を処理するために使用されます。setCertPathCheckers メソッドは、PKIXCertPathChecker オブジェクト (後述) のリストをパラメータとして取得します。

        public void setCertPathCheckers(List<PKIXCertPathChecker> checkers)

setRevocationEnabled メソッドを使用すると、呼び出し側は取り消しのチェックを無効にできます。取り消しのチェックは、PKIX 検証アルゴリズムに必要なチェックなので、デフォルトでは有効になっています。ただし、PKIX では、取り消しのチェック方法は定義しません。たとえば、実装は CRL または OCSP を使用することがあります。このメソッドを使用すると、呼び出し側は、実装でデフォルトに設定された取り消しチェックメカニズムが適当でない場合に、それを無効にできます。そのあとで、setCertPathCheckers メソッドを呼び出し、代わりとなるメカニズムを実装する PKIXCertPathChecker に渡すことにより、別の取り消しチェックメカニズムを指定できます。

        public void setRevocationEnabled(boolean val)

setPolicyQualifiersRejected メソッドを使用すると、呼び出し側は、ポリシー修飾子の処理を有効または無効に設定できます。PKIXParameters オブジェクトが生成されると、このフラグは true に設定されます。この設定は、ポリシー修飾子を処理するためのもっとも一般的な (かつ簡単な) 方法を反映します。より複雑なポリシーを使用するアプリケーションでは、このフラグを false に設定する必要があります。

        public void setPolicyQualifiersRejected(boolean qualifiersRejected)

パラメータ値の取得

各パラメータの現在の値は、該当する get メソッドを使って取得できます。これらのメソッドの詳細については、PKIXParameters の API ドキュメントを参照してください。

PKIXCertPathValidatorResult クラス

CertPathValidatorResult インタフェースを実装するこのクラスは、PKIX 証明書パスの検証アルゴリズムの結果を表します。 検証アルゴリズムの実行結果である有効なポリシーツリーおよび主体の公開鍵が保持され、それらを返すためのメソッド (getPolicyTree() および getPublicKey()) が含まれます。PKIXCertPathValidatorResult のインスタンスは、PKIX アルゴリズムを実装する CertPathValidator オブジェクトの validate メソッドによって返されます。

このクラスの詳細については、PKIXCertPathValidatorResult の API ドキュメントを参照してください。

PolicyNode インタフェースおよび PolicyQualifierInfo クラス

PKIX 検証アルゴリズムは、証明書ポリシー処理に関連のあるいくつかの出力を定義します。ほとんどのアプリケーションは、これらの出力を使用する必要はありませんが、PKIX 検証を実装しているかまたはアルゴリズムを構築しているプロバイダはすべて、それらの出力をサポートする必要があります。

PolicyNode インタフェースは、PKIX 証明書パス検証が正常に実行されると作成される有効なポリシーツリーのノードを表します。アプリケーションは、PKIXCertPathValidatorResult の getPolicyTree メソッドを使って、有効なポリシーツリーのルートを取得できます。ポリシーツリーの詳細については、「PKIX Certificate and CRL Profile」を参照してください。

PolicyNode の getPolicyQualifiers メソッドは、PolicyQualifierInfo オブジェクトの Set を返します。その各オブジェクトは、このポリシーが適用される適切な証明書の Certificate Policies 拡張情報に含まれるポリシー修飾子を表します。

ほとんどのアプリケーションでは、有効なポリシーツリーおよびポリシー修飾子を調べる必要はありません。PKIXParameters でポリシー関連のパラメータを設定することにより、アプリケーションのポリシー処理目標を実現できます。ただし、有効なポリシーツリーは、より複雑なアプリケーション、特にポリシー修飾子を処理するアプリケーションに利用できます。

これらのクラスの詳細については、PolicyNode および PolicyQualifierInfo の API ドキュメントを参照してください。

PKIX アルゴリズムを使った証明書パスの検証例

ここでは、PKIX 検証アルゴリズムを使った証明書パスの検証の例を取り上げます。例では、ほとんどの例外処理を無視し、信頼できるアンカーの証明書パスおよび公開鍵がすでに生成されているものと仮定します。

まず、次の行のようにして、CertPathValidator を生成します。

    CertPathValidator cpv = CertPathValidator.getInstance("PKIX");

次の手順で、TrustAnchor オブジェクトを生成します。このオブジェクトは、証明書パスの検証にアンカーとして使用されます。この例では、もっとも信頼できる CA は公開鍵および名前 (名前制約は適用されず、null として指定される) として指定されます。

    TrustAnchor anchor = new TrustAnchor("O=xyz,C=us", pubkey, null);

次の手順で、PKIXParameters オブジェクトを生成します。これを使用して、PKIX アルゴリズムで使用されるパラメータを移入します。この例では、コンストラクタに、前の手順で生成した要素 TrustAnchor を 1 つだけ含む Set を渡します。

    PKIXParameters params = new PKIXParameters(Collections.singleton(anchor));

次に、検証アルゴリズムにより使用される制約またはその他のパラメータを持つ、パラメータオブジェクトを移入します。この例では、explicitPolicyRequired フラグを有効にし、初期ポリシー OID のセット (セットの内容は示されない) を指定します。

    // set other PKIX parameters here
    params.setExplicitPolicyRequired(true);
    params.setInitialPolicies(policyIds);

最後の手順は、生成済みの入力パラメータセットを使った証明書パスの検証です。

    try {
        PKIXCertPathValidatorResult result =
            (PKIXCertPathValidatorResult) cpv.validate(certPath, params);
        PolicyNode policyTree = result.getPolicyTree();
        PublicKey subjectPublicKey = result.getPublicKey();
    } catch (CertPathValidatorException cpve) {
        System.out.println("Validation failure, cert[" 
            + cpve.getIndex() + "] :" + cpve.getMessage());
    }

検証アルゴリズムが成功したら、その検証アルゴリズムで生成されたポリシーツリーおよび主体の公開鍵を、PKIXCertPathValidatorResult の getPolicyTree および getPublicKey メソッドを使って取得します。

そうでない場合は、CertPathValidatorException がスローされるため、呼び出し側は例外をキャッチして、エラーメッセージや障害を引き起こした証明書のインデックスなど、障害のいくつかの詳細について出力できます。

PKIXBuilderParameters クラス

PKIXParameters クラスを拡張するこのクラスは、PKIX 証明書パスの検証アルゴリズムに従って検証される証明書パスを構築する CertPathBuilder に使用されるパラメータのセットを指定します。

PKIXBuilderParameters オブジェクトは、PKIX アルゴリズムを実装した CertPathBuilder インスタンスの build メソッドに引数として渡されます。すべての PKIX CertPathBuilder は、PKIX 証明書パスの検証アルゴリズムに従って検証されている証明書パスを返す必要があります。

PKIX CertPathBuilder が構築されたパスの検証に使用するメカニズムが、実装の詳細であることに注目してください。たとえば、実装はまず、最低限の検証を行なったパスを構築し、次に PKIXCertPathValidator のインスタンスを使ってパスを完全に検証します。より効率的な実装は、パスの構築中に多くのパスを検証し、検証の障害または行き詰まりが発生した場合には、前の段階に戻ります。

PKIXBuilderParameters オブジェクトの生成

PKIXBuilderParameters オブジェクトの生成は、PKIXParameters オブジェクトの生成と同様です。ただし、PKIXBuilderParameters オブジェクトを生成するときに、呼び出し側は、ターゲットまたはエンドエンティティーの証明書に制約を指定する必要があります。これらの制約は、ターゲットの証明書を探すのに十分な情報を CertPathBuilder に提供する必要があります。制約は、CertSelector オブジェクトとして指定されます。次のコンストラクタのうちの 1 つを使って、PKIXBuilderParameters オブジェクトを生成します。

        public PKIXBuilderParameters(Set<TrustAnchor> trustAnchors, 
                CertSelector targetConstraints)
                throws InvalidAlgorithmParameterException
        public PKIXBuilderParameters(KeyStore keystore, 
                CertSelector targetConstraints) 
                throws KeyStoreException, InvalidAlgorithmParameterException
                                                

パラメータ値の取得/設定

PKIXBuilderParameters クラスは、PKIXParameters クラスで設定できるすべてのパラメータを継承します。さらに、setMaxPathLength メソッドを呼び出して、証明書パス内の最大数の証明書に制限を設定することもできます。

        public void setMaxPathLength(int maxPathLength)

maxPathLength パラメータは、証明書パスに存在できる非自動発行の中間証明書の最大数を指定します。PKIX アルゴリズムを実装している CertPathBuilder インスタンスでは、指定された長さよりも長いパスを構築することはできません。値が 0 の場合、パスは単一の証明書だけを含むことができます。値が -1 の場合、パスの長さは制約を受けません (つまり上限はない)。最大パス長を指定しなかった場合、デフォルトの 5 になります。このメソッドは、呼び出し側の要求を満たすかどうかにかかわりなく、CertPathBuilder が長いパスを構築するのにリソースおよび時間を費やさないようにするために便利です。

パス内の CA 証明書に Basic Constraints 拡張機能が含まれている場合、結果がより短い証明書パスのときは常に、拡張機能の pathLenConstraint コンポーネントの値で maxPathLength パラメータの値をオーバーライドします。また、対応する getMaxPathLength メソッドにより、このパラメータを取得することもできます。

        public int getMaxPathLength()

また、PKIXParameters クラスから継承された setCertStores メソッドは、通常、CertPathBuilder の PKIX 実装によって、パスを検証するための CRL の検索だけでなく、パスを構築するための証明書の検索にも使用されます。これにより、証明書および CRL の位置を指定する拡張可能なメカニズムが提供されます。

PKIXCertPathBuilderResult クラス

PKIXCertPathValidatorResult クラスを拡張し、CertPathBuilderResult インタフェースを実装するこのクラスは、PKIX 証明書パス構築アルゴリズムの成功結果を表します。 PKIXCertPathBuilderResult のインスタンスは、PKIX アルゴリズムを実装する CertPathBuilder オブジェクトの build メソッドによって返されます。

PKIXCertPathBuilderResult インスタンスの getCertPath メソッドは、常に PKIX 証明書パスの検証アルゴリズムを使って検証された CertPath オブジェクトを返します。返された CertPath オブジェクトには、パスの固定に使用されていたもっとも信頼できる CA 証明書が含まれません。代わりに、getTrustAnchor メソッドを使って、もっとも信頼できる CA の Certificate を取得します。

このクラスの詳細については、PKIXCertPathBuilderResult の API ドキュメントを参照してください。

PKIX アルゴリズムを使った証明書パスの構築例

これは、PKIX アルゴリズムに従って検証される証明書パスの構築例です。例外処理、および CertStore の移入用に信頼できるアンカーおよび証明書を生成する場合など、除外されている詳細もあります。

まず、次の例にあるように、CertPathBuilder を生成します。

    CertPathBuilder cpb = CertPathBuilder.getInstance("PKIX");

この呼び出しは、PKIX アルゴリズムに従って検証されるパスを返す CertPathBuilder オブジェクトを生成します。

次の手順では、PKIXBuilderParameters オブジェクトを生成します。これは、CertPathBuilder により使用される PKIX パラメータの移入に使用されます。

    // Create parameters object, passing it a Set of
    // trust anchors for anchoring the path
    // and a target subject DN.
    X509CertSelector targetConstraints = new X509CertSelector();
    targetConstraints.setSubject("CN=alice,O=xyz,C=us");
    PKIXBuilderParameters params = 
        new PKIXBuilderParameters(trustAnchors, targetConstraints);

次の手順では、CertPathBuilder が証明書および CRL の検索に使用する CertStore を指定します。この例では、証明書および CRL を使用して Collection CertStore を移入します。

    CollectionCertStoreParameters ccsp = 
        new CollectionCertStoreParameters(certsAndCrls);
    CertStore store = CertStore.getInstance("Collection", ccsp);
    params.addCertStore(store);

次の手順では、生成済みの入力パラメータセットを使って証明書パスを構築します。

    try {
        PKIXCertPathBuilderResult result = 
            (PKIXCertPathBuilderResult) cpb.build(params);
        CertPath cp = result.getCertPath();
    } catch (CertPathBuilderException cpbe) {
        System.out.println("build failed: " + cpbe.getMessage());
    }

CertPathBuilder は、指定されたパラメータを満たすパスを構築できない場合、CertPathBuilderException をスローします。そうでない場合、検証された証明書パスは、getCertPath メソッドを使って PKIXCertPathBuilderResult から取得できます。

PKIXCertPathChecker クラス

このセクションでは、ユーザーが PIKX CertPathValidator または CertPathBuilder 実装を拡張できるようにする強力なクラスを説明します。これは、ほとんどのユーザーは理解する必要のない高度な機能です。ただし、PKIX サービスプロバイダを実装している方は、このセクションをお読み下さい。

PKIXCertPathChecker クラスは、X.509 証明書で 1 つ以上のチェックを実行する抽象クラスです。開発者は、実行時に PKIX CertPathValidator または CertPathBuilder 実装を動的に拡張する必要がある場合、PKIXCertPathChecker クラスの固定実装を作成する必要があります。PKIXCertPathChecker 実装が役立つ例のいくつかを次に示します。

PKIXParameters クラスの setCertPathCheckers メソッドを使用すると、ユーザーは PKIXCertPathChecker オブジェクトの List を PKIX CertPathValidator または CertPathBuilder 実装に渡すことができます。各 PKIXCertPathChecker オブジェクトは、PKIX CertPathValidator または CertPathBuilder 実装によって処理される証明書ごとに、順次呼び出されます。

PKIXCertPathChecker オブジェクトの生成および使用

PKIXCertPathChecker クラスには、public コンストラクタはありません。PKIXCertPathChecker のインスタンスの生成は実装に固有の問題なので、あえてこのようになっています。たとえば、証明書の取り消しステータスのチェックに OCSP を使用する PKIXCertPathChecker 実装のコンストラクタは、OCSP サーバーのホスト名およびポートを要求できます。

        PKIXCertPathChecker checker = new OCSPChecker("ocsp.sun.com", 1321);

チェッカーのインスタンスが生成されると、PKIXParameters クラスの addCertPathChecker メソッドを使って、パラメータとして追加できます。

        params.addCertPathChecker(checker);

また、チェッカーの List は、PKIXParameters クラスの setCertPathCheckers メソッドを使って追加できます。

PKIXCertPathChecker オブジェクトの実装

PKIXCertPathChecker クラスは、抽象クラスです。このクラスには 4 つのメソッド (check、getSupportedExtensions、init、および isForwardCheckingSupported) があり、すべての固定サブクラスはこれらを実装する必要があります。

PKIXCertPathChecker の実装は、簡単な場合と複雑な場合があります。PKIXCertPathChecker 実装には、状態のない場合と状態のある場合があります。状態のない実装では、check メソッドの連続する呼び出しの間で、状態が維持されません。たとえば、特定のポリシー修飾子を含む各証明書を確認する PKIXCertPathChecker は、状態がありません。それに対して、状態のある実装では、check メソッドの連続する呼び出しの間で、状態を維持します。通常、状態のある実装の check メソッドは、証明書パス内の以前の証明書の内容に依存します。たとえば、NameConstraints 拡張情報を処理する PKIXCertPathChecker は、状態があります。

また、PKIXCertPathChecker に提供される (渡される) サービスプロバイダ実装によって処理される証明書の順序は、実装に状態がある場合は特に重要です。サービスプロバイダが使用するアルゴリズムによっては、証明書は、逆方向または順方向に渡されます。逆方向とは、証明書がもっとも信頼できる CA (存在する場合) からターゲットの主体へと順序づけられていることを意味します。それに対して順方向とは、証明書がターゲットの主体からもっとも信頼できる CA へと順序づけられていることを意味します。PKIXCertPathChecker 実装には、連続した証明書の処理方法を理解できるようにするため、順序を知らせる必要があります。

PKIXCertPathChecker オブジェクトの初期化

init メソッドは、チェッカーの内部状態を初期化します。

        public abstract void init(boolean forward)

すべての状態がある実装は、チェッカーの内部状態をクリアまたは初期化する必要があります。こうすれば、サービスプロバイダ実装は、初期化されていない状態のチェッカーを呼び出すことができません。また、状態のあるチェッカーは、インスタンスを再度生成しなくても、以降の操作でそれを再利用できます。forward パラメータは、PKIXCertPathChecker に渡される証明書の順序を示します。forward が true である場合、証明書はターゲットから信頼できるアンカーに渡され、false の場合、信頼できるアンカーからターゲットに渡されます。

順方向のチェック

isForwardCheckingSupported メソッドは、PKIXCertPathChecker が順方向のチェックをサポートするかどうかを示す boolean を返します。

        public abstract boolean isForwardCheckingSupported()

すべての PKIXCertPathChecker 実装は逆方向のチェックをサポートしている必要があります。PKIXCertPathChecker 実装は順方向のチェックをサポートできます。

順方向のチェックをサポートすると、パスが構築時にチェックされるので、順方向に構築する CertPathBuilder の効率が向上します。ただし、状態のある PKIXCertPathChecker では、順方向チェックのサポートが難しいか、または不可能な場合があります。

サポートされる拡張情報

getSupportedExtensions メソッドは、PKIXCertPathChecker 実装がサポートする (つまり、認識し、処理できる) X.509 拡張情報の不変の OID String の Set を返します。

        public abstract Set<String> getSupportedExtensions()

拡張情報が処理されない場合、メソッドは null を返す必要があります。すべての実装は、check メソッドが処理する OID String の Set を返す必要があります。

CertPathBuilder は、この情報を使って、順方向のチェックをサポートしない PKIXCertPathChecker で順方向の構築を実行しているときでも、認識されない重要な拡張情報を含む証明書を識別できます。

チェックの実行

次のメソッドは、証明書に対するチェックを実行します。

        public abstract void 
                check(Certificate cert, Collection<String> unresolvedCritExts)
                throws CertPathValidatorException

unresolvedCritExts パラメータには、OID のコレクションが String として含まれています。これらの OID は、まだ証明書パスの検証アルゴリズムで解釈されていない証明書内の重要な拡張情報のセットを表します。check メソッドの固定実装は、unresolvedCrit.Exts パラメータから処理するすべての重要な拡張情報を削除する必要があります。

証明書がチェックに合格しない場合、CertPathValidatorException がスローされる必要があります。

PKIXCertPathChecker の複製

PKIXCertPathChecker クラスは、Cloneable インタフェースを実装します。すべての状態のある PKIXCertPathChecker 実装は、必要に応じて、clone メソッドをオーバーライドする必要があります。clone メソッドのデフォルトの実装は、Object.clone メソッドを呼び出します。このメソッドは、元のオブジェクトのすべてのフィールドを新しいオブジェクトにコピーすることにより、簡単な複製を実行します。状態のない実装は、clone メソッドをオーバーライドしません。ただし、すべての状態のある実装は、デフォルトの clone メソッドが正しいことを確認し、必要に応じてそれをオーバーライドする必要があります。たとえば、配列内の状態を格納する PKIXCertPathChecker は、配列を参照するだけではなく、配列のコピーを作成するため、clone メソッドをオーバーライドする必要があります。

PKIXCertPathChecker オブジェクトが Cloneable である理由は、潜在的な証明書パスが行き詰まったり、障害ポイントに到達した場合、CertPathBuilder 実装が効率的に戻り、別のパスを試すことができるようにするためです。この場合、実装は、複製されたオブジェクトを復元することにより、以前のパスの検証状態を復元できます。

例

これは、状態のない PKIXCertPathChecker 実装の例です。非公開の拡張情報が証明書に存在するかどうかをチェックし、いくつかの規則に従って処理します。

        import java.security.cert.Certificate;
        import java.security.cert.X509Certificate;
        import java.util.Collection;
        import java.util.Collections;
        import java.util.Set;
        import java.security.cert.PKIXCertPathChecker;
        import java.security.cert.CertPathValidatorException;

        public class MyChecker extends PKIXCertPathChecker {
            private static Set supportedExtensions =
                Collections.singleton("2.16.840.1.113730.1.1");

            /*
             * Initialize checker
             */
            public void init(boolean forward) 
                throws CertPathValidatorException {
                // nothing to initialize
            }

            public Set getSupportedExtensions() {        
                return supportedExtensions;
            }

            public boolean isForwardCheckingSupported() {
                return true;
            }

            /*
             * Check certificate for presence of Netscape's
             * private extension
             * with OID "2.16.840.1.113730.1.1"
             */
            public void check(Certificate cert, 
                              Collection unresolvedCritExts)
                throws CertPathValidatorException 
            {
                X509Certificate xcert = (X509Certificate) cert;
                byte[] ext = 
                    xcert.getExtensionValue("2.16.840.1.113730.1.1");
                if (ext == null)
                    return;

                //
              // process private extension according to some 
                // rules - if check fails, throw a 
                // CertPathValidatorException ...
                // {insert code here}

                // remove extension from collection of unresolved 
                // extensions (if it exists)
                if (unresolvedCritExts != null)
                    unresolvedCritExts.remove("2.16.840.1.113730.1.1");
            }
        }

PKIX サービスプロバイダ実装による PKIXCertPathChecker の使用方法

各 PKIXCertPathChecker オブジェクトは、構築または検証アルゴリズムを開始する前に、サービスプロバイダ実装によって初期化される必要があります。次に例を示します。

        List<PKIXCertPathChecker> checkers = params.getCertPathCheckers();
        for (PKIXCertPathChecker checker : checkers) {
            checker.init(false);
        }

検証する証明書ごとに、サービスプロバイダ実装は各 PKIXCertPathChecker オブジェクトの check メソッドを順に呼び出し、証明書および残りの解釈されていない重要な拡張情報に渡します。

        for (PKIXCertPathChecker checker : checkers) {
            checker.check(cert, unresolvedCritExts);
        }

check のどれかが CertPathValidatorException をスローする場合、CertPathValidator 実装は、検証手順を終了する必要があります。ただし、CertPathBuilder 実装は、単に障害を記録し、引き続きその他の潜在的なパスを探す場合があります。サービスプロバイダ実装は、すべての check が成功した場合、解釈されているすべての重要な拡張情報をチェックします。そうでない場合、検証が失敗したとみなされます。たとえば、

        if (unresolvedCritExts != null &&
            !unresolvedCritExts.isEmpty())
        {
            // note that a CertPathBuilder may have an enclosing
            // try block to catch the exception below and continue on error
            throw new CertPathValidatorException
                ("Unrecognized Critical Extension");
        }

前のセクションで説明したように、CertPathBuilder 実装は、潜在的な証明書パスが行き詰まったり、障害ポイントにおよんだ場合は、戻る必要があります。ここで戻るというのは、パス内の以前の証明書に戻り、その他の潜在的なパスを探すことを意味します。CertPathBuilder 実装がパスの構築中にパスを検証する場合、各 PKIXCertPathChecker の以前の状態を復元する必要があります。これを行うには、各証明書が処理される前に、PKIXCertPathChecker オブジェクトを複製します。次に例を示します。

        /* clone checkers */
        List newList = new ArrayList(checkers);
        ListIterator li = newList.listIterator();
        while (li.hasNext()) {   
            PKIXCertPathChecker checker = (PKIXCertPathChecker) li.next();
            li.set(checker.clone());
        }

証明書パス検証での PKIXCertPathChecker の使用

PKIXCertPathChecker を使用して証明書パス検証をカスタマイズすることは、比較的簡単です。

基本の証明書パス検証

まず、証明書パスを検証するコードを考慮します。

Set<TrustAnchor> trustAnchors = getTrustAnchors();
CertPath cp = getCertPath();

PKIXParameters pkixp = new PKIXParameters(trustAnchors);
pkixp.setRevocationEnabled(false);

CertPathValidator cpv = CertPathValidator.getInstance("PKIX");
PKIXCertPathValidatorResult pcpvr =
    (PKIXCertPathValidatorResult)cpv.validate(cp, pkixp);

検証が失敗した場合、validate() メソッドは例外をスローします。

基本の手順は次のとおりです。

1. CA ルート証明書および検証する証明書パスを取得します。
2. 信頼できるアンカーで PKIXParameters を作成します。
3. CertPathValidator を使用して、証明書パスを検証します。

この例では、getTrustAnchors() および getCertPath() が CA ルート証明書と証明書パスを取得するメソッドです。

この例の getTrustAnchors() メソッドは、検証に使用したい CA ルート証明書を表す TrustAnchor の Set を返す必要があります。これは、ファイルから単一の CA ルート証明書をロードする 1 つの簡単な実装です。

public Set<TrustAnchor> getTrustAnchors()
    throws IOException, CertificateException {
  InputStream in = new FileInputStream("x509_ca-certificate.cer");
  CertificateFactory cf = CertificateFactory.getInstance("X.509");
  X509Certificate c = (X509Certificate)cf.generateCertificate(in);
  in.close();

  TrustAnchor anchor = new TrustAnchor(c, null);
  return Collections.singleton(anchor);
}

同様に、これは、ファイルから証明書パスをロードする getCertPath() の簡単な実装です。

public CertPath getCertPath() throws IOException, CertificateException {
  CertificateFactory cf = CertificateFactory.getInstance("X.509");

  InputStream in = new FileInputStream("certpath.pkcs7");
  CertPath cp = cf.generateCertPath(in, "PKCS7");
  in.close();
  
  return cp;
}

PKCS#7 では、ファイル内の証明書の特定の順番を必要としないため、このコードは、証明書が検証されるエンティティーから始まり、CA ルートに戻る順番になっている場合の証明書パス検証にのみ有効です。証明書の順番が正しくない場合、追加の処理が必要です。CertificateFactory には、この種類の処理に使用できる Collection を受け付ける generateCertPath() メソッドがあります。

PKIXCertPathChecker への追加

証明書パス検証をカスタマイズするには、次のように PKIXCertPathChecker を追加します。この例では、SimpleChecker は PKIXCertPathChecker サブクラスです。新しい行を太字で示します。

Set<TrustAnchor> trustAnchors = getTrustAnchors();
CertPath cp = getCertPath();

PKIXParameters pkixp = new PKIXParameters(trustAnchors);
pkixp.setRevocationEnabled(false);

SimpleChecker sc = new SimpleChecker();
pkixp.addCertPathChecker(sc);

CertPathValidator cpv = CertPathValidator.getInstance("PKIX");
PKIXCertPathValidatorResult pcpvr =
    (PKIXCertPathValidatorResult)cpv.validate(cp, pkixp);

SimpleChecker は PKIXCertPathChecker の基本的なサブクラスです。その check() メソッドは、検証される証明書パス内のすべての証明書に対して呼び出されます。SimpleChecker は AlgorithmConstraints 実装を使用して、各証明書の署名アルゴリズムと公開鍵を調査します。

import java.security.AlgorithmConstraints;
import java.security.CryptoPrimitive;
import java.security.Key;
import java.security.cert.*;
import java.util.*;

public class SimpleChecker extends PKIXCertPathChecker {
  private final static Set<CryptoPrimitive> SIGNATURE_PRIMITIVE_SET =
      EnumSet.of(CryptoPrimitive.SIGNATURE);
  
  public void init(boolean forward) throws CertPathValidatorException {}
  
  public boolean isForwardCheckingSupported() { return true; }
  
  public Set<String> getSupportedExtensions() { return null; }
  
  public void check(Certificate cert,
      Collection<String> unresolvedCritExts)
      throws CertPathValidatorException {
    X509Certificate c = (X509Certificate)cert;
    String sa = c.getSigAlgName();
    Key key = c.getPublicKey();
    
    AlgorithmConstraints constraints = new SimpleConstraints();
    
    if (constraints.permits(SIGNATURE_PRIMITIVE_SET, sa, null) == false)
      throw new CertPathValidatorException("Forbidden algorithm: " + sa);

    if (constraints.permits(SIGNATURE_PRIMITIVE_SET, key) == false)
      throw new CertPathValidatorException("Forbidden key: " + key);
  }
}

最後に、SimpleConstraints は、RSA アルゴリズムのみを許可し、2048 ビット以上の鍵を必要とするやや厳しい AlgorithmConstraints 実装です。

import java.security.AlgorithmConstraints;
import java.security.AlgorithmParameters;
import java.security.CryptoPrimitive;
import java.security.Key;
import java.security.interfaces.RSAKey;
import java.util.Set;

public class SimpleConstraints implements AlgorithmConstraints {
  public boolean permits(Set<CryptoPrimitive> primitives,
      String algorithm, AlgorithmParameters parameters) {
    return permits(primitives, algorithm, null, parameters);
  }

  public boolean permits(Set<CryptoPrimitive> primitives, Key key) {
    return permits(primitives, null, key, null);
  }
  
  public boolean permits(Set<CryptoPrimitive> primitives,
      String algorithm, Key key, AlgorithmParameters parameters) {
    if (algorithm == null) algorithm = key.getAlgorithm();
    
    if (algorithm.indexOf("RSA") == -1) return false;
    
    if (key != null) {
      RSAKey rsaKey = (RSAKey)key;
      int size = rsaKey.getModulus().bitLength();
      if (size < 2048) return false;
    }

    return true;
  }
}

サービスプロバイダの実装

このセクションは、証明書パスサービス実装を提供する独自のプロバイダパッケージを作成する上級プログラマを対象としています。このセクションの記述は、次のドキュメントをすでに読んでいることを前提としています。Java 暗号化アーキテクチャーのプロバイダの実装方法

Java Certification Path API では、次のエンジンクラスが定義されています。

• CertPathValidator - 証明書パスの検証に使用される

• CertPathBuilder - 証明書パスの構築に使用される

• CertStore - リポジトリから証明書と CRL を取得するために使用される

さらに、既存の CertificateFactory エンジンクラスは、JDK, v 1.4 で拡張されており、証明書パスの生成をサポートします。

エンジンクラスが提供するアプリケーションインタフェースは、「Service Provider Interface」(SPI) として実装されます。各 SPI クラスの名前は、対応するエンジンクラス名のあとに「Spi」を追加した名前になります。たとえば、CertPathValidator エンジンクラスに対応する SPI クラスは、CertPathValidatorSpi クラスです。各 SPI クラスは、抽象クラスです。個々のアルゴリズムまたは型について、特定の型のサービスの実装を提供するには、プロバイダは対応する SPI クラスをサブクラス化して、すべての抽象メソッドの実装を提供する必要があります。たとえば、CertStore クラスは、証明書および CRL をリポジトリから取得する機能を利用できるようにします。CertStoreSpi サブクラスで提供される実際の実装は、LDAP など、特定の型の証明書リポジトリのための実装です。

プロバイダの実装および統合までのステップ

開発者は、「Java 暗号化アーキテクチャー用プロバイダの実装方法」ドキュメントに示されたステップに従う必要があります。ここでは、特定のステップを補足するいくつかの付加的な規則について説明します。

put("CertPathValidator.PKIX", "sun.security.provider.certpath.PKIXCertPathValidator")

put("CertPathValidator.PKIX ValidationAlgorithm", "RFC3280");

サービスの相互依存性

ここでは、証明書パスサービス実装におけるアルゴリズムの相互依存の一般的な種類を示します。

証明書パスパラメータ仕様のインタフェース

Certification Path API には、パラメータの透過的な仕様を表す CertPathParameters および CertStoreParameters という 2 つのインタフェースが含まれています。

CertPathParameters インタフェースには、PKIXParameters および PKIXBuilderParameters クラスという 2 つの実装が含まれています。PKIX 証明書パスの検証およびアルゴリズムパラメータを使って作業する場合、これらのクラスを利用できます。アルゴリズムごとにパラメータが必要な場合は、そのアルゴリズムに独自の CertPathParameters 実装を提供する必要があります。

CertStoreParameters インタフェースには、LDAPCertStoreParameters および CollectionCertStoreParameters クラスという 2 つの実装が含まれています。これらのクラスは、それぞれ LDAP および Collection CertStore 実装で別々に使用されます。リポジトリ型ごとにパラメータが必要な場合は、その型に独自の CertStoreParameters 実装を提供する必要があります。

CertPathParameters および CertStoreParameters インタフェースは、それぞれ実装がオーバーライドする必要のある clone メソッドを定義します。標準的な実装は、オブジェクトの「ディープ」コピーを実行し、それ以降コピーに対して行われる変更が元のオブジェクトに影響しないように (逆の場合も同様) します。ただし、これは、CertStoreParameters の実装の絶対的な要件ではありません。しかし、CertStoreParameters に含まれるパラメータへの参照を保持する必要があるアプリケーションでは、clone のシャローコピー実装の方が適切です。たとえば、CertStore.getInstance は指定された CertStoreParamter の複製を作成するので、アプリケーションはガベージコレクションメカニズムを待つのではなく、clone のシャローコピーを使って特定の CertStore 初期化パラメータのリソースへの参照を維持し、あとでリリースできます。CertStore がその他のスレッドによって使用されていることがあるので、この操作は細心の注意を払って行う必要があります。

証明書パスの結果の仕様インタフェース

Certification Path API には、結果の透過的な仕様を表す CertPathValidatorResult および CertPathBuilderResult という 2 つのインタフェースが含まれています。

各インタフェースの実装には、それぞれ PKIXCertPathValidatorResult および PKIXCertPathBuilderResult クラスが含まれます。PKIX 証明書パスサービスプロバイダを実装する場合、これらのクラスを使用できます。アルゴリズムごとに証明書パスの結果が必要な場合は、そのアルゴリズムに独自の CertPathValidatorResult または CertPathBuilderResult 実装を提供する必要があります。

CertPathValidator または CertPathBuilder の PKIX 実装では、デバッグトレースなど、PKIXCertPathValidatorResult または PKIXCertPathBuilderResult の追加情報を格納することが有用な場合があります。この場合、実装は、関連情報を取得するメソッドを持つ、適切な結果クラスのサブクラスを実装する必要があります。これらのクラスは、プロバイダクラスとともに (たとえば、プロバイダ JAR ファイルの一部として) 提供される必要があります。

証明書パスの例外クラス

TrustAnchor クラス

前述のように、PKIX CertPathValidator または CertPathBuilder は、TrustAnchor クラスの nameConstraints パラメータをサポートする必要はありません。実装は、このパラメータがサポートされていない場合、InvalidAlgorithmParameterException をスローする必要があります。

署名タイムスタンプのサポート

はじめに

このセクションでは、署名タイムスタンプをサポートするために追加された拡張機能について説明します。

Java SE 5.0 より前では、jarsigner が生成した署名には、署名がいつ生成されたかについての情報が含まれていませんでした。その他の情報が入手できないため、システムやデプロイヤ (Java Plug-in のユーザーも含む) は署名された JAR ファイルの妥当性を、署名対象の証明書の妥当性を基準として評価していました。署名証明書の有効期限が切れると、署名および JAR ファイルの有効期限も切れたと認識されます。署名証明書は一般には 1 年単位で期限が切れるので、顧客は配備された JAR ファイルに毎年再署名しなければならないという重大な問題が発生します。

Java SE 5.0 以降では、jarsigner はタイムスタンプを含む署名を生成するので、システムやデプロイヤ (Java Plug-in を含む) は JAR ファイルが署名証明書の有効期間中に署名されたかどうかをチェックできます。さらに、Java SE 5.0 で追加された API を使用して、アプリケーションはタイムスタンプ情報を取得できます。

次の署名時間の拡張機能および追加機能がサポートされています。

• Jarsigner の拡張機能
• Java Plug-in の拡張機能
• API の拡張機能

Jarsigner の拡張機能

jarsigner ツールは、JAR ファイルの署名時に署名タイムスタンプを生成して保存できるようになりました。さらに、jarsigner は代替署名メカニズムをサポートします。これは任意の動作で、次に説明するオプションを使用して、署名時にユーザーが制御します。

Jarsigner タイムスタンプオプション

次の jarsigner オプションが署名タイムスタンプをサポートしています。

-tsa url

JAR ファイルの署名時にコマンド行に「"-tsa http://example.tsa.url"」が表示される場合、署名のタイムスタンプが生成されます。URL http://example.tsa.url は、TSA (Time Stamping Authority) の場所を特定します。これは、-tsacert オプションで検出された URL をオーバーライドします。-tsa オプションでは、TSA の公開鍵証明書がキーストアに配置されている必要はありません。

タイムスタンプを生成するために、jarsigner は RFC 3161 で定義されている TSP (Time-Stamp Protocol) を使用して TSA と通信します。成功すると、TSA から返されたタイムスタンプトークンが署名ブロックファイルの署名とともに保存されます。

-tsacert alias

JAR ファイルの署名時にコマンド行に「"-tsacert alias"」が表示される場合、署名のタイムスタンプが生成されます。alias は、キーストア内の現在有効な TSA の公開鍵証明書を特定します。エントリの証明書で、TSA の場所を特定する URL を含む Subject Information Access 拡張機能が確認されます。

-tsacert を使用する場合は、TSA の公開鍵証明書がキーストアに配置されている必要があります。

代替署名オプション

代替署名メカニズムの指定

-altsigner class

代替署名メカニズムを使用することを指定します。完全修飾クラス名は、com.sun.jarsigner.ContentSigner abstract class を拡張するクラスファイルを特定します。このクラスファイルへのパスは、-altsignerpath オプションによって定義されます。-altsigner オプションが使用されている場合、jarsigner は指定されたクラスが提供する署名メカニズムを使用します。それ以外の場合、jarsigner はデフォルトの署名メカニズムを使用します。

たとえば、com.sun.sun.jarsigner.AuthSigner というクラスが提供する署名メカニズムを使用するには、jarsigner オプション「"-altsigner com.sun.jarsigner.AuthSigner"」を使用します。

代替署名メカニズムへのパスの指定

-altsignerpath classpathlist

クラスファイル (クラスファイル名は前述のように -altsigner オプションで指定される) およびそれが依存する JAR ファイルへのパスを指定します。クラスファイルが JAR ファイル内にある場合、次の例のように JAR ファイルへのパスが指定されます。

絶対パスまたは現在のディレクトリからの相対パスを指定できます。classpathlist に複数のパスまたは JAR ファイルを含める場合、Solaris ではコロン (:)、Windows ではセミコロン (;) を使用して区切ります。目的のクラスがすでに検索パス内にある場合は、このオプションは不要です。

クラスファイルを含む JAR ファイルへのパスを指定する例を示します。

    -altsignerpath /home/user/lib/authsigner.jar

JAR ファイル名が含まれていることに注意してください。

クラスファイルを含む JAR ファイルへのパスを指定する例を示します。

    -altsignerpath /home/user/classes/com/sun/tools/jarsigner/

JAR ファイル名は含まれていないことに注意してください。

Java Plug-in の拡張機能

Java SE 5.0 では、Java Plug-in は JAR ファイルの検証中に署名タイムスタンプ (存在する場合) をチェックするように拡張されました。署名タイムスタンプによって署名が有効期限内または取り消し日付前に生成されたことが確認できる場合は、署名済み jar の検証中に期限切れまたは取り消された証明書が見つかっても、Java Plug-in はダイアログを表示しなくなりました。

Plug-in が署名タイムスタンプを含む JAR ファイルを検証しているときに、Plug-in のキーストアまたは証明書ストアから TSA の証明書を取得できる必要があります。

署名にタイムスタンプが含まれていない場合は、Plug-in の動作は 1.4.x と同じになります。

API の拡張機能

セキュリティーおよび JAR API が拡張され、アプリケーションがタイムスタンプ情報にアクセスできるようになりました。

新しい 2 つのクラスが java.security パッケージに追加されました。これらのクラスは、署名者に関連付けられた情報を保持する CodeSigner と、署名タイムスタンプに関連付けられた情報を表す Timestamp です。

java.security.CodeSource クラスおよび java.util.jar.JarEntry クラスに新しいメソッドが追加され、新しいオプション情報にアクセスできるようになりました。

付録 A: 標準名

Java Certification Path API では、証明書パスの検証アルゴリズム、エンコードおよび証明書ストレージの型について、標準名のセットを必要とし、それらを使用します。以前にこの付録 A およびその他のセキュリティー仕様 (JCA/JSSE/など) にあった標準名は、標準名のドキュメントにまとめられました。特定のプロバイダの情報は、Sun プロバイダドキュメントにあります。

サービスプロバイダは、標準名のドキュメントに記述されていない独自のアルゴリズムまたは非標準のアルゴリズムに新しい名前を定義することもできます。ただし、名前の衝突を防止するため、プロバイダの組織のインターネットドメイン名を逆にしたもの (com.sun.MyCertPathValidator など) を名前の前に付けることをお勧めします。

付録 B: 「SUN」プロバイダ

「SUN」プロバイダは、次の標準アルゴリズム、型、およびエンコードをサポートしています。

• CertificateFactory: X.509 CertPath 型と PKCS7 および PkiPath エンコード
• CertPathValidator: PKIX アルゴリズム
• CertPathBuilder: PKIX アルゴリズム
• CertStore: LDAP および Collection CertStore 型

CertificateFactory

CertPathValidator

「SUN」プロバイダは、CertPathValidator エンジンクラスの PKIX 実装を提供します。この実装は、X 509 型の CertPath を検証し、RFC 3280: PKIX Certificate and CRL Profile に定義されている証明書パス検証アルゴリズムを実装します。この実装では、ValidationAlgorithm サービス属性は「RFC3280」に設定されます。

Java SE 7 リリースでは、「SUN」プロバイダで、セキュリティープロパティーを使用して、弱い暗号化アルゴリズムを無効にできます。jdk.certpath.disabledAlgorithms プロパティーは、証明書パス検証に適用される無効にされるアルゴリズムのリストです。

JDK 7u40 リリース以降では、jdk.certpath.disabledAlgorithms のデフォルト値は次のとおりです。

    jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

これは、証明書の検証に、MD2 を含む署名アルゴリズムを使用しないことを意味します。また、1024 ビット未満の RSA 鍵サイズによる証明書の使用は制限されます。付録 D に jdk.certpath.disabledAlgorithms の値の例があります。

PKIX 証明書と CRL プロファイルには、多くのオプション機能があります。「SUN」プロバイダは、ポリシーマッピング、Authority Information Access および CRL 配布ポイント証明書拡張機能、Issuing Destribution Point CRL 拡張機能、原因コードおよび Certificate Issuer CRL エントリ拡張機能のサポートを実装しています。Freshest CRL または Subject Information Access 証明書拡張機能のサポートは実装していません。また、Freshest CRL および Delta CRL Indicator CRL 拡張機能と Invalidity Date および Hold Instruction Code CRL エントリ拡張機能のサポートは含まれません。

実装は、PKIX 証明書と CRL プロファイルのセクション 6.3 に準拠している CRL 取り消しチェックメカニズムをサポートします。OCSP (RFC 2560) も、現在、組み込みの取り消しチェックメカニズムとしてサポートされています。実装と構成および CRL とどのように連携するかについての詳細は、付録 C を参照してください。

この実装は、TrustAnchor クラスの nameConstraints パラメータをサポートしないため、このパラメータが指定されると、validate メソッドにより InvalidAlgorithmParameterException がスローされます。

CertPathBuilder

この実装では、PKIXBuilderParameters オブジェクトの targetConstraints パラメータが X509CertSelector のインスタンスで、主体の条件が null 以外の値に設定されていることが必要です。そうでない場合、build メソッドにより InvalidAlgorithmParameterException がスローされます。

実装は、深さ優先アルゴリズムを使って、順方向に CertPath オブジェクトを構築します。潜在的なパスが無効であるか、または PKIXBuilderParameters maxPathLength パラメータを超えていると判定されると、前の状態に戻って代替パスを試みます。

パスの検証は、CertPathValidator 実装と同じ方法で実行されます。実装は、プロセスの早い段階で無効なパスを削除するために、パスの構築時にほとんどのパスを検証します。順方向に順序付けされている証明書で実行できない検証チェックは延期され、パスが構築されてから (アプリケーションに返される前に) そのパス上で実行されます。

CertPathValidator と同様に、jdk.certpath.disabledAlgorithms セキュリティープロパティーを使用して、安全とみなされない暗号化アルゴリズムを除外できます。

2 つ以上の潜在的な証明書が検出され、指定された制約を満たすパスが見つかる可能性がある場合、実装は、次の条件を使って、証明書の優先順位を設定します (次の例では、TrustAnchor の識別名 "ou=D,ou=C,o=B,c=A" が指定されていると仮定)。

1. 証明書の発行者 DN が、指定された TrustAnchor のうち 1 つの DN と一致 (例: issuerDN = "ou=D,ou=C,o=B,c=A")。
2. 証明書の発行者 DN が TrustAnchor のうち 1 つの DN の子孫で、アンカーに近いほうから順に順序付けられている (例: issuerDN = "ou=E,ou=D,ou=C,o=B,c=A")。
3. 証明書の発行者 DN が TrustAnchor のうち 1 つの DN の祖先で、アンカーに近いほうから順に順序付けられている (例: issuerDN = "ou=C,o=B,c=A")。
4. 証明書の発行者 DN が TrustAnchor のうち 1 つの同じ名前空間内にあり、アンカーに近いほうから順に順序付けられている (例: issuerDN = "ou=G,ou=C,o=B,c=A")。
5. 証明書の発行者 DN が、証明書の主体 DN の祖先で、主体に近いほうから順に順序付けられている。

この実装は、このリリースの「SUN」プロバイダに含まれる LDAP および Collection CertStore 実装でテストされています。

デバッグのサポートは、java.security.debug プロパティーを certpath に設定すると有効になります。例:

       java -Djava.security.debug=certpath BuildCertPath

CertStore

Collection CertStore

証明書および CRL は、特定の順序で返されることはなく、複製を含みません。

LDAP CertStore

実装は、主体の値、発行者、および X509CertSelector で指定されている basicConstraints 選択条件によって、証明書を別の位置からフェッチします。実装は、次の操作をできるだけ多く実行します。

1. Subject non-null, basicConstraints <= -1

   主体 DN の「userCertificate」属性で証明書を検索します。

2. Subject non-null, basicConstraints >= -1

   主体 DN の「crossCertificatePair」属性の順方向の要素内にあり、かつ主体の「caCertificate」属性内にある証明書を検索します。

3. Issuer non-null, basicConstraints >= -1

   発行者 DN の「crossCertificatePair」属性の逆方向要素内にあり、かつ発行者 DN の「caCertificate」属性内にある証明書を検索します。

どの場合も、証明書は検索結果のコレクションに追加する前に、X509CertSelector.match() を使ってチェックされます。

上記に指定した条件のどれも当てはまらない場合、提供された条件を使って証明書をフェッチできなかったことを示す例外がスローされます。1 つ以上の条件が適用されたとしても、ディレクトリに証明書がない場合、返される Collection は空のままであることに注意してください。

実装は、X509CRLSelector クラスの setCertificateChecking、addIssuerName、または setIssuerNames メソッドで指定された発行者 DN から CRL をフェッチします。いずれかのメソッドを使って発行者 DN を指定しないと、実装により、指定された基準では CRL をフェッチできなかったことを示す例外がスローされます。それ以外の場合、CRL は次のように検索されます。

最初に、実装により発行者名のリストが作成されます。setCertificateChecking メソッドに証明書が指定されている場合、その証明書の発行者が使用されます。それ以外の場合、addIssuerName または setIssuerNames メソッドで指定された発行者名が使用されます。

次に、発行者名のリストに対して繰り返し処理が行われます。実装は、発行者名ごとに "authorityRevocationList" 属性を検索し、一致する CRL が見つからなかった場合、発行者の "certificateRevocationList" 属性内を検索します。ただし、setCertificateChecking メソッドに指定された証明書から発行者名を取得した場合は例外です。この場合、発行者の「authorityRevocationList」属性に対して、指定された証明書が CA 証明書であるかどうかのチェックが行われるだけになります。

すべての CRL は検索結果のコレクションに追加する前に、X509CRLSelector.match() を使ってチェックされます。

選択基準を満たす CRL が見つからない場合、空の Collection が返されます。

キャッシュ

CRL 配布ポイント拡張機能のサポート

true に設定した場合、Sun の PKIX 実装は、指定される CertStore に加えて証明書の CRL 配布ポイント拡張機能の情報を使用して、CRL を検索します。ただし、配布ポイントが X.500 識別名または ldap、http、または ftp 型の URI である必要があります。

注:ネットワークおよびファイアウォールの設定によっては、ネットワークプロキシサーバーを、ネットワークのドキュメントの記載に従って構成することが必要な場合があります。

Authority Information Access (AIA) 拡張機能のサポート

true に設定した場合、CertPathBuilder の Sun の PKIX 実装は、指定される CertStore に加えて証明書の AIA 拡張機能の情報を使用して、発行する CA 証明書を検索します。ただし、それが ldap、http、または ftp 型の URI である必要があります。

注:ネットワークおよびファイアウォールの設定によっては、ネットワークプロキシサーバーを、ネットワークのドキュメントの記載に従って構成することが必要な場合があります。

付録 C: OCSP (On-Line Certificate Status Protocol) サポート

RFC 2560 に定義された OCSP (On-Line Certificate Status Protocol) のクライアント側のサポートが、JDK 5.0 でサポートされます。OCSP チェックは、次の 5 つのセキュリティープロパティーで制御されます。

ocsp.responderURL=http://ocsp.example.net:80

ocsp.responderCertSubjectName="CN=OCSP Responder, O=XYZ Corp"

ocsp.responderCertIssuerName="CN=Enterprise CA, O=XYZ Corp"

ocsp.responderCertSerialNumber=2A:FF:00

これらのプロパティーは、Java ランタイムの $JAVA_HOME/jre/lib/security/java.security ファイル内で静的に設定されるか、または java.security.Security.setProperty() メソッドを使って動的に設定されます。

デフォルトでは、OCSP チェックは有効ではありません。ocsp.enable プロパティーを「true」に設定すると有効になります。その他のプロパティーは、オプションで使用できます。OCSP チェックは、取り消しチェックも有効になっている場合にのみ有効になります。取り消しチェックは、PKIXParameters.setRevocationEnabled() メソッドを使用して有効にできます。

OCSP チェックは、取り消しチェック中に証明書の取り消しリスト (CRL) と連動して機能します。次は、OCSP と CRL の相互作用のサマリーです。CRL でのフェイルオーバーは、OCSP に問題が発生した場合にかぎり、発生します。OCSP 応答者が、証明書が取り消されたことまたは取り消されていないことを確認した場合は、フェイルオーバーは発生しません。

付録 D: 暗号化アルゴリズムの無効化

jdk.certpath.disabledAlgorithms セキュリティープロパティーには、証明書パスの処理中に使用されない暗号化アルゴリズムのリストが含まれます。正確なプロパティーの構文は、jre/lib/security/java.security に説明されていますが、ここで簡単に要約します。

セキュリティープロパティーには、使用してはいけない暗号化アルゴリズムのリストが含まれます。アルゴリズム名はコンマで区切られています。さらに、鍵サイズの制限を指定することもできます。

たとえば、java.security 内の次の行は、証明書パスの処理に MD2 および DSA アルゴリズムを使用してはいけないことを指定しています。さらに、2048 ビット未満の鍵サイズに対して RSA は無効になります。

jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048