Eclipse Temurin 17.0.15 のリリースノート

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

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

Eclipse Temurin には、OpenJDK のアップストリームディストリビューションの構造の変更は含まれません。

Eclipse Temurin の最新の OpenJDK 17 リリースに含まれる変更点とセキュリティー修正の一覧は、OpenJDK 17 .0.15 Released を参照してください。

新機能および機能拡張

Eclipse Temurin 17.0.15 には、以下の新機能と機能拡張が含まれています。

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

以前の OpenJDK リリースでは、ファイルが署名済み JAR ファイルから削除されても、ファイル署名がまだ存在していた場合でも、jarsigner ツールはこの状況を検出しませんでした。

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

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

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

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

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

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 システムプロパティーを使用します。

これらの制限は、OpenJDK に含まれる次の Camerfirma ルート証明書に適用されます。

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

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

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

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

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

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

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

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

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

OpenJDK 17.0.15 は、JNI_GetCreatedJavaVM メソッドが、完全に初期化された VM のみを返すことを確認して、この問題を解決します。

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

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

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

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

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

改訂日時: 2025-04-30