加密和解密

先说加密。
明文P，加上密码W一混淆之后，变成密文M
如果不知道W，则无法从M反推回P。也就是无法进行解密。
类似这种加密方式，称为对称加密。也就是加密、解密使用的密码是一样的。
实际上加解密并不是直接使用密码，而是经由密码生成的密钥。
这种算法有很多，比如AES。

另外还有一种神奇的加解密算法，叫做非对称加密。比如RSA。
非对称加密使用的密码有一对，一个称为公钥Pub，一个称为私钥Priv。
明文P，经过公钥Pub使用RSA加密算法一混淆之后，变成了密文M。这个密文M，用公钥Pub是解不开的，需要用私钥Priv来解密。
同样地，明文P，经过私钥Priv使用RSA加密算法一混淆之后，变成了密文M。
这个M，也只能用公钥pub来解密。
所谓公钥，就是可以公开出去可以供所有人使用的密钥。不像对称加密里的密码，要小心翼翼的存着。

还有一种算法，叫做hash算法。是单向加密。就是只能从明文得到密文，却无法从密文得到明文。这种算法有一个好处，就是明文哪怕只有一位不一样，加密后得到的密文也不一样。所以常用来进行比较明文是否被篡改过。

数字证书

有了以上的基础，就可以开始说数字证书了。

证书的组成

首先，有一个权威的证书签发机构，称为CA——全球就那么几个公司比较权威啦，这个机构，先用RSA产生一对公私钥。
私钥自己留着藏起来，你要是能偷到手就厉害了。
然后用自己的私钥对自己的公钥进行签名，生成所谓的数字证书。
这个过程大概是这样的：
先生成一个文件，文件内容大概是这样的：
- 公钥内容
- 签发者ID—-谁签发的证书
- Subject—-也就是这个证书签发给谁。这里subject和签发者ID相同。
- 有效期
- 其他信息
以上内容都是明文。我们称为内容P。

然后使用hash算法，对内容P进行hash计算，得到一个hash值H。
然后使用签发机构的私钥对H进行RSA加密，得到签名信息S。这个步骤称为签名，就是用私钥对某公开内容的hash值进行加密。

然后将P，S连成一个文件，这个文件就是所谓的数字证书了。所以数字证书里，包括证书持有者的身份信息，证书信息，证书持有人的公钥，以及签名信息。

证书的验证

现在假设某人得到了这个证书，如何确认这个证书属于谁的呢？
我们看数字证书里有些什么？可以得到P，可以得到S。
我们用同样的hash算法对P进行hash计数，得到一个hash值H1。
P里有公钥，签发者ID，Subject，有效期，及其他信息。我们用公钥解密S，得到了一个值H’。
这个H‘就是制作数字证书的时候，用私钥对S加密的H。
现在对比H’和H1是否相等，如果相等，那么就证明这个证书是有签发者签发给subject的证书。否则就说明：1.内容P被篡改过，或者2.证书不是由CA签发的。
这个是对自签发证书的验证过程。需要说明的是，这种自签发证书的验证不常使用，但如何验证证书的原理类似。

证书管理机构 - Certificate Authority

既然自己可以给自己签发证书，那黑客宣称自己是某著名CA，然后给自己签发一个证书。那验证者如何来验证这个证书是黑客自己的呢还是那个著名的CA呢？
如果仅仅按照上文所说的自签发证书验证过程来看，是无法确认身份的。这个问题，就是CA存在的意义了。

所谓全球权威的CA，就那么几个公司，这几个公司的证书，被各软件厂商设置成“可信任的根证书”了。至于这些CA是怎么把自己的数字证书交给软件厂商而且让他们信任自己，我也不知道。
如果你知道了，你就可以自己给自己签发一个证书，交给微软的IE，或者firefox等，让他们把你的证书嵌入到软件里去。这样一来，你就成了全球权威的CA之一了！
现在知道了，自签发的数字证书，要被各软件信任，是不容易的。一旦CA的根证书存在用户的系统了，就可以用这个根证书来验证其他证书了。并用被验证过的证书来认证身份。

