关于公私钥、各种证书、https基本概念扫盲

Posted 2023-03-25

参考技术A

最近实习需要写一些生成证书的脚本，借此机会顺便搞清楚了许多关于证书这块的疑惑。说到这一块东西，名词多到爆炸，对称加密、非对称加密、密钥、密钥库、公钥、私钥、CA、证书、数字签名、ssh、https、ssl、keytool、openssl、PKCS、X.509以及令人眼花缭乱的文件后缀名，cer、crt、pem、keystore、jks、key、p12、pfx...

先听我讲个故事，这次我们不用Bob和Alice,听完之后再去看这些概念，绝壁恍然大悟。

故事背景: 这是2018年，为了能够安全的进行通信，假设每个人都有俩把锁，一个叫A锁，一个叫B锁，这俩把锁和一般的锁有点区别，每把锁上即带有自己的锁孔又带有另一把锁的钥匙，因此A锁和B锁既是锁又是钥匙。 A锁和B锁唯一配对，A锁锁住之后，只有B锁可以打开，同样B锁锁住之后，只有A锁可以打开 。其中一把锁是公开的，而一把锁则自己保管，不公开。假设默认A锁是公开的，B锁是私有的。

故事内容: 阿里巴巴子弟小学的小明想给隔壁班的小花写封表白信，为了不被别人看到，他将信放入在信箱中，并用小花的A锁将信箱锁住，因为小花的B锁(同是A锁的钥匙)只有小花自己有，所以除了小花以外的任何人拿到信件，都无法看到信件内容。同样小花要给小明写信，那么也要用小明的A锁对信件内容进行保护。

小明与小花通过就这样聊了有一段时间，后来小花觉得差不多了，可以进入秀恩爱的阶段了，跟小明说，以后写信别tm加密了，又不是银行卡密码，被人看到又能怎么样呢？只要看了之后别瞎改就行了。于是小明在写完信后，把信里每个字的拼音首字母拼凑了一个字符串，并取名为 消息摘要 ，然后仅仅将消息摘要放入信箱，用自己的B锁锁住这个信箱。虽然信件本身没有放入安全的信箱，但小明作为一个情书高手，随便一封信都是上万字，如果其他人对信件内容做任何改变，那么拼音首字母组成的字符串几乎肯定会改变，因此小花拿到信件后，先用小明的A锁(B锁的钥匙)打开信箱，拿到小明的摘要,然后小花再对信件内容做同样的处理(即计算信件每个字的拼音首字母，实际上不会用这么简单的算法，而是会用不可逆的hash算法)，计算出的字符串值如与小明的信息摘要一致，说明这封信就是小明写给自己的，没有被任何人篡改。

故事高潮: 事情并没有那么简单，小花发现小明只是在信件里对自己热情似火，平常见了面连声招呼都不打，一副不认识的样子。终于有一天小花忍不住了，当面质问小明，小明却说，我什么时候给你写情书了，自作多情吧...于是小花把昨天刚收到的情书狠狠甩在了小明脸上:“上面落款不是你小明吗？怎么了,怂了？”小明一看上面还真是自己的名字，但是自己写没写信自己还不知道吗？小明把自己的作业本拿给小花，并叫自己的同桌做笔迹鉴定，小花发现笔迹的确不大像，看来是有人恶作剧，冒充小明给自己写情书，哎，好尴尬啊。。。

故事讲完了，文章开头涉及的所有概念都与信息的安全传输有关，可以说，一切都是为了安全。关于通信安全，我们通常有三个基本的需求

我们以上面的故事为例说一下这三点安全需求，一开始小明与小花通过A锁( 对应公钥 )加密,B锁( 对应私钥 )解密的通信方式即符合第一点，信件内容本身被加密，而因为公私钥唯一配对，只有配对的密钥才可以解密，因此很难被第三人破解。

之后，为了秀恩爱，他们采用了B锁( 私钥 )加密，A锁( 公钥 )解密的通信方式，其中用私钥对消息摘要加密后的字符串称为 数字签名 ,这样虽然信件可以被人直接看到，但如果被人篡改掉后可以轻易发现数据被篡改。本来以为满足第一条和第二条就可以安全的通信了，但最后才发现小明根本不是小明！为什么会出现这样的问题？因为“小明”说他是小明，小花就以为他是小明，他没有提供任何证明自己真的是小明的认证。因此要想安全通信，我们还需要一个权威第三方的机构来做身份认证,这个机构就是CA机构，通过认证后，CA机构会颁发权威的证书，而有了证书就可以证明身份，就不会出现身份被假冒的情况。而认证的过程则需要向CA机构提供自己的身份信息以及私钥。

