数字证书一步步

       先不谈他的概念，我们先看看它的应用吧：在新版的微信中已经在支付安全中看到了数字证书的身影了，我们可以在微信中启用数字证书或者将其删除。

       支付宝呢，也没有意外，并且还多了一句根据监管部门的要求安装数字证书可提升余额单日额度。

       央行公开发布的条码支付业务规范和技术规范等文件已从今年4月1日开始实施，其中提到了交易验证的三要素并且无论采取哪种支付方式都要求至少满足两条，两大支付软件开启了数字证书功能就很能说通了。

       想弄清楚数字证书的前世今生，还是要从最基本的web访问开始，下面，模拟web数据传输的几个阶段。

        http明文形式的传输如图所示，可以想象成burpsuite里的request和response。

       问题：任何人只要能抓取到我的流量，都可以像上图一样看到我详细的传输信息，这样的话密码就可以改名为明码了，基本失去了其功能。

       这个过程就是在我发送我的http请求时，我先把本地生成的会话密钥发送给服务器（服务端反之），然后我再把用该密钥加密的http请求发送，服务器再用之前获取的客户端密钥解密得到明文请求（或反之）。

       一个问题：这个本地生成的密钥如何共享给对方

       两种方式：

• 带内：请求真实数据前先发送密钥信息，这个时候发送的信息只能是明文吧，我可不是只能抓取真实数据，你传送的密钥数据包照抓不误，然后你用该密钥加密的数据还有意义嘛？

