7

自己署名証明書や信頼されていないものなど、さまざまな SSL の問題について不平を言っている Java アプリがいくつかあります。

これらのアプリのコードがなく、適切な証明書を取得するのが難しすぎるため、強制的に接続できるようにするソリューションを探しています。

これまでのところ、これらを試しましたが、十分ではないようです：

-Dcom.sun.net.ssl.checkRevocation=false 
-Djava.security.debug=certpath

私はまだ見ています：

  • sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
  • javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
4

3 に答える 3

7

信頼の検証を完全に無視することによって証明書の検証エラーを無視するようにコードを変更する（たとえば、何もしない信頼マネージャーを使用する）ことは、通常、正しい方法ではありません。一部の開発者には、証明書の処理に関する手順を実行する必要がないため人気があるかもしれませんが、問題を修正するのではなく無視しているだけなので、MITM攻撃に脆弱性が発生します。（その後、問題は解決されるため、製品リリースでは修正されない傾向があります。）

信頼管理を構成するさまざまな方法は、JSSEリファレンスガイドで説明されています。

つまり、証明書をJREトラストストア（通常cacertsはJREディレクトリ内のファイル）に明示的にインポートするか、独自のトラストストア（おそらくデフォルトのトラストストアのコピーに基づく）にインポートし、次のコマンドを使用してパスを指定することができます。 （および関連するjavax.net.ssl.trustStore）システムプロパティ（JSSE参照ガイドを参照）。

これらの構成設定は、デフォルト設定自体を使用するすべてSSLSocketのおよびに影響します（コードにSSLEngine特定のものはありません）。SSLContext

一部のアプリケーションは、独自のアプリケーションを使用してSSLContext、特定の接続用に特定のキーストアまたはトラストストアをロードします。これは通常、JSSEのデフォルトオプションに依存しないパラメーターで構成されます。この場合、アプリケーションのドキュメントまたはコードを確認する必要があります。

于 2012-10-23T12:45:26.803 に答える
6

http://code.google.com/p/misc-utils/wiki/JavaHttpsUrlには、侵襲的なソリューションがいくつか用意されています。

SSLSocketFactory は、システム プロパティでオーバーライドできます。

ただし、カスタム HostnameVerifierは、追加の起動パラメーターを介して、またはその場で特別な Java エージェントでのみ承認できます。

さらに、AspectJ ウィービング エージェントを使用して、任意のメソッドの動作をオーバーライドできます。

MiTM HTTPS プロキシを使用した代替アプローチも検討してください(アプリケーションで URL と証明書の再構成が許可されている場合)。

于 2012-10-23T14:48:36.490 に答える
-2

はい、可能です。

JVM 引数の使用:

-Dcom.sun.net.ssl.checkRevocation=false

またはプログラムで：

デフォルトの TrustManager と HostnameVerifier をオーバーライドできます。このリンクは、再利用可能なコード例を提供します。

于 2019-03-01T16:53:12.320 に答える