数字签名CA数字证书

对称加密与非对称加密

这是华盛顿大学的官方网页，但浏览器提示网站不安全，很多人知道这是因为没有使用https导致，但具体不安全在哪些方面呢？我们不妨回想一下。当你使用仅支持http的门户网站登录时，输入并发送账号密码给网站，网站验证账号密码无误后，发送带有个人信息的网页给你。这个过程听起来合理，但似乎存在问题。

既然要访问网站就需要用到网络，如果此时有人刻意记录你所有收发的网络信息，你的账号密码会暴露给中间人，门户网站发给你的个人信息网页也会暴露给中间人，这就是没有https的第一个缺点。无法保证数据的机密性，容易泄密。

你们之间的网络通信相当于高清无码的内容，因此必须给内容“打码”。打码后，中间人并非无法知道内容，而是极大地增加了中间人辨认内容的难度。具体一些，你和门户网站之间需要有两把一模一样的私钥，你和网站各自执一把。既然是私钥，当然不能给任何人。这把私钥可以简单理解为某种数学运算，比如发送一串字符时，用这把私钥加密，就会把字符倒过来，明文就变成了密文。

我们假设中间人很笨，看不懂网站发来的密文，收到后用同一把私钥解密，就能得到明文。网站发给你时也是用同样的方法，使用倒叙来加密和解密。这种只用同一把私钥的加密叫做对称加密，中间人不知道私钥的具体内容，就很难进行破解。而且这把私钥是有期限的，你和网站之间的每一次会话都需要一把新的私钥。为了视频的后续讲解，把这样有期限的私钥统称为会话密钥。现在中间人要破解所有会话就更困难了。

听起来很合理，但似乎又不是完全合理。既然你和网站之间需要不能公开的会话密钥，那你们就需要实打实地见上一面，把会话密钥沟通好，再进行网络通信。如果真要这样，你们还愿意上网吗？为了不见面就可以进行远距离网络通信，我们需要巧妙地协商或者发送这把会话密钥给对方 。

网站有一把公钥和一把私钥，用公钥加密的内容只能用私钥进行解密。记住，它们是成对的密钥，就像公鸡和母鸡一起才能下蛋的道理。因此，在网站把公钥发给你以后，你需要生成一串只有你自己知道的神秘字符，并且用收到的公钥进行加密，得到加密后的神秘字符。接着，你需要把加密后的神秘字符发送给网站。网站用谁都不晓得的私钥解密，得到那串神秘字符。于是，你们两边都可以用这串神秘字符生成只有你们知道的会话密钥。在通信过程中，中间人可以得到公钥以及加密后的神秘字符，但是用公钥进行解密是得不到神秘字符的，只能用私钥解密。因为用到公钥和私钥这样的加密叫做非对称加密。

这就解决了如何发送和协商会话密钥的问题，听起来合理，但似乎存在问题。当网站要将公钥发送给你时，中间人拿到公钥后不直接发给你，而是生成自己的一对公钥和私钥，并将自己的公钥发给你。你使用中间人的公钥加密自己生成的字符，中间人再次截获并用私钥解密，修改内容后用网站给的公钥加密修改后的内容。再发送给网站，网站收到后用私钥解密，发现信息能成功解密但已被篡改。

若此时继续生成会话密钥，会产生不同的会话密钥，一边是你和中间人的，另一边是中间人和网站的。你和网站之间并未直接生成会话密钥，中间人可篡改通信内容。因此，非对称和对称加密在此情况下无效，这是没有HTTPS的第二个缺点，即无法保证数据完整性，可能被更改。

数字证书

问题在于，我们无法确定收到的公钥是网站的还是中间人的。这如同西游记里孙悟空与六耳猕猴的争执，两者都声称自己才是真正的美猴王。直至第三方如来佛祖出现才有结果，网络通信也需要第三方来解决公钥信任问题。该第三方简称CA证书颁发机构，于是流程发生变化，在发送加密字符前，网站需将用于加密的公钥提交至受信任的CA。CA根据公钥及其他信息生成数字证书，将公钥与该网站绑定。

回到原流程，网站在与你进行加密协商前，可先发送数字证书给你。你看到数字证书由信任的CA颁发，便从数字证书中提取公钥，以生成最终的会话密钥。

数字签名

听起来合理，但似乎存在问题。我们如何确认数字证书由信任的CA颁发？数字证书上有CA的签名，这与真实生活中的签名相似。比如老师让家长检查孩子作业，为确保作业已被家长检查，会在作业上签写家长大名。在网络通信中，不是用签字笔签名，而是用数字签名给数字证书签名。

再次时光倒流，当CA收到网站的信息及公钥后，会对这些信息及公钥进行哈希运算，得到一串较短的哈希字符。听到这里，你们可能会奇怪为何要进哈希运算。简单来说，哈希运算将一段内容转化为特定的短字符，大大压缩了需要传输的信息。而且这串字符后续还要进行加密和解密，若计算的字符过长，会消耗大量时间。另外，如果内容有哪怕一个字符的修改，最终生成的短字符都会不同，不同的内容会生成不同的哈希字符。这串短字符相当于家长检查作业后给出的分数，对全部内容进行总结。

回到刚才的步骤，在哈希运算后，CA自身也生成一对专门用于数字证书的公钥和私钥，用这把私钥给哈希字符加密，注意用的是私钥。这串加密后的字符就是数字签名。

注意：进行哈希运算并非加密运算，因此这里要对哈希字符进行加密。现在CA就可以把含有CA数字签名的证书发给网站了。虽然数字证书里的网站信息都是明文的，但核心在于CA的数字签名。如果证书里的内容被篡改了，或者公钥被修改了，生成的哈希值会不同，最终的数字签名就会变成另外一串字符。