对称加密就是通信双方或多方采用的密钥是一样的。加解密速度快，但不够安全。因为一旦密钥泄露，谁都可以对数据进行解密。非对称加密就是当然就是通信双方使用的密钥不同。而公钥和私钥就是非对称加密的一种方式。比较常用的对称加密算法如
AES、DES，非对称加密比较常见的则有sha256,RSA。
非对称加密算法有俩个密钥，一个公钥，一个私钥。公钥和私钥必须配对出现，一对公钥和一个私钥统称为一个 密钥 ，而 密钥库 中可以存放多个密钥，即多对公私钥。

如果你用github的话，应该注意到github链接有俩种方式。一种是https,一种是ssh,通过https经常需要输密码，而通过ssh则不需要。回忆你设置ssh的步骤，本地生成了一个密钥对，并将公钥上传到了github。每次传输用自动本地私钥加密，服务器用你上传的公钥解密，就不需要手动输入密码了。

keytool和openssl是俩个证书管理工具.keytool是java JDK自带的证书管理工具，使用keytool可以生成密钥，创建证书。只要装了jdk,并正确设置了环境变量，就可以之间通过命令行执行keytool命令来管理证书。
openssl则是一个开源的安全套接字层密码库，功能比keytool更加丰富。

PKCS全称Public-Key Cryptography Standards 即公钥标准，PKCS已经发布了15个标准。
PKCS#12 包含了公钥和私钥的二进制格式的证书形式，以pfx作为证书文件后缀
X.509 则是一个通用的证书标准，规定了证书应该包含哪些内容，X.509通常有俩种编码方式，一种是二进制编码，另一种是base64编码
X.509#DER 二进制格式证书，常用后缀.cer .crt
X.509#PEM 文本格式证书，常用后缀.pem

因为http是明文传输，非常不安全，因此又提出了ssl(Secure Sockets Layer即安全套接字)层协议，即在原来的基础上又加了一层协议用于保障安全传输,可以认为https=ssl+http。很多人刚开始接触https，用浏览器F12打开控制台后。可能发现数据仍然没有加密。要注意https是 传输层加密 ，浏览器F12控制台你看到的还是应用层的数据。
因为本文主要是概念扫盲，帮助理解，因此关于这部分具体细节不作介绍。

.keystore和.jks和.truststore都是java用来存放密钥的文件
.key nginx中私钥文件
而不同的证书文件后缀都是为了区分不同种类的证书的，主要有俩个分类维度

公私钥，数字证书，https

1、密钥对，在非对称加密技术中，有两种密钥，分为私钥和公钥，私钥是密钥对所有者持有，不可公布，公钥是密钥对持有者公布给他人的。

 

2、公钥，公钥用来给数据加密，用公钥加密的数据只能使用私钥解密。

3、私钥，如上，用来解密公钥加密的数据。

4、摘要，对需要传输的文本，做一个HASH计算，一般采用SHA1，SHA2来获得。

5、签名，使用私钥对需要传输的文本的摘要进行加密，得到的密文即被称为该次传输过程的签名。

6、 签名验证，数据接收端，拿到传输文本，但是需要确认该文本是否就是发送发出的内容，中途是否曾经被篡改。因此拿自己持有的公钥对签名进行解密（密钥对中的 一种密钥加密的数据必定能使用另一种密钥解密。），得到了文本的摘要，然后使用与发送方同样的HASH算法计算摘要值，再与解密得到的摘要做对比，发现二 者完全一致，则说明文本没有被篡改过。

上面实际上介绍了加密解密和数字签名两个概念和实现过程，二者的过程正好是相反的。

在 签名的过程中，有一点很关键，收到数据的一方，需要自己保管好公钥，但是要知道每一个发送方都有一个公钥，那么接收数据的人需要保存非常多的公钥，这根本 就管理不过来。并且本地保存的公钥有可能被篡改替换，无从发现。怎么解决这一问题了？由一个统一的证书管理机构来管理所有需要发送数据方的公钥，对公钥进 行认证和加密。这个机构也就是我们常说的CA。认证加密后的公钥，即是证书，又称为CA证书，证书中包含了很多信息，最重要的是申请者的公钥。

CA 机构在给公钥加密时，用的是一个统一的密钥对，在加密公钥时，用的是其中的私钥。这样，申请者拿到证书后，在发送数据时，用自己的私钥生成签名，将签名、 证书和发送内容一起发给对方，对方拿到了证书后，需要对证书解密以获取到证书中的公钥，解密需要用到CA机构的”统一密钥对“中的公钥，这个公钥也就是我 们常说的CA根证书，通常需要我们到证书颁发机构去下载并安装到相应的收取数据的客户端，如浏览器上面。这个公钥只需要安装一次。有了这个公钥之后，就可 以解密证书，拿到发送方的公钥，然后解密发送方发过来的签名，获取摘要，重新计算摘要，作对比，以验证数据内容的完整性。

HTTPS是综合用了加密解密和数字签名的实例，理解了上述概念和过程，结合密钥对交换的过程就不难理解HTTPS。

ca机构在公私钥体系中承担了公钥合法性的检验工作。