深刻理解数字签名，SSL加密，证书

基本概念

CA：数字证书认证机构，CA的就像一个颁发护照的政府，政府给每本护照印章，所以这样的护照很难伪造。只有CA盖过章的护照才是真实的，合法的。所以 CA是一个大家都信任的第三方机构，只要是他签名过的证书（类似盖章）就是真实，合法的证书。

CSR：Certificate Signing Request的英文缩写，即证书签名请求文件，是证书申请者在申请数字证书时由CSP(加密服务提供者)在生成私钥的同时也生成证书请求文件，证书申请者只要把CSR文件提交给证书颁发机构后，证书颁发机构使用其根证书私钥签名就生成了证书公钥文件，也就是颁发给用户的证书。

CSR按照X509的结构存储信息的，可以通过openssl req -noout -text -in xxxx来查看文件内容。这个文件包括证书以及公钥等信息。

X.509：是一种证书格式.对X.509证书来说，认证者总是CA或由CA指定的人，一份X.509证书是一些标准字段的集合，这些字段包含有关用户或设备及其相应公钥的信息。

X.509的证书文件，一般以.crt结尾，根据该文件的内容编码格式，可以分为以下二种格式：

PEM - Privacy Enhanced Mail,打开看文本格式,以"-----BEGIN…"开头, "-----END…"结尾,内容是BASE64编码.
Apache和*NIX服务器偏向于使用这种编码格式.

DER - Distinguished Encoding Rules,打开看是二进制格式,不可读.
Java和Windows服务器偏向于使用这种编码格式

CSP:加密服务提供程序 (CSP) 是 Windows 操作系统中提供一般加密功能的硬件和软件组件。可以编写这些 CSP 以提供各种加密和签名算法。

PKCS:he Public-Key Cryptography Standards (PKCS)是由美国RSA及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。

PKCS（Public-Key Cryptography Standards ）和CSP(Cryptographic Service Provider)都是加密服务标准，前者由RSA提出，后者由微软提出，他们之间设计初衷基本是相同的，各种逻辑结构其实也差不多。并且在实际应用中，比如USBKey或是蓝牙Key，往往设计上只会参考一种规范设计，然后使用中间件转接方式兼容另一种标准（PKCS或CSP）

server.keystore.jks:存储服务器证书，CA证书，CA签名的服务器证书。

client.keystore.jks:存储客户端证书，CA证书，CA签名的客户端证书。

server.truststore.jks:存储服务器端信任的CA证书。

client.truststore.jks:存储客户端信任的CA证书。

keytool是一个工具可以用来创建包含公钥和密钥的的keystore文件，并且利用keystore文件来创建只包含公钥的truststore文件

ca-cert:CA证书,用来给服务器证书签名的。有CA机构生成，里面有CA信息，以及公钥。

ca-key：生成秘钥和公钥的字段。例如生成私钥：openssl genrsa -out ca-key 1024。生成公钥：openssl rsa -in private_rsa.pem -pubout -out public-key。（https://blog.csdn.net/topgun_chenlingyun/article/details/43274501）

cert-file：CSR文件，需要签名的证书，首先生成CSR文件，然后将CSR发送给CA进行签名。

cert-signed：经过CA证书签名之后的证书。

什么是签名

现实生活中，签名有什么作用？在一封信中，文末的签名是为了表示这封信是签名者写的。计算机中，数字签名也是相同的含义：证明消息是某个特定的人，而不是随随便便一个人发送的（有效性）；除此之外，数字签名还能证明消息没有被篡改（完整性）。

简单来说，数字签名（digital signature）是公钥密码的逆应用：用私钥加密消息，用公钥解密消息。

用私钥加密的消息称为签名，只有拥有私钥的用户可以生成签名。

一般来说，不直接对消息进行签名，而是对消息的哈希值进行签名

什么是证书

证书实际上就是对公钥进行数字签名，它是对公钥合法性提供证明的技术。

考虑这样一种场景：我们对签名进行验证时，需要用到公钥。如果公钥也是伪造的，那怎么办？如果公钥是假的，验证数字签名那就无从谈起，根本不可能从数字签名确定对方的合法性。
这时候证书就派上用场了。

证书一般包含：公钥（记住证书中是带有公钥的），公钥的数字签名，公钥拥有者的信息
若证书验证成功，这表示该公钥是合法，可信的。

数字签名验证过程

鲍勃有两把钥匙，一把是公钥，另一把是私钥。

鲍勃把公钥送给他的朋友们----帕蒂、道格、苏珊----每人一把。

苏珊要给鲍勃写一封保密的信。她写完后用鲍勃的公钥加密，就可以达到保密的效果。

鲍勃收信后，用私钥解密，就看到了信件内容。这里要强调的是，只要鲍勃的私钥不泄露，这封信就是安全的，即使落在别人手里，也无法解密。

鲍勃给苏珊回信，决定采用"数字签名"。他写完后先用Hash函数，生成信件的摘要（digest）。

然后，鲍勃使用私钥，对这个摘要加密，生成"数字签名"（signature）。

鲍勃将这个签名，附在信件下面，一起发给苏珊。

苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。

苏珊再对信件本身使用Hash函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，就证明这封信未被修改过。

复杂的情况出现了。道格想欺骗苏珊，他偷偷使用了苏珊的电脑，用自己的公钥换走了鲍勃的公钥。此时，苏珊实际拥有的是道格的公钥，但是还以为这是鲍勃的公钥。因此，道格就可以冒充鲍勃，用自己的私钥做成"数字签名"，写信给苏珊，让苏珊用假的鲍勃公钥进行解密。

后来，苏珊感觉不对劲，发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法，要求鲍勃去找"证书中心"（certificate authority，简称CA），为公钥做认证。证书中心用自己的私钥，对鲍勃的公钥和一些相关信息一起加密，生成"数字证书"（Digital Certificate）。

