web-dev-qa-db-ja.com

java.security.cert.CertificateException：証明書はアルゴリズムの制約に準拠していません

URLを指定してArcGIS 9.3 +ベースマップを追加できるマッピングアプリケーションがあります。追加したいURLの1つは、顧客のURLからのものであり、保護されています。私のマッピングアプリケーションは、以前にJava 6を使用していたため、問題なく安全なURLを追加できました。現在、Java 7にアップグレードし、

"Java.security.cert.CertificateException: Certificates does not conform to algorithm constraints"

例外。 Java 7では、デフォルトで、SSL証明書に署名するMD2アルゴリズムが無効になっているため、これは事実だと思います。これはJava.securityで確認できます。ファイル：

"jdk.certpath.disabledAlgorithms=MD2"

しかし、そのURLのCertification Signature Algorithmを確認すると、SHA-1と表示されます。さらに奇妙なのは、"jdk.certpath.disabledAlgorithms=MD2"ファイルのJava.security行をコメントアウトすると、URLが問題なく機能することです。 SSLプロセス中にMD2が別の場所で使用されていますか？ここに何かが足りませんか？

javassljava-7arcgisarcgis-server
34
james

バックグラウンド

MD2は安全でないと広く認識されていたため、JavaバージョンJDK 6u17で無効化されました（リリースノートを参照 http://www.Oracle.com/technetwork/Java/javase/6u17- 141447.html 、「証明書チェーンの検証でMD2を無効にする」）、およびJava.securityで指摘した構成に従って、JDK 7。

Verisignはmd2WithRSAEncryption署名アルゴリズム（シリアル70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf）を使用するクラス3ルート証明書を使用していましたが、廃止し、同じキーと名前を持つ別の証明書に置き換えましたが、アルゴリズムsha1WithRSAEncryption。ただし、一部のサーバーはSSLハンドシェイク中に古いMD2署名付き証明書を送信しています（皮肉なことに、私はVerisignが実行するサーバーでこの問題に遭遇しました！）。

これが事実であることを確認するには：

openssl s_client -showcerts -connect <server>:<port>

JDKの最近のバージョン（例：6u21およびリリースされた7のすべてのバージョン） 解決 信頼できるアンカーと同じ発行者および公開キーを持つ証明書を自動的に削除することにより（デフォルトではcacertsで）.

新しいJDKでこの問題がまだある場合

古いX509TrustManagerインターフェイスを実装するカスタムトラストマネージャーがあるかどうかを確認します。 JDK 7+はこのインターフェイスと互換性があるはずですが、トラストマネージャーが新しいX509TrustManager（ docs ）ではなくX509ExtendedTrustManagerを実装するときの調査に基づいて、JDKは独自のラッパー（AbstractTrustManagerWrapper）であり、何らかの理由でこの問題の内部修正をバイパスします。

解決策は次のとおりです。

  1. デフォルトのトラストマネージャーを使用する、または

  2. カスタムトラストマネージャーを変更してX509ExtendedTrustManagerを直接拡張します（簡単な変更）。

50
Raman

EclipseはSVN httpsリポジトリーへの接続に失敗しました（SSL/TLSを使用するすべてのアプリにも適用する必要があります）。

svn：E175002：接続がシャットダウンされました：javax.net.ssl.SSLHandshakeException：Java.security.cert.CertificateException：証明書はアルゴリズムの制約に適合していません

この問題は、最新のJava 8 OpenJDK更新によりMD5関連アルゴリズムが無効になりました。新しい証明書が発行されるまでの回避策として（存在する場合）、Java.securityファイルで次のキーを変更します。

[〜＃〜] warning [〜＃〜]
無効なアルゴリズムは脆弱と見なされるため、これはセキュリティに影響する可能性があることに留意してください。別の方法として、外部Java.securityファイルを使用するコマンドラインオプションにより、workaroundをJVMベースで適用できます。この変更により、例えば：
Java -Djava.security.properties=/etc/sysconfig/noMD5.Java.security
Eclipseの場合、Eclipse.iniの下に-vmargs
-Djava.security.properties=/etc/sysconfig/noMD5.Java.security

