电子发烧友App
相信很多人，对 https 的过程弄不清楚，只是知道 https 是安全加密的，背后的原理，过程并不清楚
笔者曾经也是对 https 的过程并不清楚，一知半解，而且最可气的是每次面试，面试官很可能就问你这个问题
每次都答不对或者答的面试官不满意，说来说去，还是自己没有真正理解
其实 https 的原理过程，并没有那么复杂，只是有些文章没有说清楚，这样的文章看多了，就迷糊了。
在了解 https 原理的过程之前，我们先来了解一下加密的知识
一 加密知识
加密按照加密方式，可以分为以下三种方式
1.1 单向加密
也叫做不可逆加密，对明文的加密产生一个密文，并不能再通过密文，解出来对应的明文
一般用于产生消息摘要，密钥加密等，常见的单向加密有：
MD5 : 相信这个大家都都熟悉了，一个明文，md5 以后，对应一个唯一的密文
SHA : 其中又分为 sha192 , sha256
特点：
不可逆
输入一样，输出必然相同
1.2 对称加密
对称加密，用一个密钥，对明文进行加密，同理，同这把密钥，也可以对密文进行解密
也就是说加密和解密，可以用同一个密钥
这种加密方法就是 对称加密
常用的对称加密方法有：
DES
3DES
AES
特点：
加密方和解密使用同一密钥
加密解密的速度比较快
1.3 非对称加密
我们知道，对称加密使用同一把密钥，相反，非对称加密，使用公钥和私钥进行加密解密
可以使用私钥加密，公钥进行解密，同理，也可以使用公钥加密，私钥进行解密
常见非对称加密方式的有：
RSA
DSA
我们平时最常用的就是 RSA
特点：
使用两把密钥进行加密和解密，即公钥和私钥
公钥加密私钥解密，私钥加密公钥可以解密
加密或者解密，速度非常慢
私钥和公钥是成对出现的
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://github.com/YunaiV/ruoyi-vue-pro
视频教程：https://doc.iocoder.cn/video/
二 加密知识总结
** 单向加密：** 不可逆，只要输入的内容一样，输出的密文一定是一样的，有任何修改， 产生的密文都是不同的
** 对称加密：** 加密和解密使用同一把密钥，加密解密速度特别快
非对称加密： 使用公钥和私钥进行加密和解密，公钥加密私钥解，私钥加密公钥解。加密解密的过程非常慢
所谓公钥，就是可以公开给别人的
所谓私钥，就是不可以公开给别人，是自己私有保留的。
注：以上内容，纯粹是加密的知识，和 https 没有任何关系。下面我们开始讲解 https 的过程。我们先看一个需求
解决了这个需求，就明白了 https 的过程了。
从一个需求开始
假设有这样一个需求：小明和小花需要通信，少男少女写情书嘛，肯定不想让别人看到，所以需要安全的通信。
问题一：小明如何安全的把内容传给小花？
通过上面的加密知识的学习，我们很容易就想到，把通信的内容，给加密了就行了啊
答案是对的，把通信的内容给加密就行了。
问题二：使用哪种加密方式加密呢？
单向加密肯定不行，小花收到信，解不出来，这恋爱没法谈
对称加密可以 ，小花只要有密钥，就可以把内容解出来
非对称加密也可以 ，小明用自己的私钥加密，小花拿到小明的公钥，也可以把内容解出来
问题三：对称加密，非对称加密都可以，到底使用哪种呢？
通过上面的加密知识的学习，我们知道
对称加密速度快，非对称加密速度慢
那么对于小明，小花这俩人来说，经常一聊就是几个小时，数据是非常多的
如果使用非对称加密，那估计得郁闷死，因为加密也慢，解密也慢，这俩人肯定不会用非对称加密，要是我，我也不用，急死个人。
那么答案就是，使用对称加密方式 ，因为加密快啊，小明小花，都持有同一把密钥，双方互相都能解密出来对方发的信。
总结：小明和小花通信，使用对称加密，假如密钥是 S , 双方都使用同一把密钥 S 进行加密，解密
这样小明和小花就能愉快的通信了，而且内容是加密的，加密解密的速度也很快，这很美好。
但是这样有一个隐患，就是密钥 S ， 在传输的过程中，不小心被 老王 截获了
造成的后果就是：小明，小花以及老王，都有相同的密钥 S 了
那么，小明和小花之间没有秘密可言了，他们发的信，老王都能解开看，看完再加密，再发给小花，这还得了。
那么如何解决 密钥S 在传输的过程中，被别人截获的情况呢？
有人说，可以对称加密方式对密钥S 进行加密， 再传输，那么此时的密钥S1 也是有被截获的风险啊
那就再对 S1 进行加密，再传输...... ， 这样就无穷尽了。肯定是行不能的。
上面的方法肯定是不行了，现在的问题，变成了：小明如何把 密钥S 安全的传给小花， 这是不是和之前的问题一小明如何安全的把内容传给小花？类似
所以，小明和小花如何要安全的通信，就需要使用对称加密 把信件内容加密传输
那么就得先解决一个问题：小明如何安全的把密钥S 传输给小花？
问题四：小明如何安全的把密钥S 传输给小花？
如果密钥S 的传输过程不安全，那么后面的通信就是不安全的，反之，如何密钥S 能安全的传输给小花，那么后面的通信就是安全的。
如果这是领导交待给我们这样一个活，我们使用自己学到的上面的加密知识，应该怎么解决呢？
通过上面的加密知识的学习，是不是有下面这样一个安全的加密传输方式
小明使用非对称加密进行通信，首先小明生成了自己的一对私钥和公钥，为了方便，分别叫做 privateKey, publicKey
小明把 publicKey 给了小花
方法一 小明用自己的 privateKey，对 密钥S 进行加密，加密后的密文 S0 传输给小花，小花用 publicKey 对 S0 解密出来 密钥S
方法二 小花用 publicKey 对 密钥S 进行加密，加密后的密文 S0 传输给小明，小明用 privatekey 对 S0 解密出来 密钥S
上面，方法一 是不可行的，因为小明的 publicKey 是公开的，谁都可以下载，也就是说，老王也有小明的 publicKey，也可以对 S0 进行解密出来 密钥S
方法二是可行的，因为 privateKey 只有小明有，小花用小明的公钥进行加密，只有小明能解开，其它任何人都解不开
所以上面的解决方案就是：
使用非对称加密 方式，对 密钥S 进行加密，进行传输
有人说，不对啊，非对称加密 性能不好，加密解密特别慢，要不刚一开始，小明，小花直接使用非对称加密 进行通信，不就行了嘛
说的是对的，不过我们这里只是使用非对称加密 对 密钥S 进行加密，这个数据量很小的，而且密钥S 安全的传输给对方之后
后面的通信就直接使用对称加密了，这样效率就高了，而非对称加密只是在开始协商怎么安全传输密钥S 的阶段使用了，此阶段完成后，就不再需要使用了。
通过上面可知：非对称加密有这样的特性
我只要拿到谁的公钥，我和谁通信，就是安全的
比如，你有一对私钥和公钥，我只要拿到你的公钥，然后用你的公钥进行加密传输内容，只有你自己能解开，因为私钥只有你自己有
如下：
反过来，小明用自己的私钥加密，其它人使用小明的公钥解密，这个过程的作用是什么的呢？
答案是：验证身份的。
只要小明用自己的私钥加密，其它人用小明的公钥如果能解开，那么证明这封信一定以及肯定是小明写的
比如你需要发一个通知，但是又要确保这个通知一定是你发的，为了怕别人在中间涂改（比如古代假传圣旨，就是没有做好身份验证）
你可以用你的私钥对通知进行加密，其它人想看的话，通过下载你的公钥，进行解密，能解密出来，说明通知一定是你发的。
因为其它人如果在中间涂改，但是又没有你的私钥重新加密，所以是行不通的。
总结 ：通过以上的描述，我们解决了好几个问题，经过了以下几个过程。
小明和小花为了安全的通信，采用加密方式，对内容进行加密传输
对比来对比去，只能选对称加密这种加密方式，对内容进行加密传输
但是对称加密的密钥S ，传输过程不安全，容易被老王窃取，怎么办呢
小明想到了非对称加密方式，于是就生成了一对私钥公钥，并且把公钥给了小花
小花就用公钥对密钥S 进行加密，传给小明
因为是用了小明的公钥加密的，又因为私钥只有小明自己有，所以，只有小明能解密。这个过程哪怕老王截获了密文，也解密不了
这样，小明用自己的私钥解密出来了 密钥S
此时 小明和小花就用对称加密， 密钥S ， 进行愉快的通信了，比如商量彩礼给多少，酒席在哪办，蜜月在哪度
这样，这个通信过程就是安全的了。
上面的过程很完美，但是道高一尺，魔高一丈啊，老王脑子灵光特别好使啊，又想出来一招
既然你俩用非对称加密，我截取到密文也解密不了，那就换个法子。
如果小花在获取小明的公钥的过程，出了问题，比如小花获取的不是小明的公钥，而且老王的公钥呢（此时小花还以为手里的公钥是小明的呢）
会发生什么？先看一下图（也就是所谓的中间人攻击）
根据上图，老王，也叫做中间人，上图就是中间人攻击，流程如下：
小花在获取小明公钥的过程中，被老王给掉包成了自己的公钥，发给了小花
小花误以为手里的公钥是小明的 (其实是老王的公钥了)，所以就用老王的公钥对密钥S 进行加密，得到密文S0
密文S0 发给小明的过程中，被老王拦截，老王就用自己的私钥解密，得到了密钥S
老王得到密钥S 后，自己备份一份，再把此 密钥S，用小明的公钥加密，得到密文S1, 发给小明
小明得到 密文S1 后，用自己的私钥解密，得到 密钥S
以后，小明和小花，就用对称加密方式， 密钥S 进行通信了
他俩还以为很安全，其实通信的内容早就被老王先看了一遍了。还是不安全
啊啊啊，要疯了，为了通信安全，我们就加密，但是加密的密钥传输又不安全了
为了密钥传输安全，我们生产了私钥公钥对，把公钥给小花，小花用公钥对密钥加密再传输
这样就只有小明能解密了，没曾想，公钥的传输又不安全了。
谈个恋爱好难啊，老王啊，干的都叫啥事啊。。。
出了问题，总得解决啊，现在是传输公钥的过程，又不安全了
这和上面的问题 怎么把信件内容安全的传输给对方？以及怎``么把密钥安全的传输给对方？`` 是类似的
现在这个问题是：怎么把公钥安全的传输给对方？
感觉进入到了死循环了，不管是把 信件内容安全传输，还是把密钥安全传输，还是把 公钥安全安全传输
本质都是类似的，只不过传输的东西不一样，采用的方法不一样
问题五：小明如何安全的把自己的公钥传输给小花
经过上面我们解决的问题可以知道
如何安全的把通信内容传输给对方？
解决方法：我们用对称加密的方式进行通信
如何安全的把密钥S 安全的传输给对方 ？
解决方法：采用非对称加密方式，小明把自己的公钥给小花
小花用小明的公钥对密钥S 加密传给小明，小明用自己的私钥解密
这个过程只有小明能解密，所以是安全的
现在新的问题是：公钥如何安全传输给对方 ？
难道再用对称或者非对称加密？都不对。这样已经行不通了。
想象一下，生活中，我们有个矛盾，有个问题，我们最相信的是谁，肯定是政府啊
现在我从小明那下载公钥已经不靠谱了，已经不安全了
到底我应该相信谁呢？到底从谁那获取的公钥是小明真正的公钥呢？
所以，我们也搞一个机构，我们大家都相信这个机构，反正我就是无条件百分百相信这个机构，这是规定。
我们把这个机构起一个名字，叫做 CA 机构
好了，现在我们把问题抛给了 CA 机构，小花也好，小丽也好，小美也好，只要获取小明的公钥，都从 CA 那里获取
CA 机构哪来的小明的公钥呢？肯定是小明给的啊，对于小明来说，反正我已经把我的公钥给你 CA 了，你 CA 机构就得保证安全的传输给别人
这 CA 也是够倒霉的，你们搞不定的活，全抛给了我，又不是我和小花谈恋爱。。。
抱怨归抱怨，CA 是怎么解决的呢？
答案是 数字证书 ， 怎么又出来一个名字，数字证书是个什么鬼，是不是已经绕晕了，不要急，这个时候晕了，再回过过头再看看前面的写的
多看看几遍，别忘了，笔者也是看了 N 多遍，自己问自己问题，自己来尝试解决，才搞明白这个过程的。
先来说一个结论：数字证书就是解决公钥传输问题的
重要的事件重复三遍 ：数字证书就是解决公钥传输问题的 ，数字证书就是解决公钥传输问题的 ，数字证书就是解决公钥传输问题的
在说数字证书之前，我们先解决这样一个问题
问题六：信件的传输过程中，如何保证内容不被篡改，即信息的完整性？
结合前面学到的加密知识，我们可以用单向加密算法，我们以 md5 加密算法举例
小明给小花写完信后，用 md5 对信件的内容作一次加密运算，得到一个唯一的字符串，我们把这个字符串起个名，叫做摘要
小明在信件的底部，写上单向加密算法 md5, 以及 md5 对信件内容运算出来的摘要，一块发给小花
小花收到信后，看到信件底部是 md5 算法，于是就用 md5 对信件内容进行加密算法，得到 新的摘要
小花将 新的摘要 和信件底部附加的 摘要 进行对比，如果相等，说明信件没有被人改过
如果不相等，说明信件内容被别人改过了。
如下图表示此过程。
但就是上面这个过程，也是有问题的，如果老王又出现了呢
首先老王拿到信了，把信给改了
老王用 md5 算法 ，重新把信件内容给 md5 一下，得到新的加密串
老五把新的加密串，放在信件底部，发给了小花
此时小花收到信后，是没办法判断出来，信件是不是被篡改过的。
如下图表示：
所以，单纯的使用单向加密算法 ，生成摘要，是不能保证内容的完整性的
那么如何才能保证信件的完整性，不被人篡改呢？
答案是，签名
又出来一个名词，签名，本文的名词太多了。
通过前面学习，我们知道，非对称加密，有 2 个作用，其中一个就是身份认证
还是上面的例子我， 我们改一下：
小明用 md5 对信件内容进行运算，得到一个字符串，我们起名叫摘要
小明用自己的私钥对摘要进行加密运算，得到另一个字符串，我们起名叫签名
将 md5, 摘要， 签名一块发给小花
小花用小明的公钥对签名进行解密，到得信件摘要，假如为 d1
小花用 md5 对信件内容进行运算，得到信件摘要，假如为 d2
对比 d1 和 d2 是否相等，相等说明信件内容没有被篡改过
d1 和 d2 不相等，说明信件内容被篡改过。
此时，这个过程就是安全的了
如果老王再次截取了信件，老王可以修改信件内容，再次用 md5 算出一个新的摘要出来
但是签名，老王是修改不了的。因为签名是用的小明的私钥加密的，就算老王能解密出来
老王是没有办法生成新的签名的，因为小明的私钥只有小明自己有。
而且小花收到信后，是用小明的公钥进行对签名解密的，老王假如用自己的私钥对摘要进行加密生成新的签名
小花用小明的公钥是解密不了的。
此时再来进行一时概念的定义
摘要 ：md5（或者其它单向加密算法），对内容进行加密出来的字符串，就叫做摘要
签名 ：小明用私钥对摘要进行加密，加密出来签字串，就叫做签名
验签 ：小花用小明的公钥，对签名进行解密操作，解密出来的摘要和原来的对比，就叫做验签
问题七：数字证书是怎么由来的？
数字证书是由 CA 机构颁发的，首先小明如果想要有一个数字证书，就需要向 CA 机构申请
CA 机构就会给小明颁发一张数字证书，里面包含了
公钥：小明的公钥
颁发者：CA（证书认证机构）
有效期：证书的使用期限
摘要算法：指定的摘要算法，用来计算证书的摘要
指纹：也就是证书的摘要，保证证书的完整性
签名算法：用于生成签名，确保证书是由 CA 签发
序列号：证书的唯一标识
知道了证书里面包含的内容，我们了解一下证书是如何产生的？
将小明的公钥，颁发者，有效期，摘要算法 ，哈希算法写入证书
CA 根据证书中的指定的哈希算法，计算出整个证书的摘要，即 digest
CA 根据签名算法以及上一步计算出来的摘要，CA用自己的私钥对摘要进行加密，生成 CA 的签名，即 signature
最后把摘要，签名以及证书的基本信息，一起发布，就得到了小明的证书
问题八：数字证书的作用
从上面我们知道，数字证书就是解决公钥传输问题的，同时我们也知道，数字证书就是一个文件
既然数字证书是用来解决公钥的安全传输的，那么到底如何解决传输问题的呢
现在小明有了自己的证书了，我们就不会公开传输公钥了，只需要传输证书就行了
那么，小明和小花现在需要安全的通信，那么流程是怎么样的呢？如下
小明把自己的数字证书发送给小花
担心证书被老王掉包，小花需要对证书进行验证，验证什么呢？
其实就是验证此数字到底是不是 CA 机构颁发的，不是 CA 机构颁发的证书，我们就认为传输是不安全的。
验证数字证书是不是 CA 颁发的，需要有 CA的公钥 。。。（为啥需要 CA 的公钥啊，因为证书上的签名，是 CA 的私钥加密的啊，只有 CA 的公钥才能解密啊）
啊啊啊，受不了啦，搞了半天怎么又需要公钥，我们讲了半天的数字证书，就是为了传输公钥的
所以，换成下面的描述会好点
验证数字证书是不是 CA 频发的，需要 CA 的数字证书（因为里面有 CA 的公钥）
那我们去哪里找 CA 的数字证书呢？从上面的描述，我们知道了，需要一个数字证书，就向 CA 申请，CA 给我们颁发。
那么 CA 机构自己的数字证书哪来的呢？答案是也是自己给自己颁发的，那么我们从哪里获取呢？
如果从网上，或者从其它服务器下载，又有可能会被掉包，又不安全了。
这真的是个伤心的故事，但是今天兔哥非要把这个故事讲完。
从网上下载或者从其它服务器下载数字证书，都不安全的，那么怎么样才是安全的呢？
答案就是：你的电脑安装操作系统的时候，操作系统里面，就已经内置了非常多的 CA 机构的数字证书了
也就说，只要你安装了操作系统，不管是 windows, linux, 或者 mac , 或者你刚买的电脑，里面都已经有了 CA 机构的数字证书了
这个是可以相信的，是真的 CA 机构的数字证书，不会有假。（除非你安装的是盗版的操作系统，所以我们尽量用正版操作系统）
上面的过程真的是复杂啊，兔哥也是花了很久才搞明白的，知道这块面试会坑很多人，其实 https 过程不知道，也没啥关系
也不影响你写代码，但是那些面试官就死爱问这块，好像他们能搞懂这个过程很了不起似的，你问点设计模式它不香嘛。
不过话说回来，兔哥在写自己的 HelloWorld 技术社区 的时候，配置 https ，数字证书，不懂这些，还真的不好搞啊
写文章不容易，尤其是写这篇文章，为了写的更容易懂点，花了不少精力，能看到这块的，帮忙给个关注吧
尤其是帮忙宣传一下兔哥的 HelloWorld 技术社区 , 同一个世界，同一行代码，我们的域名是：www.helloworld.net
我们的电脑，天生就有 CA 的数字证书，而且是真的。天生的。上天定的，上天最大
那么我们就可以对数字证书进行辨别真伪了。
问题九：对数字证书的验证
从上面可以知道：
小花收到了小明的数字证书，首先要对数字证书进行验证，就是验证此数字证书是不是 CA 颁发的
因为我们操作系统里面内置了所有 CA 机构的数字证书，所以，我们就可以对数字证书进行验证
在说流程之前，先来简单的复习一下前面的，摘要和签名怎么来的
摘要 = md5 (证书内容) ：单向加密算法，比如 md5，对证书整个内容进行加密，得到摘要，也叫做证书的指纹
签名 = privateKey (摘要) : 私钥对上一步摘要加密，产生签名
数字证书的验证流程如下：
小花用内置的 CA 的数字证书，得到 CA 的公钥
小明发过来的数字证书，我们假如叫做 C ， 小花用 CA 的公钥对 C 证书里面的签名进行解密，得到摘要 D
小花根据 C 证书里面的摘要算法，假如是 md5，小花用 md5 对证书整个内容进行计算，得到摘要 D1
小花对比摘要 D 和摘要 D1 是否相等
如果 D == D1 ，那么说明此证书就是 CA 颁发的
如果 D != D1 ， 那么说明此证书不是 CA 颁发的，是有风险的，不安全的
假如证书验证通过，就说明此证书的确是 CA 颁发的，此时小花就可以从数字证书中拿到小明的公钥了
因为小明在申请数字证书时，数字证书中所有者是小明，CA 是会验证小明的身份的，所以数字证书中小明的公钥是真实的
由至此，我们总算完成了一件事：小明正确的把自己的公钥安全的传输给了小花
这件事的成立 ，接下来我们的工作就好做多了。接下来，我们看一下具体的传输过程
问题十 ：完整的传输过程
下面我们看一下小明再次给小花通信，就和前面的不一样了，我们来看下：
小明把写完的信，在信的底部，附加上摘要算法，假如是 MD5， 以及通过 MD5 算出来的摘要
小明用自己的私钥，对上一步的摘要进行加密，得到签名
小明把摘要算法，摘要，签名都附加到信件底部以后，再把自己的数字证书，一起发送给小花
小花收到信后，首先用自己的 CA 数字证书，拿到 CA 公钥，再用 CA 公钥对数字证书进行验证（也就是上面我们讲的流程）
数字证书验证通过后，说明证书就是 CA 颁发的，没有被篡改
小花就从证书中拿到了小明的公钥
有了小明的公钥，接下来的过程，就是对信件内容进行验证了
对信件内容的验证流程如下（前面其实我们讲过）
小花用小明的公钥，对信件的签名进行解密，得到信件的摘要 D1
小花用摘要算法，对信件进行运算，得到信件的摘要 D2
小花对比 D1 是否等于 D2
如果不相等，说明信件被人篡改过，不安全
如果相等，说明，信件内容没有被篡改过
相等的情况，小花就拿到了信件的内容
总结：
以上所有的内容，是数字证书，加密解密，签名，验签的过程，还没有正式讲 https 的过程呢。
有了以上的知识，我们讲起来 https 就容易的多了。下面我们看一张图
我们以访问 www.helloworld.net 网站为例，讲解 https 的过程
此过程分为 3 个阶段，我们在下面描述此 3 个阶段
访问 www.helloworld.net 的过程 阶段如下
网站申请证书阶段
网站向 CA 机构申请数字证书（需要提交一些材料，比如域名）
CA 向证书中写入摘要算法，域名，网站的公钥等重要信息
CA 根据证书中写入的摘要算法，计算出证书的摘要
CA 用自己的私钥对摘要进行加密，计算出签名
CA 生成一张数字证书，颁发给了 www.helloworld.net
网站的管理员，把证书放在自己的服务器上
浏览器验证证书阶段
浏览器在地址栏中输入 https://www.helloworld.net，并回车
服务器将数字证书发送给浏览器
浏览器用操作系统内置的 CA 的数字证书，拿到 CA 的公钥
浏览器用 CA 公钥对 www.helloworld.net 的数字证书进行验签
具体就是，浏览器用 CA 公钥，对 helloworld 的数字证书中的签名进行解密，得到摘要 D1
浏览器根据 helloworld 数字证书中的摘要算法，计算出证书的摘要 D2
对比 D1 和 D2 是否相等。
如果不相等，说明证书被掉包了
如果相等，说明证书验证通过了。
协商对称加密密钥阶段
浏览器验证数字证书通过以后
浏览器拿到数字证书中的公钥，也就是 www.helloworld.net 网站的公钥
浏览器有了网站的公钥后，就用公钥进行对密钥S 进行加密，加密以后的密文发送给服务器
服务器收到密文后，用自己的私钥进行解密，得到密钥S
此后浏览器，服务器双方就用密钥S 进行对称加密的通信了。
终止所述，终于讲完了，花了整整一天的时间
过程那么多，其实抓住几个关键的问题是很简单的，本质上还是两个人，如何安全高效的进行通信
我们再次简单的总结一下，采用一问一答的方式，我觉得比较好
问题一：小明和小花安全的通信，怎么做？
答：通过加密
问题二：通过哪种加密方式通信，更高效？
答：对称加密
因为，单向加密，没办法解密，不行
非对称加密，太慢，也不行
只有对称加密，速度快
问题三：采用对称加密，密钥 S 怎么安全传输？
答：小花使用小明的公钥，对密钥S 进行加密，传给小明
小明用自己的私钥解密
问题四：小明如何安全的把自己的公钥传输给小花？
答：使用数字证书
具体就是 小明向 CA 申请一个自己的数字证书，把自己的公钥放在证书中
小明将数字证书发送给小花
问题五：小花如何验证数字证书的真实性？
答：小花用操作系统内置的 CA 的数字证书，拿到 CA 的公钥，用 CA 的公钥，对数字证书进行验签
验签通过，说明数字证书是真的。
以上几个问题，希望读者多问问自己，如果是自己，应该怎么解决这个问题。
编辑：黄飞
工商网监
评论