如何连接到一个安全的使用SSL在java和PKCS12文件的网站吗

在项目开发中,有时会遇到与SSL安全证书导入打交道的，如何把证书导入java中的cacerts证书库呢？

其实很简单，方法如下：

每一步：进入某个ht tp s:/ /ww w.x xx.c o m开 头的网 站,把要导入的证书过来，

在该网页上右键 >>属性 >>点击"证书" >>

再点击上面的"详细信息"切换栏 >>

再点击右下角那个"复制到文件"的按钮

就会d出一个证书导出的向导对话框，按提示一步一步完成就行了。

例如：保存为abc.cer,放在C盘下

第二步：如何把上面那步的(abc.cer)这个证书导入java中的cacerts证书库里?

方法如下

假设你的jdk安装在C:\jdk1.5这个目录，

开始 >>运行 >>输入cmd 进入dos命令行 >>

再用cd进入到C:\jdk1.5\jre\lib\security这个目录下

敲入如下命令回车执行

keytool -import -alias cacerts -keystore cacerts -file d:\software\AKAZAM-Mail.cer

此时命令行会提示你输入cacerts证书库的密码，

你敲入changeit就行了，这是java中cacerts证书库的默认密码，

你自已也可以修改的。

导入后用-list查看(没有使用-alias指定别名，所以是mykey)，其中md5会和证书的md5对应上。

mykey, 2012-10-26, trustedCertEntry,

认证指纹 (MD5)： 8D:A2:89:9A:E4:17:07:0B:BD:B0:0C:36:11:39:D0:3D

ok,大功告成！

以后更新时，先删除原来的证书，然后导入新的证书

keytool -list -keystore cacerts

keytool -delete -alias akazam_email -keystore cacerts

keytool -import -alias akazam_email -file akazam_email.cer -keystore cacerts

自定义文件和密码路径，还没有验证：

Define the TrustStore using the JAVA_OPTS variable on the Stash Server:

You will have to do the following:

On Windows:

JAVA_OPTS = -Djavax.net.ssl.trustStore="%JAVA_HOME%\jre\lib\security\cacerts" -Djavax.net.ssl.trustStorePassword="changeit"

On Linux:

JAVA_OPTS = -Djavax.net.ssl.trustStore="$JAVA_HOME/jre/lib/security/cacerts" -Djavax.net.ssl.trustStorePassword="changeit"

(info) On my local instance trustStore password is changeit so I belive, if you didn′t changed it, your is changeit as well.

tomcat、junit运行时会从默认路径加载cacerts文件，如果main函数直接运行需要指定javax.net.ssl.trustStore文件路径，比如：

java -Djavax.net.ssl.trustStore=$JAVA_HOME/jre/lib/security/cacerts -jar XXX.jar

注意JAVA_HOME设置中如果有空格，会java执行错误，可以把环境变量JAVA_HOME中C:\Program Files缩写为C:\Progra~1

1、打开“控制面板”，点击：“开始-控制面板”，如果“控制面板”中没有java选项，请点击“查看方式”。

2、打开java控制面板，点击：java-安全-编辑站点列表。

3、添加信任“站点”。

4、添加信任“站点”的 *** 作过程。点击“添加”，在“□”处点一下，Ctrl+V（当然必须先在要打开的网址的地址栏上C

trl+C），最后点击“确定”。

用WS-Security对.NET 和 Java之间的Web服务请求进行签发到底为了对Web服务请求进行签发可以保证消息内容在传输期间没有被修改。 使用数字证书，可以用一个私钥对Web服务进行签发，这样只能用相应的公钥对消息进行校验。

到目前为止，Web服务的安全策略有两种选择： 一种是在传输层(使用 SSL)，另一种是在应用层，使用自定制的安全机制。 这两种方法虽然技术上有效，在采用时均有一些限制与缺点。

在传输层使用SSL而获得的安全性是通过对底层的传输层（HTTP）进行安全化而确保Web服务请求的完整性。. SSL 既可以用于加密链接，也可以用于使用证书来校验客户端和服务器。

使用SSL来保护Web服务的一个主要问题之一就是其安全性只在一个单独的节点到另一个节点之间有效。 由于SSL通信是基于传输层，一旦到达终端节点，这种保护消息的方法就不再有效了。. 例如，我从Client A 向 Server B发送一个消息，并使用SSL来保护链接。 然而，如果我从Client A 向 Server C发送一条信息，并且必须经过Server B，这时就没有容易的办法来确保使用SSL通过这一媒介的传输消息的安全性。

也可以开发一种自定制的安全机制，将消息的内容和消息头在客户端进行签发，并在服务器端进行校验。 这种办法可以克服传输安全问题，但最终这将是一种自定制的解决方案。. 如果一个组织希望保护发布到其它组织的Web服务，则他必须确保另一终端节点也使用了相同的技术。

WS-Security 通过提供一种基于应用层的Web服务签发方式来解决这两个问题（避免在传输层进行安全化时遇到的安全问题），它使用了一个已经公布的标准，可以由客户、系统集成商和销售商参考和采用。

为了帮助推动这一标准，本文将演示一系列两个WS-Security实现之间进行Web签发的示例： 一个位于 Microsoft .NET, 基于 Microsoft Web Services Enhancements (WSE) 1.0, 另一个基于GLUE Professional 4.0.1。

---