加密传输SSL协议6_验证公钥
如上图所示，我怎么能确定我手里的公钥就是我心中的接收方的公钥呢？怎么防止被钓鱼呢？
解决的办法就是引入一个第三方，一个权威机构，一个我们都相信的机构。
验证公钥，Digital Certificate
显然，这不是一个用技术所能解决的问题，很好的解决办法就是建立一个中介，我们所有的人都相信这个中介，中介对接收方的公钥的合法性进行认证，在接收方的公钥上签名，这样发送方在相信中介的基础上就能安全的给接收方发送信息了。
具体的做法就是：中介要求接收方在他这里注册，验证其公钥，然后中介对接收方的公钥进行签名，也就是中介用自己的私钥对接收方的公钥进行加密。然而中介的公钥是众所周知，任何人都知道，不会被任何人假冒的，发送方如果能用中介的公钥认证这份证书，就证明里面的接收方的公钥是注册过的，是合法的。就能安全的给接收方发送信息了。
也即是说如果我们想给某个人发送信息，必须得到他的公钥，但是为了防止钓鱼，这个公钥必须得被我们相信的中介签名后才是安全的。
注意：这个证书仍是通信双方通信时，接收者给出的，不同的是这个证书已经被我们相信的中介签过名。
这里面用到了哈希函数的知识，因为非对称加密对大的数据加密速度很慢，所以通常的做法是把接收方的公钥和DN这个字符串组合成同一个文件，生成其相应的哈希值，然后中介只需要对这个哈希值进行签名，发送方在给接收方发送数据时，只对哈希值进行认证，就能核对公钥和DN的值是否合法。一张数字证书包含接收方的公钥、DN信息、签过名的哈希值。
一张数字证书的前两部分是我们需要的接收方的信息，DN是distinguished name，就是接收方的ID。那么我们怎么确信这个ID和这把公钥是真的对应关系呢？那么就要看下面的签过名的哈希值（特征码）。
CA的签名过程：首先接收方要在CA那里主存，当然这不是免费的，然后CA把接收方的DN和他的公钥打包。然后对打包后的文件Hash一下，产生其特征码。CA用自己的私钥对特征码加密（签名）。然后把这三个东西给接收方，注册完成。
发送方的验证过程：在通信开始的阶段，发送方为了加密传输问接收方要其公钥，同时为了防止钓鱼，还应给出DN信息和CA签过名的哈希值。发送方把公钥和DN信息打包，然后用和CA同样的算法得到其Hash值，然后用CA的公钥解密接收方给的Hash值，对比两个Hash值，如果相同，那么就是合法的。
