证书颁发与身份认证是Fabric的一个非常重要的环节，这1篇将从最基础的公私钥出发，详细解析整个基于PKI的安全体系。
这个安全体系，不光是Fabric使用的，整个互联网（Https协议），也同样基于这个体系。
对称加密
对称加密很简单，通信双方共享同1个密钥。但有个根本问题：你如何把密钥发送给对方？
密钥的发送过程，也需要加密，再来1个新的密钥，新的密钥又怎么发送给对方？ 这是个连环套。。。
关于对称加密的详细内容，网上参考文章很多，本处就不再详细解释。
非对称加密（比如RSA）与 HTTPS
我们知道，Https，还有我们前面讲的比特币/以太坊的交易过程，都用到了非对称加密。常用的非对称加密算法不止1种(比如RSA），但其加密通信的原理类似：
如下图所示，A/B双方要通信。
首先呢，A为自己准备1对公私钥，B为自己准备1对公私钥（关于如何根据私钥生成公钥，在前面的比特币序列有详细讲解。参见第8课 账号相关概念：公钥/私钥/Public Key Hash/P2PKH）
然后A, B把自己的公钥公开出去，私钥自己藏着。这样呢，A就知道了B的公钥，B就知道了A的公钥。
A给B发送信息时，就用自己的私钥签名，再用B的公钥加密。所谓的“签名”，就相当于自己盖了个章，或者说签了个字，证明这个信息是A发送的，A不能抵赖；用B的公钥加密，只有B可以用自己的私钥解密。即使这个信息被C截获了，C没有B的私钥，也解密不了这个信息。
B收到这个信息之后，先用A的公钥验签（证明这个信息是A发的），然后再用自己的私钥解密，从而看到信息。
反向过程同理：
B给A发送信息时，B用自己的私钥签名，然后用A的公钥加密。
A接收到B的信息之后，先用B的公钥验签，然后用A自己的私钥解密，看到内容。
总结：非对称加密，签名/验签 与 加密/解密 是个相反的过程，目的也不一样。
签名/验签： 私钥签名，公钥验签。目的是防篡改。如果第3方截取到信息之后篡改，那接收方肯定就验不过了。同时也防抵赖，既然没有人可篡改，那只可能是发送方自己发的。
加密/解密：公钥加密，私钥解密。目的是防止信息被第3方拦截，偷听。第3方能截获到信息，但你没有私钥，解密不了。
好了，现在有了非对称加密，我们就可以安全的传输信息了。但非对称加密，有个问题，就是性能慢。发送方要签名，要加密； 接受方要验签，要解密。 其速度比对称加密慢很多。
那好办，把对称加密 + 非对称加密 结合起来：双方先用非对称加密通信（如上图所示），通过非对称加密传输，协商出一个对称加密的密钥。这个密钥临时生成的，也不会落地存储。 之后，双方用这个密钥，进行对称加密传输。
而这，就是https的原理。
中间人攻击
上面的算法看起来很无懈可击，但其实它由一个漏洞，也就是中间人攻击。
这个攻击，发生在A, B交互公钥的时候：
如下所示，A和B本来要交互公钥，但被中间人C劫持了，劫持过程如下：
A本来是要把自己的公钥发给B：“hi，哥们，我是A，我的公钥是Axxx”。
被C劫持之后，C用自己的公钥替换A的公钥，然后发给B： “hi，哥们，我是A，我的公钥是Cxxx”
B本来是要把自己的公钥发给A：“hi，哥们，我是B，我的公钥是Bxxx”。
被C劫持之后，C用自己的公钥替换B的公钥，然后发给A： “hi，哥们，我是B，我的公钥是Cxxx”
A和B都以为自己是在和对方通信，但其实他们都是在和C通信！！！
接下来，A发给B的信息，会用C的公钥加密，C当然可以看到这个信息；
同样，B发给A的信息，会用C的公钥加密，C也可以看到。
为什么会出现这个问题呢？？
这个问题的根源是：公钥的传输过程，可以被篡改！！A和B在网络上，互相又没见过对方，又没啥根据，你说你是A，我咋知道你就是A呢？
那我们需要想个办法，来证明B收到的公钥，的确就是A的，中间没有人可以篡改这个公钥，这就是接下来要将的数字证书。
数字证书（Certificate）与 证书认证中心（CA）
如下图所示，引入1个中间机构CA。A要把公钥发给B的时候呢，不是直接发公钥，而是发公钥对应的证书。证书怎么来的呢？
CA从组织上来讲，类似现实中的“公证处”，从技术上来讲，就是1个服务器。A先把自己的公钥发给CA，CA给A颁发一个数字证书（Certificate），这个证书就相当于A的身份证。B也把自己的公钥发给CA，CA给B颁发1个证书，相当于B的身份证。
之后A把这个证书给B，B可以验证这个证书是A的，不可能是谁伪造的。
这个过程具体怎么操作的呢？
其实也很简单，CA自己有1对公钥/私钥，私钥当然只有CA自己知道，公钥在网络上，谁都知道。
A把个人信息 + A的公钥 发给CA，CA为A生成一个数字证书，B也同样的道理。
A的数字证书 = A的个人信息 + A的公钥 + CA的数字签名
B的数字证书 = B的个人信息 + B的公钥 + CA的数字签名
说的通俗点，A把自己的公钥，发给CA，让CA盖了个公章，之后别人就不能再伪造这个公钥了，B也同样的道理。
B收到A的数字证书之后，用CA的公钥验证一下这个证书，验证的过，就说明这个证书肯定是A的，不可能被别人伪造。
反过来，A收到B的证书之后，同样可以证明B的证书的确是B发放的，不是伪造的。
通过这种方式，就实现了A,B之间安全的交互公钥。公钥安全交换了，接下来就可以进行安全的非对称加密传输。
CA信任链，Root Certificate(根证书），Root CA（根认证中心）
但上面有个类似的问题，你让A,B都信任CA，但CA是个假的怎么办？？
也就是说，CA被拦截怎么办？1个假的CA在中间，A，B都在和这个假的CA通信，还以为是和真正的CA通信。
问题也就是：CA面临和A,B同样的问题，A，B需要证明公钥的确是A,B自己发出去的，不是被伪造的；CA同样需要证明，自己的公钥是自己发出去的，不是被伪造的。
这就是下面的信任链。
假设客户端Bill向CA2申请证书；
CA2呢，直接上级是CA1，它向CA1申请证书（CA2需要持证上岗）；
CA1呢，直接上级就是1个Root CA，它向Root证书机构申请证书（CA1需要持证上岗）；
Root CA呢，没有办法证明自己。你只能无条件信任Root CA！
那怎么做到无条件信任呢？ Root CA机构，都是一些世界上公认的机构，在你的操作系统、浏览器发布的时候，里面就已经嵌入了这些机构的Root证书。
你信任这个操作系统，信任这个浏览器，那也就信任了这些Root 证书。
想一想在现实生活中的例子：
你出生在一个小镇上，怎么证明你是你呢？
镇派出所给你发了个身份证，证明你是你。
镇派出所为什么可以被信任呢？ 县公安局授权给的它；
县公安局为什么可以被信任呢？ 市公安局授权给的它；
。。
一级级回溯，最后，信任的根是什么？ 根是国家政权！
下面就用IE浏览器，访问百度的网站，看一下它的数字证书：
点击链接最右边那个锁的图标
如下图所示：baidu.com这个是百度这个网站的证书，其CA机构是一个叫做Symantec Class ..的机构，Root CA机构叫做VeriSign。这个是内置在浏览器里面。
PKI
PKI，全称Public Key Infrastructure，其实就是1套上面讲的协议与体系。
这套协议和体系，定义了client到中间的CA server，CA server到上1级的CA server，到Root CA server之间的通信协议。
基于这个体系，就可以很方便的搭建CA server（CA server有很多实现，只要你符合这个协议），给client颁发证书。
从而也就达到了我们最初的目的：让大家安全的交互公钥（也就是数字证书，也就是每个人的身份证）。
所以其名字，才叫Public Key Infrastructure。
有兴趣朋友也可以进一步关注公众号“架构之道与术”， 获取原文。 或扫描如下二维码：
