[size=4]原文地址，欢迎交流：


[color=FF0000][url]http://www.591pic.com/read-htm-tid-41.html[/url][/color][/size]


[size=3]随着互连网的规模与影响不断扩大，网络通信安全已成为网络程序设计时，需要重点考虑的问题。 

SSL(Server Socket Layer)服务套接字层，是Netscape(网景)公司提出的用于internet上安全保密传输信息的协 

议，它工作于OSI开放系统互连模型的传输层之上，因此在传输层之上的协议，比如http,ftp,smtp等，都可以基 

于ssl实现安全的网络通信。 

最近做MCS平台项目，需要实现应用程序平台到MCS平台的安全通信，做了有一阵子，小结一下。 




原理： 

要想保证网络通信的安全，我们第一反应就是给传输的数据加密，这也是现行安全传输通用的模式。但在传统加 

密方式(单密钥，对称加密)下，密钥不可避免的要被传送于网络节点之间，(除非是写死到各个节点中,不过那样 

就没有任何灵活性和普适性)，在一定强度的网络攻击下，这种加密方式是很脆弱的。 

SSL的出现解决了这个难题，理解SSL的关键是理解非对称加密的含义。 

在对称加密的情况下，源数据A，通过使用密钥B，加密成为密文C。任何人，只要获得了密钥B，就能够对截获 

的密文C解密，还原出源数据A。(依靠"算法安全"远不如依靠"密钥安全")；在非对称加密中，出现了“密钥对” 

的概念，即有一个公共密钥(公钥)和一个私有密钥(私钥)，经公钥加密的密文只能由私钥解密，反过来，经私钥 

加密的密文只能由公钥解密。这是个重要的特性(数学原理可参考RSA算法)，下面的模拟https通信流程说明了这 

一特性的重要。 

1，客户端向服务端发出请求，服务端将公钥(以及服务端证书)响应给客户端； 

2，客户端接收到服务器端端公钥与证书，验证证书是否在信任域内，不信任则结束通信，信任则使用服务端传 

过来的公钥生成一个“预备主密码”，返回给服务端。 

3，服务端接收客户端传过来的“预备主密码”密文，使用私钥解密。非对称加密的安全性也就在于此了，第三 

方无法获取到“预备主密码”的明文，因为除了服务端，其他任何人是没有私钥的。 

4，双方使用“预备主密码”生成用于会话的“主密码”。确认后，结束本次SSL握手，停止使用非对称加密。 

5，双方使用“主密码”对称加密传输数据，直到本次会话结束。 

总结整个流程：先采用非对称加密模式，保证“主密码”只被通信双方获知，而后使用传统的对称加密方式 

通信，这样，保证了密钥安全(即“主密码”)就等于保证了数据安全。之所以建立安全连接后，转而使用对称加 

密，是因为非对称加密的运算量很大，用于“常态”的数据通信十分低效。 

以上描述的仅是SSL协议中加密通信的原理，没有涉及到证书验证，以及客户端，服务端模式。 




实现： 

JDK里面自带了一个密钥生成工具keytool，可以通过它生成SSL通信需要的密钥对，或者生成自签名的证书。 

所有密钥对或者签名证书都是存放在“keystore”密钥仓库中，由它来管理。 

下面结合具体例子说明：(java WEB容器:tomcat 5.5) 

1，生成服务端密钥仓库， 

keytool -genkey -alias svrkey -keyalg RSA -keystore d:\svr.jks -validity 365 

"alias"是生成的密钥别名，密钥的导入导出都需要由别名来定位。 

"keystore"生成的密钥仓库 

"validity"生成密钥仓库的有效期(天) 

随后会要求输入密钥仓库入口密码,比如: lostsky_11

输完密码后，接着会要求一系列的输入，无非是单位，所在地区之类的信息， 

但是第一项很重要！为输入服务端域名或IP，如: 192.168.1.3或www.591pic.com 

必须与服务器域名或IP相同，否则SSL连接无法建立(这也是SSL通信验证的一部分) 

2，在tomcat_home/conf/server.xml中配置: 

找到ssl通信配置那一段，加入： 

keystoreFile="d:\svr.jks" keystorePass="lostsky_11" 

服务器启动时会从中寻找用于建立ssl连接的密钥 

3，导出服务端证书 

keytool -export -alias svrkey -file d:\svr.cer -keystore d:\svr.jks 

"alias"为想导出的密钥的别名，"file"为导出的证书，"keystore"为存储着导出密钥的仓库 

4，生成客户端密钥仓库 

keytool -genkey -alias clientkey -keyalg RSA -keystore d:\client.jks 

会要求输入仓库密码：如：midsky

5，将服务端证书导入到客户端密钥仓库 

keytool -import -file d:\svr.cer -keystore d:\client.jks 

会要求输入客户端密钥仓库的密码：如上是：midsky

这样服务端的密钥仓库就在tomcat部署完毕了， 

6，在客户端，每次访问服务端之前，加入 

"System.setProperty("javax.net.ssl.trustStore","d:\\client.jks"); 

System.setProperty("javax.net.ssl.trustStorePassword","midsky"); 
" 
就把服务端证书添加到了客户端的信任域中，能够完成ssl通信。 

注：ssl通信主要验证三个方面： 

a, 证书是否可信(第6步) 

b, 证书是否过期(第1步:validity) 

c, 证书地址是否和当前访问地址符合(第1步) 

客户端添加信任域还有编程的动态方法，但是那样会降低通信的安全性，对于证书相对固定的服务，不建议使 

用。 



以上是客户端对于服务端的验证，这也是SSL默认的实现方式。在这种方式下，每次通信时，发起请求方(如PC 

中的BROWSER)都会验证响应方(如某个WEB服务端)的证书是否在己方信任域中，对方的证书是否过期，对方 

的域名或IP，是否与信任域中证书记载的一致；不符合其中任何一项，通信都会被拒绝。但反过来，响应方是不 

对请求方做任何验证的。所以有些需要双向验证的服务(比如某些服务只能对特定的拥有证书的用户开放)，就需 

要添加客户端证书，由服务端来验证了，原理和实现与默认模式类似。 



完，困，洗，睡。[/size]