当你访问网站时，网站会把含有CA数字签名的数字证书发给你。为了证明没有中间人更改过公钥，你需要用到CA签名时生成的公钥，并且用这把CA公钥给数字证书里面的数字签名解密，这样会得到一串哈希字符，毕竟数字签名加密前就是一串哈希字符。这串哈希字符先放着，接着你对收到的数字证书内容进行同样的哈希运算，也得到一串哈希字符，如果前后两串哈希字符一致，说明数字证书是靠谱的，没有被篡改。

我们现在假设中间人修改了数字证书的内容。但是由于中间人没有原本生成数字证书的私钥，因此你收到的数字签名会和数字证书不匹配，除非中间人把数字证书和数字签名同时改得匹配才行，这种情况也只能是拥有私钥才行。没问题的话就可以继续生成会话密钥的步骤了。

看到这里你们可能感到奇怪，一下子私钥加密，一下子公钥加密，是不是有些混乱？这就和可乐既可以用来喝，还可以用来冲马桶是差不多的道理。虽然听着反人类，但事实就是如此，千万不要被一些字面意思给束缚住。不管是公钥加密还是私钥加密，背后的数学原理就是你用了一把进行加密，另一把就只能用来解密。由于应用场景的不同，导致了它们在用法上的不同。

前面说的公钥加密、私钥解密，虽然理论上谁都可以加密，但是加密后只能是拥有私钥的人才能解密，因此用来加密信息就很好。而数字签名则是私钥先加密，公钥再解密，也就是常说的私钥签名、公钥验签。只能是拥有私钥的人才能加密，但理论上谁都能解密，用来验证身份就很好。

证书链

但是刚才还遗留了个问题，我们如何安全地拿到信任CA的公钥呢？

我们不妨再次让时光倒流。当网站向第三方CA申请证书的时候，CA会生成专门给这个网站颁发证书的一对公钥和私钥，并且用自己的私钥给证书签名。网站公钥和私钥用来生成最终的会话密钥，我们是知道了。CA私钥用来给证书签名，我们也知道了。就剩子CA的公钥像孤儿一样被丢在一边。

其实CA也需要数字证书来证明自己的身份，因此会把这把公钥放在自己的数字证书里面，按照数字证书的生成原理，这份数字证书同样也需要另外一把私钥来进行签名，这就需要再加一层，也就是根CA。即网站申请证书时的这个CA只是中间CA，根CA同样需要生成一对专用的公钥和私钥，并且用这把私钥为中间CA的证书签名。根CA既然有这把公钥，也就是说根CA也有自己的证书，但是根CA的证书由谁来签名呢？

会不会是地球CA呢？如果是就没完没了了。根CA需要为自己的证书签名，然后在用户的操作系统和浏览器里面预先安装根CA的证书。这样就可以闭合这一整条证书链了。

这里的核心就是用顶层的私钥给下层的证书签名，验证的时候用顶层的公钥来检验下层的签名。你们可能觉得奇怪，网站可以直接和根CA申请证书，没有中间商赚差价多好。其实我们只需要把这里的结构想象为一棵树就好，如果中间有一根树枝断了，也不至于连根拔起。根CA可以避免与广大的网站服务器直接接触，直接交给中间CA进行接触。如果其中有一家中间CA的私钥被破解了，也不至于影响到全局。因此，根CA的管理十分重要。

证书验证

为了让大家理解这一过程，我们来看看使用了HTTPS的华盛顿大学网站有什么不同。

没错，华盛顿大学提供了HTTP和HTTPS两种方式访问网站。浏览器在进行加密之前，收到网站服务器发过来的证书，上面有串重要的字段，颁发者，也就是谁颁发了这份数字证书。这里有个很重要的缩写CN，不是China的缩写，意思是Common Name，公用名。

但是我的电脑里面并没有这家CA的证书。其实网站是可以把整个证书链发给浏览器的，也有可能网站服务器不发送中间证书，导致有些浏览器可能需要从缓存中找这些证书或者自行下载中间证书。

继续刚才的步骤，浏览器查看这份中间证书的颁发者，发现这里的公用名是User Trust RSA Certification Authority，此时就需要找找电脑里面有没有它的证书，最后成功找到这份根证书，并且提取里面的公钥来验证中间证书的签名。没问题的话，再用中间证书的那份公钥来验证网站证书的签名，都没问题，说明网站的证书没有被篡改。

但是没有被篡改，也还是证明不了这份证书就是属于该网站的。浏览器还会查看主题背景的公用名是否和域名一致。很明显这里是一致的，因此证明这份证书是和该域名绑定的。

这里也说明了，没有用HTTPS的第三个缺点，就是你很难确定访问的是不是官网，毕竟第三方CA在颁发证书之前是会进行网站信息的检查。

当然，我们经常会看到网站域名和公用名CN不一致，因此浏览器还会查看扩展程序里的证书、主题背景的备用名称，接着浏览器还需要检查证书的有效期。若证书到期，需记得续费。

此外，若网站服务器的私钥泄露，并已向CA申请证书的吊销，浏览器如何得知此事呢？此时需依靠CA的证书吊销列表。我们可以在扩展程序的CRL分发点查看并访问该网址以下载此文件。当我们用命令查看这份文件内容时，可以看到被吊销证书对应的序列号。当然，有些浏览器不会去检查此列表，这带来了安全隐患。

另外，证书吊销列表可能并非实时更新，因此有了“在线证书状态协议OCSP”作为替补，使浏览器可以向专门的服务器查看某个证书是否被吊销，以弥补前面方法时效性的问题。不过，这个协议也存在隐私泄露的问题。虽然浏览器还会继续对证书进行审查，但核心部分你们已经了解，我们下次见。