最近实习需要写一些生成证书的脚本，借此机会顺便搞清楚了许多关于证书这块的疑惑。说到这一块东西，名词多到爆炸，对称加密、非对称加密、密钥、密钥库、公钥、私钥、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机构提供自己的身份信息以及私钥。
对称加密 VS 非对称加密
对称加密就是通信双方或多方采用的密钥是一样的。加解密速度快，但不够安全。因为一旦密钥泄露，谁都可以对数据进行解密。非对称加密就是当然就是通信双方使用的密钥不同。而公钥和私钥就是非对称加密的一种方式。比较常用的对称加密算法如
AES、DES，非对称加密比较常见的则有sha256,RSA。
非对称加密算法有俩个密钥，一个公钥，一个私钥。公钥和私钥必须配对出现，一对公钥和一个私钥统称为一个密钥，而密钥库中可以存放多个密钥，即多对公私钥。
- 公钥是公开的，私钥是保存在自己本地的
- 通信双方各有一套公钥和私钥
- 公钥加密的数据只有私钥可以解密
- 私钥加密的数据只有公钥可以解密
如果你用github的话，应该注意到github链接有俩种方式。一种是https,一种是ssh,通过https经常需要输密码，而通过ssh则不需要。回忆你设置ssh的步骤，本地生成了一个密钥对，并将公钥上传到了github。每次传输用自动本地私钥加密，服务器用你上传的公钥解密，就不需要手动输入密码了。
keytool VS openssl
keytool和openssl是俩个证书管理工具.keytool是java JDK自带的证书管理工具，使用keytool可以生成密钥，创建证书。只要装了jdk,并正确设置了环境变量，就可以之间通过命令行执行keytool命令来管理证书。
openssl则是一个开源的安全套接字层密码库，功能比keytool更加丰富。
X.509 VS PKCS
PKCS全称Public-Key Cryptography Standards 即公钥标准，PKCS已经发布了15个标准。
PKCS#12 包含了公钥和私钥的二进制格式的证书形式，以pfx作为证书文件后缀
X.509 则是一个通用的证书标准，规定了证书应该包含哪些内容，X.509通常有俩种编码方式，一种是二进制编码，另一种是base64编码
X.509#DER 二进制格式证书，常用后缀.cer .crt
X.509#PEM 文本格式证书，常用后缀.pem
ssl vs https
因为http是明文传输，非常不安全，因此又提出了ssl(Secure Sockets Layer即安全套接字)层协议，即在原来的基础上又加了一层协议用于保障安全传输,可以认为https=ssl+http。很多人刚开始接触https，用浏览器F12打开控制台后。可能发现数据仍然没有加密。要注意https是传输层加密，浏览器F12控制台你看到的还是应用层的数据。
因为本文主要是概念扫盲，帮助理解，因此关于这部分具体细节不作介绍。
各种常见文件后缀
.keystore和.jks和.truststore都是java用来存放密钥的文件
.key nginx中私钥文件
而不同的证书文件后缀都是为了区分不同种类的证书的，主要有俩个分类维度
- 证书内容是只包含公钥，还是即包含公钥又包含私钥
如.pfx 和 .p12 即包含公钥又包含私钥
.crt、.cer、.pem只包含公钥 - 通过编码格式来区分
通常.crt和.cer为二进制编码
.pem为base64编码
不同的证书格式之间有时候需要转换,用到时候查对应的openssl或keytool命令就好了。
