jarsigner ユーティリティは、コード署名証明書が自己署名されない場合に、Netscape SignTool 1.3 によって署名されたファイルを検証できます。注: 公式な Netscape コード署名証明書は、VeriSign から入手できます。これらの証明書は、VeriSign によって発行され、自己署名はされません。
Netscape SignTool 1.3 は、コード署名証明書が自己署名される場合は、証明書を署名ファイルには格納しません。また、署名ファイルが署名者の証明書を含まない場合、jarsigner は署名された JAR ファイルを検証できません。注: SignTool 1.3 自体が生成したコード署名証明書は、テスト用であり、自己署名されたものです。コード署名証明書が自己署名されたテスト用の証明書である場合に、Netscape SignTool 1.3 によって署名された JAR ファイルを jarsigner が検証できないというのは、既知の問題です。
Java 2 SDK では、アプリケーションクラスは現行の ClassLoader インスタンスによってロードされます。それによってアプリケーションクラスがインストール済み拡張機能を使用できるようになり、さらに、アプリケーションクラスパス (ユーザが指定) をブートストラップクラスパス (固定で、ユーザは通常変更しない) から分離することができるようになります。-Xbootclasspath オプションを使用すると、必要に応じてブートストラップクラスパスを無効にできます。
つまり、Java 2 SDK のアプリケーションクラスは、デフォルトですべてのアクセス権を持つのではないこということです。その代わり、そのシステムに設定されたセキュリティポリシーを基にアクセス権が与えられます。そのため、1.0 や 1.1 の元のセキュリティモデルに基づいて自らのセキュリティコードを書くようなアプリケーションでは、例外をスローしたり、Java 2 SDK で起動しなかったりする場合があります。
以下に、セキュリティポリシーと署名に関する問題の概要を示します。
- Java 2 プラットフォームが使用するデフォルトのセキュリティポリシー実装は、Java セキュリティプロパティファイル jre/lib/security/java.security の policy.provider プロパティによって指定されます。デフォルト以外のセキュリティポリシー実装を指定する場合は、デフォルト以外のセキュリティプロパティクラスファイルを新しくブートクラスパスに置く必要があります。これは、-Xbootclasspath コマンド行オプションを使って行います。このオプションの詳細は、Java アプリケーション起動ツールのリファレンスページを参照してください。これにより、ポリシーファイルがブートストラップクラスローダによりロードされます。新たにデフォルトポリシーファイルを、クラスパスまたは拡張機能内などの他の場所に配置すると、このファイルは取得されず、代わりに sun.security.provider.PolicyFile で提供されるデフォルトポリシーが使用されます。
- バージョン 1.2.2 以降の Java 2 SDK は、新しいクラスローディング機構を使用します。新しいクラスローダでは、Jar ファイルのパッケージに属する任意のクラスファイルを署名する場合、同じパッケージに属するすべてのクラスファイルが同じ署名者によって署名されている必要があります。パッケージ内に署名付きクラスと署名のないクラスとが混在する、または署名者の異なるクラスが存在する Jar ファイルは使用できなくなりました。Jar ファイルには、署名のないパッケージを含めることは可能です。ただし、任意のパッケージが署名付きクラスを含む場合、そのパッケージのクラスファイルはすべて、同一の署名者により署名される必要があります。この基準に従っていない既存の Jar ファイルは、このバージョンの Java 2 プラットフォームでは使用できません。
keytool ツールを使って、Base64 で符号化された証明書をインポートまたは印刷することができます。ただし、この処理を行うためには、証明書ファイルの末尾に改行文字が挿入されていなければなりません。証明書ファイルの末尾に改行文字がない場合は、サポート対象外の符号化であることを示す例外 CertificateException がスローされるか、「入力の構文解析に失敗しました。」や「入力は X.509 証明書ではありません。」などの意味のエラーメッセージが表示されます。
このようなエラーメッセージや例外が発生する場合は、ファイルの末尾に改行文字が存在しない可能性があります。その理由の 1 つとして、証明書発行局からの証明書応答 (証明書署名要求への応答) に改行文字が含まれていないことが考えられます。
UNIX では、次のコマンドを実行することによって、ファイルの末尾に改行文字が存在するかどうかを確認できます。
od -xc <certificate_name>
<certificate_name> は、証明書が含まれているファイル名で置き換えます。たとえば、mycert という名前のファイルを使用する場合は、次のコマンドを実行します。
od -xc mycert
実行後、出力の末尾に「¥n」があれば、ファイルの末尾には改行文字が存在しています。「¥n」がない場合は、改行文字を挿入する必要があります。
証明書ファイルの末尾に改行文字があるかどうかわからない場合は、とりあえず段落ごとに改行文字を挿入してみてください。改行文字が余分に存在していても問題はありません。改行文字を挿入したら、-import または -printcert コマンドを再試行します。ここでコマンドが正しく実行されれば、改行文字の不足のせいでエラーが発生していたことになります。それでもまだエラーが発生する場合は、証明書に何らかの問題があると考えられます。
Base64 で符号化された証明書ファイルの末尾に改行文字を挿入したい場合は、まず任意のテキストエディタでファイルを開き、ファイルの末尾にカーソルを移動させます。次に、改行文字 (または復帰改行文字) を入力します。キーボードの Enter キーなどを押すと入力できます。
Print-friendly Version