元のキー

jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768

への変更

jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize < 768

Java.securityファイルは、Linux 64の/usr/lib64/jvm/Java/jre/lib/security/Java.securityにあります。

26
Luis Muñoz

Fedora 28では、次の行に注意してください。

security.useSystemPropertiesFile = true

次の場所にあるJava.securityファイルの

$（dirname $（readlink -f $（which Java）））/../ lib/security/Java.security

Fedora 28はdisabledAlgorithmsコントロールの外部ファイルを導入しました

/etc/crypto-policies/back-ends/Java.config

この外部ファイルを編集するか、次を設定してJava.securityから除外できます。

security.useSystemPropertiesFile = false

8
Aleksandar Brankovic

制御できないデータベースでこの問題が発生し、別のソリューションが必要になりました（ここにリストされているものは機能しませんでした）。私の必要なもの：

-Djdk.tls.client.protocols="TLSv1,TLSv1.1"

私の場合、特定の順序を強制することに関係していると思います。

4
Bill K

この結果はこのエラーに対してGoogleが最初に返すものなので、誰かが方法を探している場合は、グローバルファイルJava.securityを変更せずにJavaセキュリティ設定を変更してくださいいくつかのテストを実行する必要があります）、JVMパラメーター-Djava.security.properties = your/file/pathでオーバーライドセキュリティファイルを提供するだけで、無効化をオーバーライドすることで必要なアルゴリズムを有効にできます。

1
Joonas Vali

同僚。

REST API。JDK 7_80は自分のマシンにのみインストールされました。JDK8をインストールする前はすべて正常に機能し、可能性がありましたOAuth 2.0トークンをJMeterで取得します。JDK8をインストールした後、Certificates does not conform to algorithm constraints 始めた。

JMeterとSerenityの両方には、トークンを取得する可能性がありませんでした。 JMeterは、JDKライブラリを使用して要求を行います。ライブラリーは、要求を無視して、それを使用するエンドポイントに接続するためにライブラリー呼び出しが行われると、例外を発生させます。

次は、comment[〜＃〜] all [〜＃〜 ]Java.securityファイル。

C:\Java\jre7\lib\security\Java.security
C:\Java\jre8\lib\security\Java.security
C:\Java\jdk8\jre\lib\security\Java.security
C:\Java\jdk7\jre\lib\security\Java.security

その後、ようやく機能し始めました。それは総当たり的なアプローチですが、それを修正する最も簡単な方法でした。

# jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
# jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
1
Lord Nighton

これは、証明書チェーンのどこかに証明書、より可能性の高い古いルートがあり、MD2RSAアルゴリズムでまだ署名されているために発生する可能性が高くなります。

証明書ストアに配置して削除する必要があります。

次に、証明機関に戻って、新しいルートを要求します。

同じ有効期間を持つ同じルートである可能性が高くなりますが、SHA1RSAで再認証されています。

この助けを願っています。

1
snlpnstslocn

SOAP-UIでこの問題が発生しましたが、上記の解決策が役に立たなかったわけではありません。

私にとって適切な解決策は、追加することでした

-Dsoapui.sslcontext.algorithm = TLSv1

vmoptionsファイル（私の場合は...\SoapUI-5.4.0\bin\SoapUI-5.4.0.vmoptions）

0
menkow

Docker内でopenjdk-7を使用して、コンテンツを含むファイルをマウントしました https://Gist.github.com/dtelaroli/7d0831b1d5acc94c80209a5feb4e8f1c#file-jdk-security

#Location to mount
/usr/lib/jvm/Java-7-openjdk-AMD64/jre/lib/security/Java.security

ありがとう@luis-muñoz

0
dtelaroli