这篇文章记录了我认识https加密原理的全过程，全篇几乎没有专业词汇用最通俗的文字进行表达（其实是自己比较捞），希望能对理解https和数字证书原理有困难的朋友有所帮助 2019-11-08 17:19:54

对https的一点认识和感悟

从Chrome直接对所有http网站标为不安全开始，我就对https产生了兴趣，也去了解了一些加密知识，直到现在才有了一个比较模糊的认识

一、从明文到加密通信谈起

1. http协议是明文通讯，很不安全，很容易遭受中间人攻击，被截获后可以直接读出真实信息，也容易被篡改，造成信息泄露等后果；
2. 于是乎可以考虑加密通信，比如历史上有著名的凯撒密码等等，这种手段就需要把加密手段告诉对方，但是互联网通信是公共信道，怎么把加密/解密方法安全送给对方呢；

二、非对称加密和对称加密

1. 现在提两个概念：对称加密和非对称加密，对称加密就是加密秘钥和解密秘钥相同的加密方式，而非对称加密的加***和解***是不同的，非对称加密被发明至今不过半个世纪的时间。

2. 显然，对称加密不能胜任上文提到的场景任务，而非对称加密就可以解决这个问题：

   1. A向B发起通信请求
   2. B生成一个私钥和一个公钥
   3. 说明：被私钥加密后的密文只能被公钥解密，被公钥加密后的密文只能被私钥解密
   4. 然后B把公钥以明文形式发送给A
   5. A收到公钥之后就可以用公钥加密信息发送给B，B也可以用私钥加密信息发送给A

3. 看起来很安全，但是，这种手段仍然存在被中间人利用的漏洞：

   1. 在B发送公钥给A的时候，中间人C截获公钥
   2. 中间人C自己生成一对公私钥，然后把自己的公钥发送给B
   3. B收到的是C的公钥，用C的公钥加密明文信息P得到密文S发送给A
   4. 此时C又截获B发给A密文S，然后用自己的私钥解密密文S得到明文P
   • 此时已经能够说明这个方式不够安全了，就不再继续说明了

4. 反思一下，这个非对称的加密手段的问题就在于B不能确定收到的公钥是不是A的，如果能解决这个问题，中间人便无机可乘

三、CA和证书

1. 考虑一下自己在生活中是怎么证明自己是自己的：身份证，我们为什么相信身份证？答：身份证是*发的，我们肯定认为*是可以信任的
2. 然后我们为什么相信身份证？答：身份证是*发的，我们肯定认为*是可以信任的
3. 在上文中如果有一个机构能帮助我们证明B收到的公钥是A的，问题就解决了，即给A发一个身份证，身份证上有A的公钥，与A通信之前先看他的身份证
4. 这个机构就是CA(Certificate Authority)，身份证就是数字证书，数字证书由CA签发。
5. 现在的信任问题就转移到这个数字证书上面了，只要数字证书是真的，证书上面的公钥就是真的，我们就可以安全通信，那么如何保证数字证书是真的呢？

四、证书的签发与证书链

1证书的签发

1. 首先说明：①CA的身份是权威的证书签发机构，这是整个数字证书信任体系的基石，即CA本身是可信的，如果CA不可信了，整个信任体系就不能成立；②下文仅讨论数字证书的一部分构成
2. 网站A向CA申请证书签发时，和之前提到的非对称加密通信类似，CA会生成一对公私钥。
3. 公钥发送给A，A用CA的公钥加密自己的”申请书“，上面包含一些自己的基本信息，包括A自己的公钥，域名等；
4. CA收到后使用自己的私钥把A的公钥，域名等信息加密，这个过程叫签名，得到的密文就叫数字签名，数字签名与A的明文个人信息组合在一起就成为数字证书。
5. 与A通信时，B用CA的公钥解密数字签名与明文一比对，能对上，就说明证书是真的，即证书不可伪造，不可篡改。
6. 至此，虽然证书本身不可篡改，但似乎又出现了CA公钥是不是真的的问题，是不是就进入了一个鸡生蛋蛋生鸡的问题？当然不是！解决方案如下：
7. 需要说明的是：与CA通信时其实并不是只接收CA的公钥，而是也是验证CA的证书，即CA也是有证书的。
8. 而CA的证书（公钥）其实根本就用不着在互联网上传播，而是采用出厂即内置的办法，比如Chrome浏览器会直接内置CA自己的证书，多数操作系统也是在安装的时候就会一同安装CA自己的证书，CA的证书是自己给自己签发的（实际上只有根CA的证书是这样的，根CA的证书称为根证书，后面会说明，这里可以忽略这个说法，为便于理解就先假定CA的证书都是自己签发的），也是大家公认的，在验证来自CA的信息的时候，直接从硬盘中读取CA的证书（公钥），至此，问题就顺利解决了。

2证书链

1. 前面提到只有根证书是根CA自己签发的，我之前看了很多介绍证书的文章很多是这样解释证书链的：讲的是与站点A通信时用CA的证书（公钥）验证A的证书，而验证CA的证书时又用上一级CA的证书（公钥）验证这个CA的证书…直到根CA那里为止，可以先忽略这里的第一条和第二条内容，直接从3开始看
2. 我不准备这样记载和说明这个过程，而是倒过来说明，从根CA开始
3. 前面说了CA的证书会被内置，CA是可以有很多的，而且可以越来越多，这样就需要添加内置的证书，怎么更新呢，上互联网上去更新吗，我上了这么久的网也没见过要求下载证书的（12306除外，等会另外说）
4. 根据前文约定，CA的证书是自己给自己签发的，从互联网上下载证书就又出现了安全问题，所以一般不要从互联网上下载证书添加到内置证书库里。那这个问题怎么解决呢？
5. 现在的真实情况是电脑、手机和浏览器等等厂商都内置了一定数量的证书，而这些证书已经足够让我们验证互联网上的所有身份信息而不需要另外安装证书，那么是怎么做到的呢？
6. 答：通过证书链。
7. CA可以有很多，但是根CA不多，根CA是最最上层的CA，是最为权威和可信的存在，而他们可以给新成立的次级CA发证书，这个发证书的手段恐怕就不是通过互联网了，可以通过U盘/硬盘/打印/手写等方式颁发。总之是可以确保这个过程是安全的方法，然后这个次级CA就可以给用户网站发证书了。
8. 验证证书链举例：

假设

1. 网站：A向CA：B申请到一个证书N，
2. B自己的证书M是根CA：C签发给B的
3. C的证书：P是自己签发给自己的

此时用户U访问A，得到A的证书N,发现是B签发的（证书里面包括签发者与被签发者的信息），U发现自己的没有内置B的证书M，于是验证M，发现是C签发的，而U自己内置了C的证书P，验证用P验证M通过，再用M验证N，通过则说明通信可信

3 12306要求安装证书

1. 从前面的说明，已经了解到从互联网上安装证书是不安全的，并且由于证书链的缘故，其影响是链式的

2. 因此12306要求我们安装证书本来就不合理

3. 我们看看12306让我们安装了什么证书

4. 证书链的顶端是SRCA，对话框下面提示了这个根CA没有内置，因此可以认为不安全

5. 那这个SRCA是个什么？全称Sinorail Certification Authority，中铁数字证书认证中心，搞了半天就是自己给自己发了个证书然后自己当上了根CA

6. 当然现在的12306没有这么搞了，还是遵守了国际规则，现在他的证书是这样的