web-dev-qa-db-ja.com

Weblogicからサービスリクエストを送信するときの証明書検証エラー

Salesforce.comにサービスコールを発信しようとしています。証明書チェーンをキーストアに追加しましたが、サービスがドメイン証明書を確認すると、CNのサブドメイン部分のワイルドカードでハングアップしますが、これはサイトから直接取得した証明書です。 WebLogicが証明書CNでワイルドカードをサポートしていないことがわかりました。証明書を無効にすることなくCNを変更することは可能ですか？.

WebLogic OSB内からサービスをテストするときのエラーは次のとおりです。

呼び出しの結果、エラーが発生しました：[セキュリティ：090504] sensis-proxy-vs.sensis.com.au-161.117.32.128-> cs5.salesforce.comから受け取った証明書チェーンがホスト名検証チェックに失敗しました。証明書には* .salesforce.comが含まれていますが、予想されるcs5.salesforce.comを確認してください。

ssl-certificateweblogic
2
Fergal

ここでの問題は、WebLogicのデフォルトのホスト名検証が、CNにホスト名のワイルドカードが含まれているSSL証明書をサポートしていないことです。

WebLogicのホスト名検証を変更することが可能で、WebLogicにはワイルドカードを使用してCNを検証できるクラスが付属しています。

  1. WebLogic管理コンソール->環境->サーバー->サーバー->設定-> SSLに移動します。

  2. 「ロックして編集」をクリックします

  3. 「詳細」フラップを開きます

  4. 「ホスト名検証」を「BEAホスト名検証」から「カスタムホスト名検証」に変更します。

  5. 「カスタムホスト名検証」をweblogic.security.utils.SSLWLSWildcardHostnameVerifierに設定します

  6. [保存]をクリックし、[変更を有効化]をクリックします

  7. サーバーを再起動します。

5
Stuart Caie

WeblogicサーバーでSSLの問題をデバッグするために友達を探していますか？

エラー：

FINE: ……….. Eating Exception ……….
Java.security.NoSuchAlgorithmException: Algorithm ECDH not available
+ at javax.crypto.KeyAgreement.getInstance(DashoA13*..)+

理由：

これは、クライアントとサーバーの両方が共通の暗号（アルゴリズム）でネゴシエートできないため、ハンドシェイクが失敗しています。

簡単に説明すると、暗号はクライアント側で初期化され、サーバーはSSLで通信するためにクライアントから提示された暗号のいずれかを選択する必要があります。サーバーがクライアントに共通するそのような暗号アルゴリズムをサポートしていない場合、通信は行われません。

したがって、クライアント（Weblogic）がより弱い暗号を使用するように強制でき、サーバーが制限された暗号の使用に制約がない場合は、SSL経由で接続できます。

解決：

デフォルトでは、WebLogic ServerはSSLのcerticom実装を使用します。

上記の例外は、SSLのcerticom実装が共通の暗号ネゴシエーションを取得できないためです。

この問題を解決するために、SSLのSun実装を使用するようにWeblogicサーバーに指示できます。

SSLのSun実装を使用するために、Weblogicサーバーで次のプロパティを使用できます。

  • Djavax.net.ssl.keyStore
  • Djavax.net.ssl.keyStoreType
  • Djavax.net.ssl.keyStorePassword
  • Djavax.net.ssl.trustStore
  • Djavax.net.ssl.trustStoreType
  • Djavax.net.ssl.trustStorePassword
  • Djava.protocol.handler.pkgs = com.Sun.net.ssl.internal.www.protocol

上記のプロパティはすべてJavaプロパティとして使用できるため、WLS JVMは独自の実装を使用するのではなく、これらの値を使用します。

以下のように、コードで上記のプロパティを使用することもできます。

System.setProperty( “javax.net.ssl.keyStore”, “***” );
System.setProperty( “javax.net.ssl.keyStoreType”, “JKS” );
System.setProperty( “javax.net.ssl.keyStorePassword”, “***” );
System.setProperty( “javax.net.ssl.trustStore”, “***” );
System.setProperty( “javax.net.ssl.trustStoreType”, “JKS” );
System.setProperty( “javax.net.ssl.trustStorePassword”, “***” );
Security.addProvider( new com.Sun.net.ssl.internal.ssl.Provider() );
System.setProperty( “Java.protocol.handler.pkgs”, “com.Sun.net.ssl.internal.www.protocol” );

[〜＃〜]注[〜＃〜]-また、SSLランタイムのデバッグには、アドミンコンソールを使用できます。サーバーの場合、アドミンコンソール>>>>サーバー>>> MS1 >>>デバッグ>>>> weblogicツリー>>>> sslオプションにログオンします。オプションをチェックし、[有効にする]をクリックします。

2
Sahara

WebLogic管理コンソール->環境->サーバー->サーバー->設定-> SSLに移動します。

「詳細」フラップを開きます

「ホスト名検証」を「BEAホスト名検証」から「なし」に変更します。

「保存」をクリックします

サーバーを再起動します。

1
user299833

あるいは、以下のように作業することもできます。

上記の回答＃「カスタムホスト名検証をweblogic.security.utils.SSLWLSWildcardHostnameVerifierに設定」を設定しても機能しませんでした。

私はそれが私のために働いた次の手順を実行しました：

に行く

WebLogic管理コンソール->環境->サーバー->サーバー->構成-> SSL

  • 「ロックして編集」をクリックします

    • 「詳細」フラップを開きます

    • 「ホスト名検証」を「BEAホスト名検証」から「なし」に変更します。

    • [保存]をクリックし、[変更を有効化]をクリックします

    • サーバーを再起動します。

そして、このSSL対応環境に接続するクライアントアプリケーションは、Javaを次の-Dオプションで実行しました。

-Dweblogic.security.SSL.ignoreHostnameVerification=true

これで、クライアントアプリケーションからSSL対応環境に接続できるようになりました。内部的に、クライアントはWebサーバーのt3s（SSL）対応のJMSで動作する必要があります。それは私が私のクライアントアプリケーションで得ていた以下の例外を解決しました：

javax.naming.CommunicationException: t3s://slc09kty.MYHost.com:7202: Destination 10.XX.XX.164, 7202 unreachable; nested exception is:
        javax.net.ssl.SSLKeyException: Hostname verification failed:
0
Laxman G