标签：
我们将未加密的内容称为明文，加密之后的内容称为密文。
简单来说，要加密一段明文，可以将这段内容输入到一个加密函数中，输出密文。但这种简单的加密方式存在被人盗取到加密函数从而破解明文的危险，且加密函数一般构成复杂，一旦被盗取更换成本较高。
于是人们想出了一个办法，在加密函数中再添加一个参数，这个参数只有通信双方知道，没有参数则无法正确解密出密码。这个参数被称为密钥。对于同一个加密函数而言，密钥值的不同则加密方式也不同，得出的密文也就不同。这样加密系统的安全性提高了，被盗取密钥之后更换密钥的成本也低了很多。常见的情景是加密函数都是公开的，用户需要保存的仅仅是自己的密钥。
对称密钥加密就是加密与解密使用相同的是密钥值。
流行的对称密钥加密包括：
对称密钥需要通信双方共享密钥。对互联网通信而言，不同的通信双方需要不同的对称密钥，如果有N个用户需要相互通信，总共需要密钥数N*(N-1)。
对称密钥加密存在需要密钥数太多以及传递密钥不方便的缺点，于是人们研究出非对称的密钥加密技术，即加密和解密的密钥不需要一样。其中常见的一种称为公开密钥加密。
公开密钥加密将通信一端的加密和解密密钥分成两个，其中加密密钥可以公开发布，也就是随便谁都可以使用该加密密钥为明文加密，但要解密这段明文只能靠该端私有的解密密钥。这解决了对称密钥加密中的缺点。其中公开的加密密钥称为公开密钥，私有的解密密钥称为私有密钥。
要保证公开密钥加密的可用性必须确保以下情况无法计算出私有密钥：
流行的公开密钥加密包括：
公开密钥加密虽然更加简单安全但其加密算法比较慢，所以一般混合使用公开密钥加密和对称密钥加密的使用方式，即先通过公开密钥加密获取到对称密钥加密的密钥，再通过对称密钥加密传输数据。这种情况在后文说明。
对称密钥加密和公开密钥加密都是将报文加密的技术。但加密能做的不止如此，还可以用加密算法来证明报文是谁编写的以及中途没有被篡改。数字签名就是这种技术。
数字签名是附加在报文上的特殊加密校验码。其使用了私有密钥加密生成校验码，除发送者外其他人都无法重新生成对应的校验码，这样就证明了报文的身份以及中途没有被人篡改过。
数字签名通常通过公开密钥技术产生，但使用方式相反。发送者首先生成报文摘要，使用签名函数并输入私有密钥作为参数，对报文摘要进行加密，生成签名并随报文一起发送出去。接收者通过附加了公开密钥参数的签名函数反函数将签名解密，并与生成的报文摘要进行对比，如果结果一致则代表报文无误。
RSA加密系统可以用于公开密钥加密和数字签名。RSA加密系统将解码函数D作为签名函数使用，编码函数E作为解签名函数。
数字证书是网络上的身份证明。一般包括如下内容：
其中颁发者的数字签名是通过数字证书的其余部分的报文摘要经证书签名算法及证书颁发者的私有密钥计算出的，用于验证数字证书的真实性。
任何人都能自行生成一个数字证书，但只有值得信任的组织（CA）生成的数字证书才会默认被浏览器信任。
HTTPS是在HTTP报文发送给TCP之前对报文进行加密的安全协议。使用443端口进行通信。
普通的HTTP有如下四层：
HTTPS多了一个安全层：
证书密钥验证都是在安全层验证。常用的SSL/TLS编程实现库是OPENSSL。
关于浏览器验证网站数字证书的流程网上的资料一般讲的都不是很清楚。在查阅了不少资料后终于搞清楚这部分。
CA下发给网站的证书都是一个证书链，也就是一层一层的证书，从根证书开始，到下级CA，一层一层，最后一层就是网站证书。
浏览器收到服务器发送的证书后，需要验证其真实性。而证书的签名是通过签名算法和上级CA的私钥生成的，并非很多文章里简单说的靠CA私钥生成。浏览器需要用上级CA的公钥才能解密签名，并与生成的指纹对比，那么问题来了，这个上级CA的公钥从哪来呢？
答案是此公钥来自于证书链该层的上级CA的证书明文内。单个X509v3证书由以下部分组成：
X.509v3证书由三部分组成：
tbsCertificate又包含10项内容，在HTTPS握手过程中以明文方式传输：
证书链由多个证书一层一层组成的，除了最底层的网站证书的公钥是给用户加密报文外，其他层证书中的公钥均用于解密底层的证书指纹签名。最高层的根证书是自签名的，也就是自己颁发给自己，所以它的公钥不仅用来解密下层的签名，也用来给自己的签名解密。
验证证书是否真实的任务完成了，那么证书是否可靠如何验证呢？一句话，只要根证书可靠，整个证书链就可靠，而根证书是否可靠要看这个根证书是否在操作系统或浏览器内置的可信根证书内，在的话就可信。
此部分内容主要参考《SSL/TLS协议运行机制的概述》http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
实际的HTTPS验证过程如下：
对于需要验证用户证书的还会包含请求要求用户提供证书。
客户端收到回应后首先验证服务器证书：
证书没问题的话客户端会回应以下内容：
此时通信双方都有了这三个随机数。通过商定的加密方法根据三个随机数生成一个相同的会话密钥SessionSecret，用于之后的对称加密。
服务器收到回应后计算出SessionSecret，并发送以下内容给客户端：
这样HTTPS握手过程就结束了，之后就是通过HTTP发送经过对称加密的报文。
参考资料：
- 《HTTP权威指南》一书
- 《数字证书原理》http://www.cnblogs.com/JeffreySun/archive/2010/06/24/1627247.html
- 《数字签名是什么？》http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
- 《HTTPS通信中的身份认证机制》https://cnodejs.org/topic/56eb698ec95e8f992473c5a3
- 《SSL证书必知必会：数字证书及CA基础知识》http://liuqunying.blog.51cto.com/3984207/1664246
- 《SSL/TLS协议运行机制的概述》http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
- 《大型网站的 HTTPS 实践（一）—— HTTPS 协议和原理》http://op.baidu.com/2015/04/https-s01a01/
- 《理解 HTTPS 原理，SSL/TLS 协议》https://hacpai.com/article/1447920990604
- 《HTTPS证书生成原理和部署细节》http://www.barretlee.com/blog/2015/10/05/how-to-build-a-https-server/
- 《HTTPS原理学习笔记》http://www.kevenwu.com/blogs/14/
标签：
原文地址：http://blog.csdn.net/chroming/article/details/50995384