我们举一个例子，说明数字证书用来进行身份认证，就是https连接某网站的时候的身份认证过程。
首先，某网站当然是一个web服务器，它要有一个数字证书。这个证书，要么是自己签发的，要么是由第三方签发的，一般这个第三方是全球权威的CA。
IE或者firefox用https连上web server，这个时候，IE或者firefox最担心的是这个web server是冒充的网站，比如我登录某银行网站，结果连上了一个钓鱼网站，用户也没有发现，就在这个钓鱼网站做的和真网站一样的页面里，输入了自己的用户名密码，岂不是就这么泄露了机密信息么？
那么怎么确认这个网站是正确的呢？这个就需要浏览器要求web server提供自己的数字证书来证明自己的身份。
网站的身份是什么？域名，比如https://www.zhihu.com。你如果打了https://www.zihu.com，也出现跟知乎一样的网站，浏览器没有警告你说此网站不合法，结果你输入了自己的用户名和密码登录，你觉得这个是什么问题？

继续刚才的话题。浏览器要求web server的证书来证明我在浏览器中输入的网址，并没有连接到错误的网站上去，于是web server把自己的数字证书传给浏览器。浏览器对之进行验证，确认此网站的身份。

请注意两个情况的区别：一，我在浏览器输入https://www.zhihu.com，连接到了黑客的钓鱼服务器，而没有连接到真正的服务器；二，我在浏览器输入https://www.zihu.com,连接到了一个黑客的钓鱼服务器。

现在我们继续看这个数字证书怎么证明自己的身份。
假设数字证书是第三方签发的，但这个第三方却不权威。也就是说，给网站签发证书的这个CA，没有被IE等浏览器认可。

一个12306的例子

这个时候，浏览器就会警告用户，说这个网站提供的证书不安全，比如一台干净的新系统，第一次访问12306网站的时候，提示：

这个警告的意思是说，证明该网站身份的数字证书，无法确认真假。既然数字证书无法确认真假，那自然也就无法确认我输入的网址是否连接到了真正的服务器了。

我们也可以在浏览器查看此证书。查看12306网站的证书，内容是这样的：

签发者是SRCA，这是什么意思呢？
就是说，中铁数字认证中心签发给12306网站的数字证书，其签发者”中铁数字认证中心“，在IE眼里是不受信任的。那IE自然对一个不受信任的签发机构签发的数字证书也认为不安全了。那么这个数字证书到底能不能证明12306的身份呢？答案是不能。

因为这个证书是由SRCA签发的。也就是说，12306网站的数字证书，是用SRCA的私钥签名过的。
回忆一下签名的意思，就是用私钥对公开内容的HASH值进行加密。这里的公开内容，就是12306的数字证书中的身份信息，12306网站公钥，证书信息等内容；而签名，就是SRCA的私钥对12306的数字证书部分公开内容的HASH值的加密。
既然是用SRCA的私钥签名过的，就必须使用SRCA的公钥来验证这个签名。
但是SRCA的公钥在哪里？怎么能证明这个公钥就是SRCA的而不是其他黑客的？这就回到了最初的CA存在意义的问题那里了。我们无法证明。
所以IE并没有SRCA的公钥。如果SRCA将自己的数字证书嵌入到IE里了，IE自然就有了。
既然没有嵌入进IE里，那通过手动添加SRCA到IE里可以吗？当然可以，这就是为什么12306要求安装受信任的根证书的原因。

那么这个安装动作，就要非常小心了。你怎么能确认这个SRCA是一个合法权威的CA呢，或者说，你怎么能证明你下载的这个CA证书，真的就是SRCA的呢？一旦安装了这个CA证书，其影响是链式的。
想想看我们为什么安装了12306网站提供的根证书？是基于对12306网站的信任。这个根证书是网站自身提供的，但是我们从新闻联播里，从大众行为里，信任了这个网站，安装了根证书。同样地，IE里内嵌的根证书我们为什么相信它？人为的被逼的相信，不相信就没有办法建立完整的安全链！

我们看看从12306网站下载的SRCA的CA证书：

签发者和签发给的人都是SRCA，就是自己给自己签发。但是这个证书，没有人能证明其是否可信任。但是我们，人类，基于对国家的信任，认为其可信任。安装了这个证书之后，在IE里可以查看到它。

