数字签名、数字证书与CA

上周，有同事给我们介绍了什么是数字证书及其工作原理，于是我决定结合自己的理解把这个原理记录下来。

为什么会用到数字证书

在我们上网的时候，为了防止我们的信息被某些钓鱼网站截取，所以我们在与对方进行通信的时候，需要验证对方的身份。那么如何验证对方的身份是真实可靠的呢，就需要对方能够提供数字证书，而且该证书能够被验证是权威的CA颁发的。
举个栗子，比如你要招聘一名清华大学的毕业生，那么你如何确定对方是清华大学毕业的？那么就需要对方提供他的毕业证，而且毕业证上的编号确实是能够在权威网站“学信网”上查到。

什么是数字证书、数字签名及CA

数字签名的过程分为2步：它是由发送方做的，首先把要传送的内容通过哈希算法算出一个固定长度的摘要(一个hash值)，如果摘要相同，则说明信息相同。然后发送方用自己的私钥对摘要进行加密，再把公钥发送给接收方。
数字签名验证过程也分为2步：它是由接收方完成的，首先用发送方发过来的公钥去解之前的摘要密文，这样就得到一个哈希值hash1，然后再当场通过哈希算法计算出明文内容的哈希值hash2，如果hash1=hash2，那么就说明内容没有被篡改(摘要一致)，而且内容是由发送方发过来的，不可抵赖(密钥能用对方的公钥解开)
这个过程可以通俗地理解成：
比如A想给B写一封信，但是又想让B确定这个信是A写的，且信的内容没有被别人篡改，那么A先把信的内容写好，然后A通过哈希算法生成一个摘要(digest)，接着A再用自己的私钥对摘要进行加密，就形成了数字签名(digital signature)，最后A把信和签名一同发送给B。B在收到A的信后，用A的公钥解密数字签名，得到摘要，然后再把信件的内容通过哈希算法得到一个哈希值，再与之前得到的摘要进行对比，如果一致，那么说明信件确实是A发送的，且信件内容没有被修改。
那么问题来了。。。。
（1）摘要已经是内容的hash值了，为什么还要对摘要进行加密后再发送呢？
答：摘要是不能反推出内容，但是有些不怀好意的人可能根本不想知道信件的内容，他就是想让你相信内容是他发送的而已。但是如果摘要需要进行加密，不怀好意的人用他自己的私钥进行加密后，你用真实发送方的公钥是解不开的。所以数字签名可以保证内容确实是由发送方发送的，而且内容没有被篡改。
（2）如果不怀好意的人将你的公钥替换成自己的公钥了该怎么办呢？
答：上面说了，如果你用公钥将文件解密了，那么你就确定这个文件是由对方发过来的，但是如果这个公钥被人做了手脚了呢？比如C偷偷使用了B的电脑，用自己的公钥替换了A的公钥，然后C用自己的私钥做成数字签名，再写信给B，B就用假的公钥解密了假的数字签名。为了解决这个现象，数字证书就诞生了。
数字证书(digital certificate)是由CA(Certification Authority)签发的一种较为权威与公正的电子文档。证书的内容包括：CA的信息，公钥用户的信息，公钥，CA的签名和有效期等等。
CA是颁发数字证书的权威机构，是受大家信任的第三方。如果一个用户想要得到一份属于自己的数字证书，他应先向CA提出申请。在CA判明申请者的身份后，便为他分配一个公钥，并且CA将该公钥与申请者的身份信息绑定在一起，并为之签字，便形成证书发给申请者。
由于B不确定自己拥有的公钥是否来自于A，所以他要求A去权威中心为公钥做认证，CA用自己的私钥，对A的公钥和一些相关信息一起加密，生成数字证书并签名。所以之后如果A再想给B写信，他只需要在签名的同时，再附上数字证书就可以了。B收到信件后，用CA的公钥解开数字证书，就可以拿到A真实的公钥了，然后就能证明信件确实是A发送的。
从下图中可以看出由CA签发的数字证书大概包含什么内容。

根证书(Root Certificate)是由根证书颁发机构(root CA)颁发的公钥证书，也就是说它是自己发给自己的证书，是信任链的起点。一般来说，我们的电脑上面会安装一些信任的证书，windows可以在开始运行中输入certmgr.msc来查看自己的电脑里安装了哪些证书。
有根证书，那么就有中间证书(Intermediate Certificate)，中间证书和根证书是层级关系，可以有多个中间证书。可以通过证书中对应的域找到它的上一级证书。
比如你想通过https访问百度，百度不仅会把自己的证书发过来，还会把给它签发证书的CA的证书发过来。如下图所示。

如果这个证书或者这个证书的根证书在你的电脑里有安装，那么你访问的网站就被认为是安全的网站，反之，浏览器就会弹出安全证书有问题。

有些网站的证书是自己给自己颁发的根证书，而它并不是权威的CA，如果你信任这些网站，就需要在自己的电脑上下载他们的证书安装，比如某些银行的网站，经常需要先安装证书。。。