TLS/SSL
TLS/SSL的功能实现主要依赖于三类基本算法：散列（哈希）函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列（哈希）函数验证信息的完整性。
握手流程说明
TCP握手建立链接后，客户端向服务端发送https请求前要握手一次，主要是认证服务端是否可信，与服务端协商后续传输数据的加密方式，以及校验完整性的签名方式（HASH）
- 客户端发送请求，携带支持的加密算法和hash算法
- 服务端收到后，选择一种加密算法和hash算法；然后返回证书（包含证书签发日期，签名，公钥）
- 客户端使用公钥解密签名出摘要，然后将返回的明文信息hash，与摘要比较校验数据的完整性；同时验证证书的有效性
- 如果验证通过，则hash生成握手消息的摘要，产生随机数据密钥（共享密钥），将握手消息和摘要加密，用公钥加密共享密钥，发送给服务端
- 服务端使用私钥解密出共享密钥，然后解密出握手消息，验证完整性；最后用共享密码加密一段数据后发送给客户端。
- 客户端解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。
证书颁发机构 认证中心CA
解决上述身份验证问题的关键是确保获取的公钥途径是合法的，能够验证服务器的身份信息，为此需要引入权威的第三方机构CA。简单的说，PKI就是浏览器和CA，CA是整个安全机制的重要保障，我们平时用的证书就是由CA机构颁发，其实就是用CA的私钥给用户的证书签名，然后在证书的签名字段中填充这个签名值，浏览器在验证这个证书的时候就是使用CA的公钥进行验签。
CA使用的具体流程 :
a.**服务方S**向第三方机构CA**提交**公钥、组织信息、个人信息(域名)等信息并申请认证;**（不交私钥）**
b.**CA**通过线上、线下等多种手段**验证**申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
c.如信息审核通过，**CA**会向申请者签发认证文件-证书。
证书包含以下信息：**申请者公钥**、申请者的组织信息和个人信息、签发机构**CA的信息**、有效时间、证书序列号等信息的明文，同时包含**一个签名**;
**签名的产生算法**：首先，**使用散列函数计算公开的明文信息**的**信息摘要**，然后，采用**CA的私钥**对信息摘要进行**加密**，**密文即签名**;
d.**客户端 C** 向服务器 S 发出请求时，**S 返回证书**文件;
e.**客户端 C**读取证书中的相关的明文信息，**采用相同的散列函数**计算得到**信息摘要**，然后，利用**对应CA的公钥**解密签名数据，**对比证书的信息摘要**，如果一致，则可以确认证书的合法性，即公钥合法;
f.**客户端**然后验证证书相关的域名信息、有效时间等信息;
g.**客户端**会**内置信任****CA的证书信息(包含公钥)**，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。
在这个过程注意几点：
a.申请证书不需要提供私钥，确保私钥永远只能服务器掌握;
b.证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名;
c.内置 CA 对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书（为什么说"部署自签SSL证书非常不安全"）
d.证书=公钥（服务方生成密码对中的公钥）+申请者与颁发者信息+签名（用CA机构生成的密码对的私钥进行签名）;
即便有人截取服务器A证书，再发给客户端，想冒充服务器A，也无法实现。因为证书和url的域名是绑定的。
CA的作用：
1）颁发证书，颁发证书其实就是使用CA的私钥对证书请求签名文件进行签名；
2）颁发的证书浏览器要信任，浏览器只需要用CA的公钥进行验签成功就表示这个证书是合法可信的，这就需要浏览器内置CA的公钥，也就是内置CA的证书。一般来说，操作系统都会内置权威CA的证书，有的浏览器会使用操作系统内置的CA证书列表，有的浏览器则自己维护的CA证书列表，比如Firefox。
证书链
如 CA根证书和服务器证书中间增加一级证书机构，即中间证书，证书的产生和验证原理不变，只是增加一层验证，只要最后能够被任何信任的CA根证书验证合法即可。
a.服务器证书 server.pem 的签发者为中间证书机构 inter，inter 根据证书 inter.pem 验证 server.pem 确实为自己签发的有效证书;
b.中间证书 inter.pem 的签发 CA 为 root，root 根据证书 root.pem 验证 inter.pem 为自己签发的合法证书;
c.客户端内置信任 CA 的 root.pem 证书，因此服务器证书 server.pem 的被信任。
服务器证书、中间证书与根证书在一起组合成一条合法的证书链，证书链的验证是自下而上的信任传递的过程。
二级证书结构存在的优势：
a.减少根证书结构的管理工作量，可以更高效的进行证书的审核与签发;
b.根证书一般内置在客户端（浏览器或操作系统）中，私钥一般离线存储，一旦私钥泄露，则吊销过程非常困难，无法及时补救;
c.中间证书结构的私钥泄露，则可以快速在线吊销，并重新为用户签发新的证书;
d.证书链四级以内一般不会对 HTTPS 的性能造成明显影响。
证书链有以下特点：
a.同一本服务器证书可能存在多条合法的证书链。
因为证书的生成和验证基础是公钥和私钥对，如果采用相同的公钥和私钥生成不同的中间证书，针对被签发者而言，该签发机构都是合法的 CA，不同的是中间证书的签发机构不同;
b.不同证书链的层级不一定相同，可能二级、三级或四级证书链。
中间证书的签发机构可能是根证书机构也可能是另一个中间证书机构，所以证书链层级不一定相同。
交叉证书
交叉证书的应用场景是这样的：假如现在阿里云成为一个新的根CA机构，那阿里云签发的证书想要浏览器信任的话，阿里云的根证书就需要内置在各大操作系统和浏览器中，这需要较长时间的部署，那在没有完全部署完成之前，阿里云签发的证书怎么才能让浏览器信任呢，这就需要用到交叉证书了。
上图中，根证书A是一个所有浏览器都内置了的根证书，B是一个新的根证书，用户证书D是由根证书 B的二级CA B1来签发的，但是根证书B并没有在浏览器中内置，所以浏览器不会信任用户证书D，这是因为浏览器在验签时只验证到B1这一层然后找不到根证书B就无法验证下去了。
如果二级CA B1证书是由根证书A来签名，那这个问题就解了，所以新的根证书机构B会将二级CA证书（准确地讲是二级CA的证书签名请求文件）给老的根证书A来签名，然后得到一个新的中间证书就是交叉证书。
浏览器在验证的时侯用了新的信任链，这样就可以解决用户证书的信任问题。
当B的根证书全部部署完成后，再替换成自己的二级CA就可以了。
证书分类
证书分有三类：DV、OV、EV
DV证书只校验域名的所有权，所以我们在申请DV证书的时候CA会提供几种验证域名所有权的方法：比如文件校验、DNS校验、邮件校验，DV证书支持单域名、多域名和泛域名，但不支持多个泛域名，只支持一个泛域名，一般价格比较便宜，具体价格跟域名的数量有关，域名越多价格越高。
OV证书要验证组织机构，在申请证书时CA会打电话确认这个域名是否真的属于相应的公司或者机构，OV证书是单域名、多域名、泛域名和多个泛域名都支持，价格一般比DV证书要贵。
EV证书的校验就更细了，比如组织机构的地址之类的，EV证书会在地址栏上显示组织机构的名称，EV证书只支持单域名或者多个域名，不支持泛域名，而且更贵，所以普通用户一般不会用EV证书。
证书吊销
证书是有生命周期的，如果证书的私钥泄漏了那这个证书就得吊销，一般有两种吊销方式：CRL和OCSP。
CRL（ Certificate Revocation List）是CA机构维护的一个已经被吊销的证书序列号列表，浏览器需要定时更新这个列表，浏览器在验证证书合法性的时候也会在证书吊销列表中查询是否已经被吊销，如果被吊销了那这个证书也是不可信的。可以看出，这个列表随着被吊销证书的增加而增加，列表会越来越大，浏览器还需要定时更新，实时性也比较差。
所以，后来就有了 OCSP （Online Certificate Status Protocol）在线证书状态协议，这个协议就是解决了 CRL 列表越来越大和实时性差的问题而生的。有了这个协议，浏览器就可以不用定期更新CRL了，在验证证书的时候直接去CA服务器实时校验一下证书有没有被吊销就可以，是解决了CRL的问题，但是每次都要去CA服务器上校验也会很慢，在网络环境较差的时候或者跨国访问的时候，体验就非常差了，OCSP虽然解决了CRL的问题但是性能却很差。
主要摘自
http://www.360doc.com/content/18/0606/20/13644263_760231690.shtml
