通俗大白话,彻底弄懂 https 原理本质
相信很多人,对 https 的过程弄不清楚,只是知道 https
是安全加密的,背后的原理,过程并不清楚
笔者曾经也是对https
的过程并不清楚,一知半解,而且最可气的是每次面试,面试官很可能就问你这个问题
每次都答不对或者答的面试官不满意,说来说去,还是自己没有真正理解
其实https
的原理过程,并没有那么复杂,只是有些文章没有说清楚,这样的文章看多了,就迷糊了。
在了解https
原理的过程之前,我们先来了解一下加密的知识
一 加密知识
加密按照加密方式,可以分为以下三种方式
1.1 单向加密
也叫做不可逆加密,对明文的加密产生一个密文,并不能再通过密文,解出来对应的明文
一般用于产生消息摘要,密钥加密等,常见的单向加密有:
- MD5 : 相信这个大家都都熟悉了,一个明文,md5以后,对应一个唯一的密文
- SHA : 其中又分为 sha192 , sha256
特点:
- 不可逆
- 输入一样,输出必然相同
1.2 对称加密
对称加密,用一个密钥,对明文进行加密,同理,同这把密钥,也可以对密文进行解密
也就是说加密和解密,可以用同一个密钥
这种加密方法就是 对称加密
常用的对称加密方法有:
- DES
- 3DES
- AES
特点:
- 加密方和解密使用同一密钥
- 加密解密的速度比较快
1.3 非对称加密
我们知道,对称加密使用同一把密钥,相反,非对称加密,使用公钥和私钥进行加密解密
可以使用私钥加密,公钥进行解密,同理,也可以使用公钥加密,私钥进行解密
常见非对称加密方式的有:
- RSA
- DSA
我们平时最常用的就是 RSA
特点:
- 使用两把密钥进行加密和解密,即公钥和私钥
- 公钥加密私钥解密,私钥加密公钥可以解密
- 加密或者解密,速度非常慢
- 私钥和公钥是成对出现的
二 加密知识总结
单向加密:不可逆,只要输入的内容一样,输出的密文一定是一样的,有任何修改, 产生的密文都是不同的
对称加密:加密和解密使用同一把密钥,加密解密速度特别快
非对称加密: 使用公钥和私钥进行加密和解密,公钥加密私钥解,私钥加密公钥解。加密解密的过程非常慢
所谓公钥,就是可以公开给别人的
所谓私钥,就是不可以公开给别人,是自己私有保留的。
注:以上内容,纯粹是加密的知识,和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的公钥,对数字证书进行验签
验签通过,说明数字证书是真的。
以上几个问题,希望读者多问问自己,如果是自己,应该怎么解决这个问题
此篇文章就写完了,解决的问题,就是双方通信如何采用安全高效的方式进行
能看到结尾的,真的是不容易,值得鼓励,如果我写的文章对你有用
请你转发给需要的人,也请帮忙给个关注,原创不易。谢谢