2016-11-08 17 views
0

私たちのシステムが動作するプロバイダはという名前の証明書をMM_Base64.cerとしています。私たちのキーストアはmitkeystoreです。私たちは、このように私たちのキーストアを使用している:Tomcatとの双方向SSL通信

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" 
       maxThreads="150" SSLEnabled="true" scheme="https" secure="true" 
       clientAuth="false" sslProtocol="TLS" keystoreFile="path\mitkeystore" keystorePass="ourpass" /> 

我々はこのように私たちのJDKとJVMにそのキーをインポート:

keytool -import -file "path\MM_Base64.cer" -keystore "C:\Program Files\Java\jre7\lib\security\cacerts" 

それでも、ハンドシェイクの問題が発生します。

私はthis questionを見ています。それは複雑に見えます。私たちの問題は彼らのものと同じくらい複雑ですか?システムをプロバイダのシステムと連携させる簡単な方法はありますか?

+0

あなたの質問にエラーを追加してください。 –

+0

プロバイダの証明書をキーストアではなくトラストストアにインポートし、そのトラストストアを使用することをserver.xmlに指定する必要があると思いました。どのように2が異なっているかについては、ここを参照してください:http://www.java67.com/2012/12/difference-between-truststore-vs.html#more – borowis

+0

が回答として追加されました – borowis

答えて

3

私は間違っているかもしれませんが、プロバイダの証明書をtrustストアにインポートする必要があると思います。 keystoretrustoreの説明については、hereを参照してください。次に、Tomcatをserver.xmlのhttpコネクタのconfigブロックにあるトラストストアファイルにポイントする必要があります。

SSLハンドシェイクが発生すると、プロバイダは証明書を提示し、信頼できるかどうかを知るために、Tomcatはtruststoreを使用してその証明書または証明機関に関する情報を検索します。

+0

私のチームはあなたの答えをテストしています。どうもありがとう。 –

2

私はtruststoreについてBorys Zibrovに同意します。 https://www.mulesoft.com/tcat/tomcat-sslはssl setupの良いリンクです。

truststoreについての点を除いて、証明書をjdkのキーストアにインポートしていますが、カスタムキーストア(mitkeystore)をkeystoreFileとして使用しています。あなたがmitkeystoreにロードしなかった理由はありますか? (これは実際にはコメントでなければなりませんが、十分な評判がないので私に負担してください)

+1

ええ、これは良い観察です。彼らはそれを動作させるためにすべてを試したように見えます。確かに 'mitkeystore'だったはずです – borowis

関連する問題