鲍勃拿到数字证书以后，就可以放心了。以后再给苏珊写信，只要在签名的同时，再附上数字证书就行了。

苏珊收信后，用CA的公钥解开数字证书，就可以拿到鲍勃真实的公钥了，然后就能证明"数字签名"是否真的是鲍勃签的。

自签证书与私签证书

当由于某种原因（如：不想通过 CA 购买证书，或者仅是用于测试等情况），无法正常获取 CA 签发的证书。这时可以生成一个自签名证书。使用这个临时证书的时候，会在客户端浏览器报一个错误，签名证书授权未知或不可信（signing certificate authority is unknown and not trusted.）。

自签证书，不需要CA，也不需要自建CA。使用自己证书的私钥，进行签名。其实 CA 证书就是一个自签名证书。

私签证书，需要建立一个私有CA，然后将CSR发送给私有CA，有这个私有CA进行签名。

keytool 生成ssl过程

1.keytool -keystore server.keystore.jks -alias mykafkassl -validity 3650 -genkey

生成密钥对，并且生成使用X.509 v3 自签名的证书

2.keytool -list -v -keystore server.keystore.jks

查看certificate

3.openssl req -new -x509 -keyout ca-key -out ca-cert -days 3650

生成私有CA

4.keytool -keystore client.truststore.jks -alias CARoot -import -file ca-cert

客户端信任上一步生成的CA证书，以后所有通过上一步CA签名的证书都被认为是可信的。客户端信任服务器的证书通过上一步CA签名的证书

5.keytool -keystore server.truststore.jks -alias CARoot -import -file ca-cert

服务器信任客户端的证书通过上一步CA签名的证书

5.keytool -keystore server.keystore.jks -alias mykafkassl -certreq -file certfile

生成证书签名请求，该请求用来给第1步中生成证书签名，也就是给第1步中的生成的公钥加密。

6.openssl x509 -req -CA ca-cert -CAkey ca-key -in cert-file -out cert-signed -days 3650 -CAcreateserial -passin pass:testssl

私有CA给1中的证书进行签名，就是用3中生成的私有CA的私钥加密1中的公钥。

7.keytool -keystore server.keystore.jks -alias CARoot -import -file ca-cert

CA证书存储于秘钥库中，ca-cert就是CA证书，内容是CA的公钥

8.keytool -keystore server.keystore.jks -alias mykafkassl -import -file certsigned

添加私有CA签名的证书。

流程图如下：

举个现实中的例子：
工作原理：
现在假设客户A向银行B传送数字信息，为了保证信息传送的真实性、完整性和不可否认性，需要对要传送的信息进行数字加密和数字签名，其传送过程如下：

（1）客户A准备好要传送的数字信息（明文）。（准备明文）

（2）客户A对数字信息进行哈希（hash）运算，得到一个信息摘要。（准备摘要）

3）客户A用自己的私钥（SK）对信息摘要进行加密得到客户A的数字签名，并将其附在数字信息上。　（用私钥对数字信息进行数字签名）

4）客户A随机产生一个加密密钥（DES密钥），并用此密钥对要发送的信息进行加密，形成密文。 （生成密文）

5）客户A用双方共有的公钥（PK）对刚才随机产生的加密密钥进行加密，将加密后的DES密钥连同密文一起传送给乙。（用公钥对DES密钥进行加密）

6）银行B收到客户A传送过来的密文和加过密的DES密钥，先用自己的私钥（SK）对加密的DES密钥进行解密，得到DES密钥。（用私钥对DES密钥解密）

7）银行B然后用DES密钥对收到的密文进行解密，得到明文的数字信息，然后将DES密钥抛弃（即DES密钥作废）。（解密文）

8）银行B用双方共有的公钥（PK）对客户A的数字签名进行解密，得到信息摘要。银行B用相同的hash算法对收到的明文再进行一次hash运算，得到一个新的信息摘要。　　
（用公钥解密数字签名）
　　9）银行B将收到的信息摘要和新产生的信息摘要进行比较，如果一致，说明收到的信息没有被修改过。（对比信息摘要和信息）

为什么中间使用对称加密对信息进行加密？
1.对明文加密可以防止信息泄露
2.为什么不用费对称加密，而用对称加密，因为非对称加密解析复杂，不利于信息的交换处理，同时明文信息量大，不适合非对称加密。

参考

http://cxy7.com/articles/2018/06/28/1530183007850.html#b3_solo_h3_11

https://www.cnblogs.com/lxm20145215----/p/5470400.html

https://fatfatson.github.io/2018/07/27/openssl%E8%B5%B0%E4%B8%80%E8%BD%AECA%E8%AF%81%E4%B9%A6%E7%AD%BE%E5%8F%91%E7%9A%84%E8%BF%87%E7%A8%8B%E5%92%8C%E5%90%84%E4%B8%AA%E6%96%87%E4%BB%B6%E4%BD%9C%E7%94%A8/

https://docs.vmware.com/cn/VMware-Horizon-7/7.1/com.vmware.horizon-view.certificates.doc/GUID-787B0C50-0FB3-4C4A-9B6F-5756E6829A4C.html

https://www.jianshu.com/p/e5f46dcf4664

https://www.jianshu.com/p/cc6b804a4d80

http://www.metsky.com/archives/795.html

http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html

http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html

https://blog.csdn.net/freezingxu/article/details/71547485

https://www.jianshu.com/p/ee26f2a5d430

https://blog.51cto.com/colinzhouyj/1566250

https://blog.csdn.net/weixin_36293343/article/details/85090852

https://www.jianshu.com/p/9db57e761255

https://blog.51cto.com/sandshell/2131795