作者：三一斜狩
链接：https://www.zhihu.com/question/24294477/answer/74783418
来源：知乎
著作权归作者所有，转载请联系作者获得授权。
链接：https://www.zhihu.com/question/24294477/answer/74783418
来源：知乎
著作权归作者所有，转载请联系作者获得授权。
先说加密。
明文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。
然后将P，S连成一个文件，这个文件就是所谓的数字证书了。
现在假设某人得到了这个证书，如何确认这个证书属于谁的呢？
我们看数字证书里有些什么？可以得到P，可以得到S。
我们用同样的hash算法对P进行hash计数，得到一个hash值H1.
P里有公钥，签发者ID，Subject，有效期，及其他信息。我们用公钥解密S，得到了一个值H’。
这个H‘就是制作数字证书的时候，用私钥对S加密的H。
现在对比H’和H1是否相等，如果相等，那么就证明这个证书是有签发者签发给subject的证书。否则就说明：1.内容P被篡改过，或者2.证书不是由CA签发的。
这个是对自签发证书的验证过程。
既然自己可以给自己签发证书，那黑客宣称自己是CA，然后给自己签发一个证书，那验证者如何来验证这个证书是黑客自己的呢还是CA呢？
这个问题，就是CA存在的意义了。
所谓全球权威的CA，就那么几个公司，这几个公司的证书，被各软件厂商设置成可信任的根证书了。至于这些CA是怎么把自己的数字证书交给软件厂商而且让他们信任自己，我也不知道。如果你知道了，你就可以自己给自己签发一个证书，交给微软的IE，或者firefox等，让他们把你的证书嵌入到软件里去。这样一来，你就成了全球权威的CA之一了！
现在知道了，自签发的数字证书，要被各软件信任，是不容易的。
我们举一个例子，说明数字证书用来进行身份认证。就是https连接某网站的时候的身份认证过程。
首先，某网站要有一个数字证书。这个证书，要么是自己签发的，要么是由第三方签发的，一般这个第三方是全球权威的CA。
IE或者firefox用https连上web server，这个时候，IE或者firefox最担心的是这个web server是冒充的网站，怎么确认这个网站是正确的呢？就要去web server提供自己的数字证书来证明自己的身份。
web server把自己的数字证书传给浏览器。浏览器对之进行验证，确认此网站的身份。
现在看这个数字证书怎么证明自己的身份。
假设数字证书是第三方签发的，但这个第三方却不权威。
这个时候，浏览器就会警告用户，说这个网站提供的证书不安全，比如12306网站的：
查看此证书：
签发者是SRCA，应该是这个签发中心签发的：
中铁数字认证中心
这是什么意思呢？
就是说，中铁数字认证中心签发给12306网站的数字证书，其签发者”中铁数字认证中心“，在IE眼里是不受信任的。那IE自然对一个不受信任的签发机构签发的数字证书也认为不安全了。
那么这个数字证书到底能不能证明12306的身份呢？答案是不能。
因为这个证书是由SRCA签发的，也就是需要SRCA的公钥来验证。但是IE并没有得到这个公钥。
如果SRCA将自己的数字证书嵌入到IE里了，IE自然就有了。
既然没有嵌入进IE里，那通过手动添加SRCA到IE里可以吗？当然可以，这就是为什么12306要求安装受信任的根证书的原因。
那么这个安装动作，就要非常小心了。你怎么能确认这个SRCA是一个合法权威的CA呢？一旦安装了这个CA证书，其影响是链式的。
想想看我们为什么安装了12306网站提供的根证书？是基于对12306网站的信任。这个根证书是网站自身提供的，但是我们从新闻联播里，从大众行为里，信任了这个网站，安装了根证书。
我们看看这个证书：
签发者和签发给的人都是SRCA，就是自己给自己签发。但是这个证书，没有人能证明其是否可信任。但是我们，人类，基于对国家的信任，认为其可信任。安装了这个证书之后，在IE里可以查看到它：
然后访问http://12306.cn，就没有警告信息了：
那么SRCA是如何验证12306网站的身份的呢？是如何验证12306提供的数字证书的有效性呢？
以上描述中，对于自签发证书中的公钥的使用，可能对大家有一些误导。实际上，数字证书中的公钥，可以被用来验证其他数字证书，也可以被用来进行两个节点间通信时候的加密密钥（当然实际使用的加密密钥是另一回事情，这里暂且略过）。大多数https网站提供的数字证书的目的，一个是确认身份，一个是加密浏览器与Web Server之间的通信数据。
我们构造一个场景：
假设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中的公私钥对的公钥。当浏览器用SRCA的公钥证书验证了证书之后，就得到了这个公钥。浏览器有12306网站的公钥，12306网站自己也有私钥，二者就可以进行加密通讯了。
具体流程如下：
当用户在浏览器地址栏里输入了12306的网址后，就连接到了12306的网站。网站传输给浏览器一份数字证书CERT_12306。
浏览器根据数字证书内容，发现该证书签名者是SRCA。
浏览器查找系统中受信任的根证书中是否有SRCA的公钥证书。找到了。
浏览器得到SRCA公钥证书中的公钥Pub_SRCA。
用Pub_SRCA解密CERT_12306中的签名部分，得到hash值H1.
浏览器计算CERT_12306中的明文内容，得到HASH值H2，对比H1，H2，验证数字证书有效性。
如果有效，则得到明文内容中的URL，发现正在访问的URL与证书中得到的URL一致，则此次访问正常。身份认证通过。
所以12306数字证书的验证，是使用SRCA公钥证书中的公钥验证的。自签发证书也是用自己证书中的公钥来验证自己的。
也就签名的时候用什么RSA公私钥中的私钥，则验证签名的时候就需要用对应的公钥。
而网站的数字证书提供了公钥，网站自己有私钥。浏览器于是产生一个随机数R1，用公钥加密发给服务器，服务器用私钥解密后，得到这个随机数R1，后续两种就用这个R1作为对称加密的密钥来加密传输的数据。这个大约是SSL协议的简单过程，原理是这样的，细节可能差很多。
假设，有一个坏蛋，不知道用什么方法，让访问http://12306.cn，不再连接到真正的12306网站，而连接到了自己网站，通过数字证书，能够阻止坏蛋做这样的事情吗？
明文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。
然后将P，S连成一个文件，这个文件就是所谓的数字证书了。
现在假设某人得到了这个证书，如何确认这个证书属于谁的呢？
我们看数字证书里有些什么？可以得到P，可以得到S。
我们用同样的hash算法对P进行hash计数，得到一个hash值H1.
P里有公钥，签发者ID，Subject，有效期，及其他信息。我们用公钥解密S，得到了一个值H’。
这个H‘就是制作数字证书的时候，用私钥对S加密的H。
现在对比H’和H1是否相等，如果相等，那么就证明这个证书是有签发者签发给subject的证书。否则就说明：1.内容P被篡改过，或者2.证书不是由CA签发的。
这个是对自签发证书的验证过程。
既然自己可以给自己签发证书，那黑客宣称自己是CA，然后给自己签发一个证书，那验证者如何来验证这个证书是黑客自己的呢还是CA呢？
这个问题，就是CA存在的意义了。
所谓全球权威的CA，就那么几个公司，这几个公司的证书，被各软件厂商设置成可信任的根证书了。至于这些CA是怎么把自己的数字证书交给软件厂商而且让他们信任自己，我也不知道。如果你知道了，你就可以自己给自己签发一个证书，交给微软的IE，或者firefox等，让他们把你的证书嵌入到软件里去。这样一来，你就成了全球权威的CA之一了！
现在知道了，自签发的数字证书，要被各软件信任，是不容易的。
我们举一个例子，说明数字证书用来进行身份认证。就是https连接某网站的时候的身份认证过程。
首先，某网站要有一个数字证书。这个证书，要么是自己签发的，要么是由第三方签发的，一般这个第三方是全球权威的CA。
IE或者firefox用https连上web server，这个时候，IE或者firefox最担心的是这个web server是冒充的网站，怎么确认这个网站是正确的呢？就要去web server提供自己的数字证书来证明自己的身份。
web server把自己的数字证书传给浏览器。浏览器对之进行验证，确认此网站的身份。
现在看这个数字证书怎么证明自己的身份。
假设数字证书是第三方签发的，但这个第三方却不权威。
这个时候，浏览器就会警告用户，说这个网站提供的证书不安全，比如12306网站的：
查看此证书：签发者是SRCA，应该是这个签发中心签发的：
中铁数字认证中心
这是什么意思呢？
就是说，中铁数字认证中心签发给12306网站的数字证书，其签发者”中铁数字认证中心“，在IE眼里是不受信任的。那IE自然对一个不受信任的签发机构签发的数字证书也认为不安全了。
那么这个数字证书到底能不能证明12306的身份呢？答案是不能。
因为这个证书是由SRCA签发的，也就是需要SRCA的公钥来验证。但是IE并没有得到这个公钥。
如果SRCA将自己的数字证书嵌入到IE里了，IE自然就有了。
既然没有嵌入进IE里，那通过手动添加SRCA到IE里可以吗？当然可以，这就是为什么12306要求安装受信任的根证书的原因。
那么这个安装动作，就要非常小心了。你怎么能确认这个SRCA是一个合法权威的CA呢？一旦安装了这个CA证书，其影响是链式的。
想想看我们为什么安装了12306网站提供的根证书？是基于对12306网站的信任。这个根证书是网站自身提供的，但是我们从新闻联播里，从大众行为里，信任了这个网站，安装了根证书。
我们看看这个证书：
签发者和签发给的人都是SRCA，就是自己给自己签发。但是这个证书，没有人能证明其是否可信任。但是我们，人类，基于对国家的信任，认为其可信任。安装了这个证书之后，在IE里可以查看到它：然后访问http://12306.cn，就没有警告信息了：
那么SRCA是如何验证12306网站的身份的呢？是如何验证12306提供的数字证书的有效性呢？以上描述中，对于自签发证书中的公钥的使用，可能对大家有一些误导。实际上，数字证书中的公钥，可以被用来验证其他数字证书，也可以被用来进行两个节点间通信时候的加密密钥（当然实际使用的加密密钥是另一回事情，这里暂且略过）。大多数https网站提供的数字证书的目的，一个是确认身份，一个是加密浏览器与Web Server之间的通信数据。
我们构造一个场景：
假设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中的公私钥对的公钥。当浏览器用SRCA的公钥证书验证了证书之后，就得到了这个公钥。浏览器有12306网站的公钥，12306网站自己也有私钥，二者就可以进行加密通讯了。
具体流程如下：
当用户在浏览器地址栏里输入了12306的网址后，就连接到了12306的网站。网站传输给浏览器一份数字证书CERT_12306。
浏览器根据数字证书内容，发现该证书签名者是SRCA。
浏览器查找系统中受信任的根证书中是否有SRCA的公钥证书。找到了。
浏览器得到SRCA公钥证书中的公钥Pub_SRCA。
用Pub_SRCA解密CERT_12306中的签名部分，得到hash值H1.
浏览器计算CERT_12306中的明文内容，得到HASH值H2，对比H1，H2，验证数字证书有效性。
如果有效，则得到明文内容中的URL，发现正在访问的URL与证书中得到的URL一致，则此次访问正常。身份认证通过。
所以12306数字证书的验证，是使用SRCA公钥证书中的公钥验证的。自签发证书也是用自己证书中的公钥来验证自己的。
也就签名的时候用什么RSA公私钥中的私钥，则验证签名的时候就需要用对应的公钥。
而网站的数字证书提供了公钥，网站自己有私钥。浏览器于是产生一个随机数R1，用公钥加密发给服务器，服务器用私钥解密后，得到这个随机数R1，后续两种就用这个R1作为对称加密的密钥来加密传输的数据。这个大约是SSL协议的简单过程，原理是这样的，细节可能差很多。
假设，有一个坏蛋，不知道用什么方法，让访问http://12306.cn，不再连接到真正的12306网站，而连接到了自己网站，通过数字证书，能够阻止坏蛋做这样的事情吗？