项目做的比较复杂，里面用了https传输通信，但是一直有bug，无法进行调用，怀疑签名问题，所以就深入研究一下这个是啥。
参考：https://yuhongjun.github.io/tech/2020/11/30/看懂HTTPS-证书机构-CA-证书-数字签名-私钥-公钥.html#对称加密
信息传输
传输信息时候，我们有两个大原则是期望能够做到的：
1.传输内容不想轻易被别人看懂
2.传输内容不想被别人篡改
后面弄的一系列套娃可以算是都是为了这个需求，当然可能还有额外一些额外的目标
内容加密
首先我们先来看看如何达到1这个目标：传输内容不想轻易被别人看懂
主要有两个一个是对称加密和非对称加密
对称加密：双方约定一个钥匙，所有传输的内容都用钥匙进行加密，加密后的内容都可以用钥匙进行解密。
对称加密传输过程就变成：
- 约定钥匙
- 对内容进行钥匙加密
- 传输
非对称加密：公私钥。所有内容都可以用私钥加密公钥解密，或者私钥解密公钥加密。
传输过程：
- 让发送方知道接收方的公钥是什么
- 让发送方用公钥对内容进行加密
- 加密内容发送出去
- 接收方用私钥解密
似乎二者没有什么缺陷，但是有两个问题：
- 对称加密怎么让对方知道我们约定的钥匙是对的，没有被篡改的
- 非对称加密速度慢
所以后续采用了混合，用非对称搞定约定密钥，传输过程用对称加密。
似乎又天衣无缝，但问题又来了，仔细看非对称加密的第一个过程。让发送方知道接收方的公钥是什么。如果说发送方知道的是一个假的接收方的公钥怎么办？那么这个假的接收方就可以针对内容进行解析，可以篡改，可以伪造等等。所以依旧没有达到目标
CA
刚刚谈及的最大的问题是，如果发送方知道了错误的公钥那么整个信息传输也是不安全的
所以才有了CA(certification authorization)
这个是用来保证这个公钥一定是正确的发送方
在这里先插入信息的第二个问题：信息如何不被篡改
防篡改
一般信息传输遵从某种格式，假设说黑客知道了这个格式，然后加上一些莫名其妙的字段，这对于发送接收双方也是不能够接收的。
所以才有了签名
发送方对发送内容进行摘要提取，然后对提取之后的信息进行私钥加密
接收方接收到了信息，用同样算法对内容尽心提取，然后用公钥解密，比对这个摘要与自己计算出来的，没问题就说明内容没有被篡改。
细节点：
- 签名用的是私钥加密，这个私钥一定不会让别人知道，所以这个签名肯定是无法篡改的，这就杜绝了黑客在通信过程篡改信息内容的可能性
- 但这还是与刚才类似，如果一开始通信的对象就是黑客那该怎么办呢？
所以还是需要回到CA这个认证机构这里。
根据刚才所述，最重要的是，你怎么保证一开始跟你说话的就不是黑客，就是你的目标接收方呢？
所以引入了第三方机构CA，这个是被大家所信任的一个机构，大家只看他签发的，只要是他签发的人，我就相信这一定是我传输的目标。
所以一开始通信时候，大家直接亮出这个CA证书，一看这个CA证书就知道对方一定是我的通信对象
所以这里隐含了一个条件，也就是所有人都相信这个CA，所有人都知道这个CA的公钥是什么
具体过程：
- 发送方去CA机构认证，把自己相关信息发给CA，里面最关键的就是自己的公钥
- CA核对这个人的身份，没问题就把CA证书发给发送方。而这个CA证书的构成也有三部分：CA证书内容（含有发送方的公钥） + CA证书的签名算法 + 签名。而这里的签名就是CA机构用自己的私钥对内容提取加密后的结果。
- 然后发送方与接收方通信时候，直接亮出CA证书
- 接收方核对CA证书真伪，将内容用证书表示的算法进行计算得到签名，然后将自带的签名用已知的CA公钥解密，比对内容。相同即为真
- 这样接收方就知道发送方的公钥是什么