1. 基础知识
1.1 https起源
鲍勃有两把钥匙，一把是公钥，另一把是私钥。
鲍勃把公钥送给他的朋友们----帕蒂、道格、苏珊----每人一把。
苏珊要给鲍勃写一封保密的信。她写完后用鲍勃的公钥加密，就可以达到保密的效果。
鲍勃收信后，用私钥解密，就看到了信件内容。这里要强调的是，只要鲍勃的私钥不泄露，这封信就是安全的，即使落在别人手里，也无法解密。
鲍勃给苏珊回信，决定采用"数字签名"。他写完后先用Hash函数，生成信件的摘要（digest）。
然后，鲍勃使用私钥，对这个摘要加密，生成"数字签名"（signature）。
鲍勃将这个签名，附在信件下面，一起发给苏珊。
苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。
苏珊再对信件本身使用Hash函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，就证明这封信未被修改过。
复杂的情况出现了。道格想欺骗苏珊，他偷偷使用了苏珊的电脑，用自己的公钥换走了鲍勃的公钥。此时，苏珊实际拥有的是道格的公钥，但是还以为这是鲍勃的公钥。因此，道格就可以冒充鲍勃，用自己的私钥做成"数字签名"，写信给苏珊，让苏珊用假的鲍勃公钥进行解密。
后来，苏珊感觉不对劲，发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法，要求鲍勃去找"证书中心"（certificate authority，简称CA），为公钥做认证。证书中心用自己的私钥，对鲍勃的公钥和一些相关信息一起加密，生成"数字证书"（Digital Certificate）。
鲍勃拿到数字证书以后，就可以放心了。以后再给苏珊写信，只要在签名的同时，再附上数字证书就行了。
苏珊收信后，用CA的公钥解开数字证书，就可以拿到鲍勃真实的公钥了，然后就能证明"数字签名"是否真的是鲍勃签的。
下面，我们看一个应用"数字证书"的实例：https协议。这个协议主要用于网页加密。
首先，客户端向服务器发出加密请求。
服务器用自己的私钥加密网页以后，连同本身的数字证书，一起发送给客户端。
客户端（浏览器）的"证书管理器"，有"受信任的根证书颁发机构"列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内。
如果数字证书记载的网址，与你正在浏览的网址不一致，就说明这张证书可能被冒用，浏览器会发出警告。
如果这张数字证书不是由受信任的机构颁发的，浏览器会发出另一种警告。
1.2 数字签名
签名生成流程：
发送者对消息计算摘要值
发送者用私钥对摘要值进行签名得到签名值
发送者将原始消息和签名值一同发送给接收者
注：1、数字签名技术的本质不是加密，所以和签名值一同传递的消息不是用加密的，当然也可以对消息加密后再计算签名值
2、数字签名算法建议对消息摘要值进行签名，因为摘要值的长度是固定的，运算时候的速度会比较快。
签名验证流程：
接收者接收到消息后，拆分出消息和消息签名值A。
接收者使用公钥对消息进行运算得到摘要值B。
接收者对摘要值B和签名值A进行比较，如果相同表示签名验证成功，否则就是验证失败。
RSA数字签名算法
RSA加密算法是公钥加密，私钥解密；
RSA签名算法是私钥签名，公钥验证签名。
数字签名技术：
密码学中，以PSA密钥对为例，私钥只有密钥对的生成者持有，如果不考虑密钥泄漏的问题，私钥持有者使用密钥签署一条消息，然后发送给任意的接收方，接收方只要拥有私钥对应的公钥，就能成功反解签署消息，由于只有私钥持有者才能“签署”消息，不能抵赖说这条签署消息不是他发送的。
数字签名技术的特点：
防篡改：数字不会被修改
防抵赖：消息签署者不能抵赖
防伪造：发送的消息不能够伪造
2.申请证书
提供服务的服务方通过提交关键DN信息向有合法的CA机构申请证书，如阿里云等。也可以自己利用openssl进行自签名，自签名的证书浏览器访问会报错提示。自签名可参考这篇文章（OpenSSL Certificate Authority — Jamie Nguyen），讲述的比较清晰。
容易混淆的一点是，我们平常说的对外公开的一定是证书，证书里面包含公钥。证书采用的是X.509的格式，只要是客户端进行反解证书都可以获得公钥，所以即使自签名的证书也可以通过浏览器访问，只不过浏览器或提示不安全，如果点击继续或者设置为安全，依然可以使用https协议进行通讯。
3. 交互流程
如下图，当用户发起https访问，服务端会返回CA证书（如果是自签名就是返回自签名的证书），浏览器会进行证书解析，首先会判断CA证书是否合法，比如CA机构是否合法，对应的DN信息是否匹配。如果不合法就提示用户，如果合法就获取公钥（这里不需要解密，直接解析即可获取）；然后根据公钥进行随机私钥的加密，接着一步一步按照下图流程就行。
4. 细节说明
1.CA机构的身份和作用：CA机构是一个可信第三方，常见的大多是有名望的大企业，或者对安全性要求比较高的机构，比如银行。它在这里的主要职责是签发证书，而在实际的服务器与客户机交互阶段，CA机构以“CA证书”的形式参与，而不是CA机构的服务器。如果是后者，可以想见，“几乎全网”的HTTPS请求都要经过“CA机构服务器”，怕是没有哪家服务器扛得住。所以，CS交互期间，可以认为CA机构是离线的；
2.证书的第一职责是验证身份。服务器作为服务提供者，首先要确保自己的身份和安全性，它会向CA机构申请证书，并提供一些基本信息，比如组织名称、国家、地区等：
服务器证书的获取流程：
a.服务器把自己的基本信息打包处理，得到一个签名；
b.服务器把自己的签名用自己的私钥（就是一个非对称加密的密码）加密，得到一个公钥（也叫待签名证书）；
c.服务器把自己的签名和公钥同时发给CA机构；
d.CA机构通过签名识别服务器的身份后，用自己的私钥对提交过来的服务器公钥进行加密，生成服务器证书并返回；
申请证书这个过程不一定需要提供算法名称，使用什么算法，高版本协议中都是约定好的。生成服务器证书的过程，用一句话概括就是“CA机构（证书签发机构）用自己的证书对申请者（可信服务器）签发了一个证书”。
3.服务器在与客户端交互的时候，把自己的证书发给客户端，向客户端证明自己的身份。客户端通过提前安装的CA证书（包含CA的公钥，人人都可以获取到，保持系统升级即可，一般不需要特意安装）来验证服务端证书的合法性。由于服务端证书是用CA私钥加密的，所以现在可以用CA公钥解密——即非对称加密，这样就实现了服务器签名的验证，所以叫验签。反过来，客户端向服务器证明身份也可以用同样的方式。验证CS双方身份的过程，也是实现HTTPS不可否认/不可抵赖特性的保证。
4.客户端得到的证书有两个：CA证书和服务器证书，即用CA证书来验证服务器证书的合法性，从而证明服务器身份。难道不需要证明客户端身份吗？需要，但一般不需要像服务端那样额外申请一个证书来证明（除了银行业。还记得你的U盾吗，就是个证书），用CA证书中提供的各类算法和后续的握手机制，就可以确保客户端身份，进行安全传输了。
参考链接：十分钟搞懂https签名_沉舟已过的博客-CSDN博客_https签名
参考链接：HTTPs的签名相关概念_笙箫声动的博客-CSDN博客_https 数字签名
参考链接：https的数字签名流程_卡乐C前端的博客-CSDN博客_https 数字签名
参考链接：关于本节HTTPS的相关疑惑 马士兵教育官网 - IT职业领路人
