项目做的比较复杂，里面用了https传输通信，但是一直有bug，无法进行调用，怀疑签名问题，所以就深入研究一下这个是啥。

参考：https://yuhongjun.github.io/tech/2020/11/30/看懂HTTPS-证书机构-CA-证书-数字签名-私钥-公钥.html#对称加密

信息传输

传输信息时候，我们有两个大原则是期望能够做到的：

1.传输内容不想轻易被别人看懂
2.传输内容不想被别人篡改

后面弄的一系列套娃可以算是都是为了这个需求，当然可能还有额外一些额外的目标

内容加密

首先我们先来看看如何达到1这个目标：传输内容不想轻易被别人看懂

主要有两个一个是对称加密和非对称加密

对称加密：双方约定一个钥匙，所有传输的内容都用钥匙进行加密，加密后的内容都可以用钥匙进行解密。
对称加密传输过程就变成：

1. 约定钥匙
2. 对内容进行钥匙加密
3. 传输

非对称加密：公私钥。所有内容都可以用私钥加密公钥解密，或者私钥解密公钥加密。
传输过程：

1. 让发送方知道接收方的公钥是什么
2. 让发送方用公钥对内容进行加密
3. 加密内容发送出去
4. 接收方用私钥解密

似乎二者没有什么缺陷，但是有两个问题：

1. 对称加密怎么让对方知道我们约定的钥匙是对的，没有被篡改的
2. 非对称加密速度慢

所以后续采用了混合，用非对称搞定约定密钥，传输过程用对称加密。

似乎又天衣无缝，但问题又来了，仔细看非对称加密的第一个过程。让发送方知道接收方的公钥是什么。如果说发送方知道的是一个假的接收方的公钥怎么办？那么这个假的接收方就可以针对内容进行解析，可以篡改，可以伪造等等。所以依旧没有达到目标

CA

刚刚谈及的最大的问题是，如果发送方知道了错误的公钥那么整个信息传输也是不安全的

所以才有了CA(certification authorization)

这个是用来保证这个公钥一定是正确的发送方

在这里先插入信息的第二个问题：信息如何不被篡改

防篡改

一般信息传输遵从某种格式，假设说黑客知道了这个格式，然后加上一些莫名其妙的字段，这对于发送接收双方也是不能够接收的。

所以才有了签名

发送方对发送内容进行摘要提取，然后对提取之后的信息进行私钥加密

接收方接收到了信息，用同样算法对内容尽心提取，然后用公钥解密，比对这个摘要与自己计算出来的，没问题就说明内容没有被篡改。

细节点：

1. 签名用的是私钥加密，这个私钥一定不会让别人知道，所以这个签名肯定是无法篡改的，这就杜绝了黑客在通信过程篡改信息内容的可能性
2. 但这还是与刚才类似，如果一开始通信的对象就是黑客那该怎么办呢？

所以还是需要回到CA这个认证机构这里。

根据刚才所述，最重要的是，你怎么保证一开始跟你说话的就不是黑客，就是你的目标接收方呢？

所以引入了第三方机构CA，这个是被大家所信任的一个机构，大家只看他签发的，只要是他签发的人，我就相信这一定是我传输的目标。

所以一开始通信时候，大家直接亮出这个CA证书，一看这个CA证书就知道对方一定是我的通信对象

所以这里隐含了一个条件，也就是所有人都相信这个CA，所有人都知道这个CA的公钥是什么

具体过程：

1. 发送方去CA机构认证，把自己相关信息发给CA，里面最关键的就是自己的公钥
2. CA核对这个人的身份，没问题就把CA证书发给发送方。而这个CA证书的构成也有三部分：CA证书内容（含有发送方的公钥） + CA证书的签名算法 + 签名。而这里的签名就是CA机构用自己的私钥对内容提取加密后的结果。
3. 然后发送方与接收方通信时候，直接亮出CA证书
4. 接收方核对CA证书真伪，将内容用证书表示的算法进行计算得到签名，然后将自带的签名用已知的CA公钥解密，比对内容。相同即为真
5. 这样接收方就知道发送方的公钥是什么