SSL

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