1.术语
1.1 SSL
TLS 与 SSL
TLS 的前身是 SSL。其是一个用于在应用程序之间进行通信时保障隐私的协议。除非另有说明,本文中认为 TLS 与 SSL 是等价的。
OpenSSL
简单地说,OpenSSL是SSL的一个实现,SSL只是一种规范.理论上来说,SSL这种规范是安全的,目前的技术水平很难破解,但SSL的实现就可能有些漏洞,如著名的”心脏出血”.OpenSSL还提供了一大堆强大的工具软件,强大到90%我们都用不到
1.2 密钥相关术语
公钥、私钥
公钥和私钥就是俗称的不对称加密方式,是从以前的对称加密(使用用户名与密码)方式的提高。
一个私钥可以验证与其对应的用来对数据进行加密的证书和公钥。其决不公开提供。
公钥和私钥是成对的,它们互相解密。非对称密钥密码的主要应用就是公钥加密和公钥认证,而公钥加密的过程和公钥认证的过程是不一样的:公钥加密,私钥解密。私钥数字签名,公钥认证。
比如,我用你的公钥给这个邮件加密,这样就保证这个邮件不被别人看到,而且保证这个邮件在传送过程中没有被修改。你收到邮件后,用你的私钥就可以解密,就能看到内容。
其次我用我的私钥给这个邮件加密,发送到你手里后,你可以用我的公钥解密。因为私钥只有我手里有,这样就保证了这个邮件是我发送的。
当A->B资料时,A会使用B的公钥加密,这样才能确保只有B能解开,否则普罗大众都能解开加密的讯息,就是去了资料的保密性。验证方面则是使用签 验章的机制,A传资料给大家时,会以自己的私钥做签章,如此所有收到讯息的人都可以用A的公钥进行验章,便可确认讯息是由 A 发出来的了。
摘要
对需要传输的文本,做一个HASH计算,一般采用SHA1,SHA2来获得。
签名
使用私钥对需要传输的文本的摘要进行加密,得到的密文即被称为该次传输过程的签名。
签名认证
数据接收端,拿到传输文本,但是需要确认该文本是否就是发送发出的内容,中途是否曾经被篡改。因此拿自己持有的公钥对签名进行解密(密钥对中的一种密钥加密的数据必定能使用另一种密钥解密。),得到了文本的摘要,然后使用与发送方同样的HASH算法计算摘要值,再与解密得到的摘要做对比,发现二者完全一致,则说明文本没有被篡改过。
基于公钥的加密过程
比如有两个用户Alice和Bob,Alice想把一段明文通过双钥加密的技术发送给Bob,Bob有一对公钥和私钥,那么加密解密的过程如下:
Bob将他的公开密钥传送给Alice。Alice用Bob的公开密钥加密她的消息,然后传送给Bob。Bob用他的私人密钥解密Alice的消息。Alice使用Bob的公钥进行加密,Bob用自己的私钥进行解密。
基于公钥的认证过程
身份认证和加密就不同了,主要用来鉴别用户的真伪。这里我们只要能够鉴别一个用户的私钥是正确的,就可以鉴别这个用户的真伪。
还是Alice和Bob这两个用户,Alice想让Bob知道自己是真实的Alice,而不是假冒的,因此Alice只要使用私钥对文件签名发送给Bob,Bob使用Alice的公钥对文件进行解密,如果可以解密成功,则证明Alice的私钥是正确的,因而就完成了对Alice的身份鉴 别。整个身份认证的过程如下:
Alice用她的私人密钥对文件加密,从而对文件签名。Alice将签名的文件传送给Bob。Bob用Alice的公钥解密文件,从而验证签名。Alice使用自己的私钥加密,Bob用Alice的公钥进行解密。
证书(cert)
包含了提供者信息等一些额外元数据的公钥/私钥对的公钥部分。它可以被自由的提供给任何人。
在签名的过程中,有一点很关键,收到数据的一方,需要自己保管好公钥,但是要知道每一个发送方都有一个公钥,那么接收数据的人需要保存非常多的公钥,这根本就管理不过来。并且本地保存的公钥有可能被篡改替换,无从发现。怎么解决这一问题?由一个统一的证书管理机构来管理所有需要发送数据方的公钥,对公钥进行认证和加密。这个机构也就是我们常说的CA。
认证加密后的公钥,即是证书,又称为CA证书,证书中包含了很多信息,最重要的是申请者的公钥。数字证书用来使用户找到该授信机构的公钥。
证书颁发机构(CA)
一个颁发数字证书的公司。对于 SSL/TLS 证书,也有少数供应商(例如 Symantec/Versign/Thawte、Comodo、GoDaddy)的证书囊括了大多数浏览器和操作系统。它们的目的是成为一个“可信的第三方”。
1.3 证书标准
X.509
用于描述证书的格式和用法的一个规范。主要定义了证书中应该包含哪些内容.其详情可以参考RFC5280,SSL使用的就是这种证书标准.
1.4 编码格式
同样的X.509证书,可能有不同的编码格式,目前有以下两种编码格式.
PEM
Privacy Enhanced Mail,打开看文本格式,以”—–BEGIN…”开头, “—–END…”结尾,内容是BASE64编码.
查看PEM格式证书的信息:openssl x509 -in certificate.pem -text -noout
Apache和*NIX服务器偏向于使用这种编码格式.
DER
Distinguished Encoding Rules,打开看是二进制格式,不可读.
查看DER格式证书的信息:openssl x509 -in certificate.der -inform der -text -noout
Java和Windows服务器偏向于使用这种编码格式.
1.5 文件扩展名
这是比较误导人的地方,虽然我们已经知道有PEM和DER这两种编码格式,但文件扩展名并不一定就叫”PEM”或者”DER”,常见的扩展名除了PEM和DER还有以下这些,它们除了编码格式可能不同之外,内容也有差别,但大多数都能相互转换编码格式.
key
通常用来存放一个公钥或者私钥,并非X.509证书,编码同样的,可能是PEM,也可能是DER.
查看KEY的办法:openssl rsa -in mykey.key -text -noout
如果是DER格式的话,同理应该这样了:openssl rsa -in mykey.key -text -noout -inform der
crt
crt应该是certificate的三个字母,其实还是证书的意思,常见于*NIX系统,有可能是PEM编码,也有可能是DER编码,大多数应该是PEM编码,相信你已经知道怎么辨别.
cer
还是certificate,还是证书,常见于Windows系统,同样的,可能是PEM编码,也可能是DER编码,大多数应该是DER编码.
csr
Certificate Signing Request,即证书签名请求,这个并不是证书,用私钥生成的一个文件。是向权威证书颁发机构获得签名证书的申请, CA 则使用其私钥对csr进行数字签名,并创建一个已签名的证书。然后浏览器可以使用 CA 提供的证书来验证新的证书是否已被 CA 批准。 其核心内容是一个公钥(当然还附带了一些别的信息),在生成这个申请的时候,同时也会生成一个私钥,私钥要自己保管好.(?)
查看的办法:openssl req -noout -text -in my.csr (如果是DER格式的话照旧加上-inform der,这里不写了)
PFX/P12
predecessor of PKCS#12,对*nix服务器来说,一般CRT和KEY是分开存放在不同文件中的,但Windows的IIS则将它们存在一个PFX文件中,(因此这个文件包含了证书及私钥)这样会不会不安全?应该不会,PFX通常会有一个”提取密码”,你想把里面的东西读取出来的话,它就要求你提供提取密码,PFX使用的时DER编码,如何把PFX转换为PEM编码?
openssl pkcs12 -in for-iis.pfx -out for-iis.pem -nodes
这个时候会提示你输入提取代码. for-iis.pem就是可读的文本.
生成pfx的命令类似这样:openssl pkcs12 -export -in certificate.crt -inkey privateKey.key -out certificate.pfx -certfile CACert.crt
其中CACert.crt是CA(权威证书颁发机构)的根证书,有的话也通过-certfile参数一起带进去.这么看来,PFX其实是个证书密钥库.
JKS
即Java Key Storage,这是Java的专利,跟OpenSSL关系不大,利用Java的一个叫”keytool”的工具,可以将PFX转为JKS,当然了,keytool也能直接生成JKS,不过在此就不多表了.
2.公钥、私钥、证书的生成
1、一个HTTPS服务器首先创建他自己的密钥对(key pair),包含公钥和私钥。
2、通过网络把他的公钥送到CA中心,公钥中包含了个人鉴别信息(他的名字、地址、所用设备的序列号等等)。
3、CA中心创建并签署一个包含公钥及个人信息的证书,从而保证密钥的确实性。
4、使用该证书的人可以通过检验CA中心的签名(检验CA签名需要CA的公钥)来验证证书的确实性。
3.公钥、私钥、证书的使用
在HTTPS协议的握手阶段是公钥、私钥、证书的典型使用场景。HTTPS握手的典型时序图如下:

上图中实线部分是必须的,虚线部分是可选的。该流程完成了两个任务:服务器身份的验证、加密传输对称加密密钥。
1、client hello和 server hello表示双方要建立一个加密会话。
2、服务器把数字证书传输给客户端,证书中包含服务器公钥,客户端用公钥解析证书中的数字签名,可以验证服务器的身份。
3、Server Hello Done表示hello 流程结束。
4、客户端生成一个对称加密密钥,用于实际数据的加密传输,并用服务器的公钥加密,把对生成的密钥传递给服务器。同时携带一个用刚刚生成的加密密钥加密的“client finished”。
5、服务器收到对称加密密钥,并尝试用该密钥解密加密字段,如能得到明文“client finished”,认为该密钥有效,可以用于之后的数据加密传输。同时用该密钥加密“server finished”,传递给客户端。
6、客户端用对称机密密钥解密,如能得到明文“server finished”,客户端认为该服务器已经正确的接收到对称密钥。
7、加密数据传输开始。
虚线部分是服务器端要求验证客户身份。
references
1.http://www.cnblogs.com/guogangj/p/4118605.html
2.http://www.oschina.net/translate/everything-you-ever-wanted-to-know-about-ssl
3.http://blog.csdn.net/sealyao/article/details/5761747