SSL握手會有很多意想不到的Exception, 其中很多都是因爲沒有配置好cacerts導致的。
以Tomcat爲例，你需要在conf/server.xml中指定你的keystore並且配置好KeyAlias，
同時，Tomcat會到JAVA_HOME/jre/lib/security目錄下讀取cacerts文件。
在Weblogic中，你也需要配置Trust.jks和Identity.jks（可以參考WebLoigc Security In Action）。
問題是，IE究竟根據什麼來提交證書（包含私鑰的證書）？
很簡單，服務器提交他的證書到客戶端，客戶端會根據服務器的證書的DN，檢索本地私鑰，
選擇那些由此DN簽發證書X，然後確定使用X對應的本地私鑰，用於SSL握手。
cacerts是JDK容器信任的證書列表，如果cacerts中沒有包含客戶端私鑰對應的證書鏈中的
信任證書，則服務器會拒絕任何從客戶端的SSL請求。
典型的Weblogic日誌就是：
<Certificate chain received from 客戶端- 192.168.10.10 was not trusted causing SSL handshake failure.>
以Tomcat爲例，你需要在conf/server.xml中指定你的keystore並且配置好KeyAlias，
同時，Tomcat會到JAVA_HOME/jre/lib/security目錄下讀取cacerts文件。
在Weblogic中，你也需要配置Trust.jks和Identity.jks（可以參考WebLoigc Security In Action）。
問題是，IE究竟根據什麼來提交證書（包含私鑰的證書）？
很簡單，服務器提交他的證書到客戶端，客戶端會根據服務器的證書的DN，檢索本地私鑰，
選擇那些由此DN簽發證書X，然後確定使用X對應的本地私鑰，用於SSL握手。
cacerts是JDK容器信任的證書列表，如果cacerts中沒有包含客戶端私鑰對應的證書鏈中的
信任證書，則服務器會拒絕任何從客戶端的SSL請求。
典型的Weblogic日誌就是：
<Certificate chain received from 客戶端- 192.168.10.10 was not trusted causing SSL handshake failure.>
