Red Hat build of OpenJDK 17.0.15 のリリースノート

Red Hat は、Red Hat build of OpenJDK の一部のメジャーバージョンを製品でサポートします。一貫性を保つために、これらのバージョンは長期サポート (LTS) として指定されている Oracle JDK バージョンと同様のままとなります。

Red Hat build of OpenJDK のメジャーバージョンは、最初に導入された時点から少なくとも 6 年間サポートされます。詳細は、OpenJDK のライフサイクルおよびサポートポリシー を参照してください。

Red Hat Enterprise Linux の OpenJDK には、Red Hat build of OpenJDK のアップストリームディストリビューションの構造上の変更が数多く含まれています。Microsoft Windows バージョンの Red Hat build of OpenJDK は、Red Hat Enterprise Linux の更新にできる限り従います。

以下は、Red Hat build of OpenJDK 17 における最も注目すべき変更のリストです。

最新の Red Hat build of OpenJDK 17 には、新機能が含まれている可能性があります。さらに、最新リリースは、以前の Red Hat build of OpenJDK 17 リリースに由来する機能を強化、非推奨、または削除する可能性があります。

Red Hat build of OpenJDK の機能強化

Red Hat build of OpenJDK 17 では、以前のリリースの Red Hat build of OpenJDK で作成された機能に拡張が行われました。

削除されたファイルエントリーに関する jarsigner ツールからの警告

以前の Red Hat build of OpenJDK リリースでは、ファイルが署名付き JAR ファイルから削除されても、ファイル署名がまだ存在すると、jarsigner ツールはこの状況を検出しませんでした。

Red Hat build of OpenJDK 17.0.15 では、jarsigner -verify コマンドを使用して、すべての署名に一致するファイルエントリーがあることを確認できます。不一致が存在する場合は、このコマンドが警告を出力します。一致しないエントリーの名前を表示するには、コマンドに the -verbose オプションを追加します。

JDK-8309841 (JDK バグシステム) を参照してください。

2025 年 4 月 15 日と Camerfirma ルート CA によってアンカー後に発行された TLS サーバー証明書の要求

同様に、Google、Mozilla、Apple、および Microsoft が発表されたという計画に従い、Red Hat build of OpenJDK 17.0.15 は、Camerfirma ルート証明書により 15 月 2025 以降およびアンカー後に発行される TLS 証明書を信頼します。

Red Hat build of OpenJDK は、これらの証明書が期限切れになるまで、または 2025 年 4 月 15 日より前に発行された証明書を信頼します。

サーバーの証明書チェーンが影響を受ける証明書によってアンカーされている場合は、TLS セッションをネゴシエートしようとすると、トラストアンカーが信頼されていないことを示す例外が発生して失敗するようになりました。以下に例を示します。

TLS server certificate issued after 2025-04-15 and anchored by a distrusted legacy Camerfirma root CA: CN=Chambers of Commerce Root -
2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU

次の keytool コマンドを使用して、この変更が JDK キーストア内の証明書に影響するかどうかを確認できます。

keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>

この変更がチェーン内の証明書に影響する場合は、この証明書を更新するか、証明書の管理を担当する組織に問い合わせます。

Camerfirma ルート証明書によってアンカーされた TLS サーバー証明書を引き続き使用する場合は、jdk.security.caDistrustPolicies セキュリティープロパティーから、jdk.security.caDistrustPolicies セキュリティープロパティーから、java.security.properties システムプロパティーを使用するか、java.security.properties システムプロパティーを使用します。

これらの制限は、Red Hat build of OpenJDK に含まれる以下の Camerfirma ルート証明書に適用されます。

JDK-8346587 (JDK Bug System) を参照してください。

PKCS11 メカニズムにおける問題のある SunPKCS11 プロバイダーチェックの修正

OpenJDK 14 では、SunPKCS11 プロバイダーは レガシーメカニズム の概念を導入しました。メカニズムが弱いアルゴリズムを使用している場合、プロバイダーはこのメカニズムがレガシーであると判断し、その後無効にします。

以前のリリースでは、この動作は柔軟ではありませんでした。たとえば、従来の決定を上書きして、無効なメカニズムを有効にすることはできません。また、暗号化が使用されていない場合でも、署名に使用されているメカニズムがレガシーと見なされる可能性があり、弱い暗号化アルゴリズムがある場合は無効にすることができます。同様に、弱い署名アルゴリズムでは、暗号化または復号化の暗号としてメカニズムを使用できませんでした。

Red Hat build of OpenJDK 17.0.15 では、SunPKCS11 プロバイダーの allowLegacy 設定プロパティーを導入することで、これらの問題を解決しています。allowLegacy プロパティーを true に設定すると、レガシーの決定を上書きできます。このプロパティーは、デフォルトで false に設定されます。

本リリース以降、プロバイダーはレガシーステータスを決定する際にサービスタイプも考慮します。プロバイダーは、暗号に対してのみ暗号化アルゴリズムをチェックし、署名アルゴリズムのみを署名をチェックするようになりました。

JDK-8293345 (JDK Bug System) を参照してください。

部分的に初期化された JVM を取得する JNI_GetCreatedJavaVM メソッドの修正

以前の Red Hat build of OpenJDK リリースでは、Java Native Interface (JNI)メソッド jint JNI_GetCreatedJavaVMs (JavaVM **vm_buf, jsize bufLen, jsize *numVMs) が初期化中 vm_buf アレイで仮想マシンを返した可能性があります。

Red Hat build of OpenJDK 17.0.15 では、JNI_GetCreatedJavaVM メソッドが完全に初期化された VM のみを返すようにすることで、この問題を解決しています。

JDK-8308341 (JDK バグシステム) を参照してください。

OCSP、CRL、および証明書フェッチのタイムアウトの強化

Red Hat build of OpenJDK 17.0.15 には、OCSP (Online Certificate Status Protocol)接続と証明書の取得のタイムアウトをより細かく制御できる 3 つの新しい設定プロパティーが導入されています。

Red Hat build of OpenJDK 17.0.15 には、4 つのタイムアウトプロパティーすべてに対する構文の改善も含まれています。依然として JDK では、値は正の 10 進数の整数である必要がありますが、オプションの接尾辞を追加して単位（秒単位）、ミリ秒単位 の 単位を示すことができるようになりました。接尾辞を指定しない場合、JDK は以前のリリースと同様に値を秒として解釈します。接尾辞の前に 10 進数以外の値を指定すると、JDK はこの値を拒否し、代わりにデフォルト値を使用します。無効な値の例として -5、0xA、および 6.2 の例を示します。

JDK-8179502 (JDK Bug System) を参照してください。

このリリースに含まれるバグ修正と CVE 修正を文書化するために、次のアドバイザリーが発行されます。

改訂日時: 2025-04-30