• 带外：很简单，当你想要访问百度的时候呢，先拿U盘去西二旗考一下百度的密钥，然后在回去交给你的浏览器，这样的话，过不了多时，你就以带外传输密钥的借口环游世界了。

       话说上有政策下有对策，好像不对，应该是办法总比问题多，这个时候出来了一种非对称加解密的算法，至于原理不搞密码学暂时不用管当然我也不懂，在这里明白一点，我作为服务器本地生成一对公私钥，公私钥之间只能互为对方加解密；然后我将公钥发给你，你所有的请求都用该公钥加密，而私钥只存在我手里，只有我收到你的请求才能正常的解密得到明文数据进行处理。

       问题：加密方式强度的增大，一方面靠加密算法的改进另一方面还要靠加密位数的大小。攻防始终是个博弈的过程，当我有次买票时看到12306的16张图片验证码时我就X掉了浏览器没有再买票了。非对称加密是个很耗时的过程，假设一次加解密用时3秒，意思可以理解为你去点击一个链接时需要等待2秒才可以看到返回结果，有没有想过任何一个链接都如此，结果会怎样！

       虽然说非对称加密是非常耗时的，但是他呢确实可以安全的将信息发送给所要的人而不被窃听，那也当然可以通过这种方式把我本地生成的密钥安全的传递给对方，这样就解决了2中密钥传送的历史问题。既不用跑去西二旗也不怕被网路监听了，当双方都安全的拿到密钥时，对称加密就可以粉墨登场了。

       有没有问题：利用非对称加密方式获取密钥的前提是首先要拿到对方的公钥，理论上这个公钥可以发给任何人你也可能收到任何人的公钥，怎样确定你收到的公钥就是你自己想要的呢？

       在这个图中，当客户端请求服务端的公钥时被中间人截获，中间人返回了自己本地生成的公钥，客户端也就只能将本地生成的对称密钥使用该公钥加密发送出去，中间人收到时呢私钥解决拿到该对称密钥之后的任何加解密就不是问题了；同时呢，中间人伪装客户端请求服务端的公钥，模拟客户端与服务器的数据在这里加密、解密、加密……

       数字证书包含的内容可以概述为三部分: 用户的信息、用户的公钥、还有CA中心对该证书里面信息的签名。

       上面所说的非对称加密，一个重要特点是：使用公钥加密的数据必须使用私钥才能解密，同样的，使用私钥加密的数据必须使用公钥解密。正是因为这个特点，网站就可以在自己的证书中公开自己的公钥，并使用自己的私钥将自己的身份信息进行加密一起公开出来，这段被私钥加密的信息就是证书的数字签名，浏览器在获取到证书之后，通过证书里的公钥对签名进行解密，如果能成功解密，则说明证书确实是由这个网站发布的，因为只有这个网站知道他自己的私钥（如果他的私钥没有泄露的话）。

       当然，如果只是简单的对数字签名进行校验的话，还不能完全保证这个证书确实就是网站所有，黑客可以在通信中间进行劫持，使用自己的私钥对网站身份信息进行加密，并将证书中的公钥替换成自己的公钥，这样浏览器同样可以解密数字签名，签名中身份信息也是完全合法的。下面介绍一个重要机构：CA。

       CA全称为Certificate Authority，证书授权中心，它是专门负责管理和签发证书的第三方机构。因为证书颁发机构关系到所有互联网通信的身份安全，因此一定要是非常权威的机构，像GeoTrust、GlobalSign等等。

       如果一个网站需要支持HTTPS，它就要一份证书来证明自己的身份，而这个证书必须从CA机构申请，大多数情况下申请数字证书的价格都不菲，不过也有一些免费的证书供个人使用。

       如果用户想得到一份属于自己的证书，需要向CA机构提供网站域名，营业执照，以及申请人的身份信息等。网站的域名非常重要，申请人必须证明自己对域名有所有权，一个证书一般只绑定一个域名， CA机构也提供申请通配符域名（例如，*.guokr.com），通配符域名相当于绑定了主域名下的所有域名。在CA判明申请者的身份后，便为他分配一个公钥，并且CA将该公钥与申请者的身份信息绑在一起，并为之签字后，便形成证书发给申请者。如果一个用户想鉴别另一个证书的真伪，他就用CA的公钥对那个证书上的签字进行验证，一旦验证通过，该证书就被认为是有效的。通过这种方式，黑客就不能简单的修改证书中的公钥了，因为现在公钥有了CA的数字签名，由CA来证明公钥的有效性，不能轻易被篡改，而黑客自己的公钥是很难被CA认可，所以无用担心证书被篡改的问题。

       下面以百度的证书举个栗子：

       当我们访问百度时，可以看到浏览器URL栏中的一个锁，点击它即可查看百度的证书信息，如下：

       在图中可以看到证书的唯一目的：保证远程计算机的身份。该证书颁发给：baidu.com ，这样的话www.baidu.com  / map.baidu.com等子域都可以用，之后还有颁发者信息和有效日期。

       如果个人网站只为加密传输也可以自己制作SSL证书，自己制作的证书不会受到浏览器的信任，在访问的时候由于证书验证失败而给出警告，添加信任即可。

       证书路径：我们可以这样理解，根CA机构就是一个公司，根证书就是他的身份凭证，每个公司由不同的部门来颁发不同用途的证书，这些不同的部门就是中级CA机构，这些中级CA机构使用中级证书作为自己的身份凭证，其中有一个部门是专门颁发SSL证书，当把根证书，中级证书，以及最后申请的SSL证书连在一起就形成了证书链，也称为证书路径。

       根证书是最关键的一个证书，如果根证书不受信任，它下面颁发的所有证书都不受信任。操作系统在安装过程中会默认安装一些受信任的CA机构的根证书，可以在“运行”里面运行“certmgr.msc”启动证书管理器，如下图所示：

       当浏览器收到数字证书时，首先去判断该证书的颁发机构是否在我的受信任的机构中，如果不在浏览器中直接警告用户；如果在的话，1方面用CA公钥解密数字签名得到消息摘要，再将server公钥利用相同的hash算法再次得到一个消息摘要，对比两次的结果保证证书的完整性……

       该过程仅以图展示还比较条理：

       通过以上的内容基本描述了在通信过程中数字证书从它的诞生到如何一步步保证我们信息传输的安全，对于绝大部分的网站来说已经可以达到安全要求，但相比于电子银行等涉及交易的系统时单方面的认证似乎还存在一些隐患，那对于这类安全性要求更高系统该怎么做呢，数字证书在电子银行类系统中又是怎样的一个认证过程呢，下一篇继续。

       到此文章结束，其中细节若出现错误还请不吝赐教，顺祝时祺。