那么SRCA是如何验证12306网站的身份的呢？是如何验证12306提供的数字证书的有效性呢？
也就是受信任的根证书，如何来验证网站的数字证书的呢？

在以上描述中，对于自签发证书中的公钥的使用，可能对大家有一些误导。实际上，数字证书中的公钥，可以被用来验证其他数字证书，也可以被用来进行两个节点间通信时候的加密密钥（当然实际使用的加密密钥是另一回事情，这里暂且略过）。大多数https网站提供的数字证书的目的，一个是确认身份，一个是加密浏览器与Web Server之间的通信数据。

我们构造一个场景：
假设SRCA的公钥证书已经被用户添加为受信任的根证书。也就是SRCA的公钥存于用户的计算机系统中了。而SRCA的私钥存在于SRCA公司董事长的某个保险柜里。

首先是12306网站向SRCA申请数字证书。
12306网站申请数字证书的时候，需要提供一些信息，主要包括：12306的URL，12306自己产生的一对RSA公私钥对中的公钥，其他一些相关信息。
SRCA就用自己的私钥对12306的申请内容进行签名，形成一个数字证书，还给12306网站。
所以这个证书里，包括了：
1. 12306网站的URL
2. 12306网站使用的RSA公私钥对中的公钥。
3. 证书签发者的信息。
4. 证书签名。
在12306网站里，于是就有一个数字证书，还有一份该数字证书中的公钥对应的私钥，这对公私钥是12306自己产生的。其中数字证书由SRCA的私钥签名了。而SRCA的公钥已经存在于用户浏览器中。12306网站的数字证书中包括了12306中的公私钥对的公钥和URL。

当浏览器连接到12306，要求网站提供证书证明自己身份的时候，网站传输数字证书给浏览器（一个小问题，这个传输过程安全吗？）。
浏览器得到12306的证书后，发现证书的签发者是SRCA，就用SRCA的公钥证书验证证书；确认数字证书确实属于12306之后，也就是输入的网址连到上的服务器是真正的12306网站的服务器，没有跑偏，因为这个网站提供了能够证明身份的数字证书而且数字证书中的URL与访问的URL是一致的；还从12306网站提供的数字证书中就得到了公钥，这个公钥是网站自己产生的，于是浏览器有12306网站的公钥，12306网站自己也有私钥，二者就可以用这对公私钥进行加密通讯了（当然实际通信过程的加密不是这样的，有一些变化）。
具体流程如下：
1. 当用户在浏览器地址栏里输入了12306的网址后，经DNS解析，连接到了12306的网站的某台服务器。12306网站传输给浏览器一份数字证书CERT_12306。
2. 浏览器根据数字证书内容，发现该证书签名者是SRCA。
3. 浏览器查找系统中受信任的根证书中是否有SRCA的公钥证书，找到了。
4. 浏览器得到SRCA公钥证书中的公钥Pub_SRCA。
5. 用Pub_SRCA解密CERT_12306中的签名部分，得到hash值H1。
6. 浏览器计算CERT_12306中的明文内容，得到HASH值H2，对比H1，H2，验证数字证书有效性。如果有效，则得到明文内容中的URL，发现正在访问的URL与证书中得到的URL一致，则此次访问正常。身份认证通过。

所以12306数字证书的验证，是使用SRCA公钥证书中的公钥验证的。因为12306网站数字证书是SRCA签发的，就必须用SRCA公钥验证。
自签发证书，是用自己证书中的公钥来验证自己的。因为自签发证书是自己的私钥签发的，所以需要使用自己的公钥验证。
也就签名的时候用的什么公私钥对中的私钥，则验证签名的时候就需要用对应的公钥。

而网站的数字证书提供了公钥，网站自己有私钥。浏览器于是产生一个随机数R1，用公钥加密发给服务器，服务器用私钥解密后，得到这个随机数R1，后续两者就用这个R1作为对称加密的密钥来加密传输的数据，这个大约是SSL协议的简单过程。

作者：三一斜狩
链接：https://www.zhihu.com/question/24294477/answer/74783418
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。