目录
引言
从https://blog.csdn.net/sarafina527/article/details/89333536 握手一文中讲到 ssl握手时需要验证通信双方证书，验证机制时怎样的呢，什么情况能验证通过呢？
当服务端S证书 与 本地系统的根证书 （如下图有很多根证书）能够构成证书链，就能验证通过，否则不通过。
1. 数字证书
数字证书确保公钥所有者的身份。下图是一个实际的证书，最重要的是Subject、Issuer和Public Key。
以上的百度服务端证书是在访问百度首页的时候，在chrome 开发者工具 Security Tab页找到的（如下图）
根据图中分析，百度发过来的证书与系统根证书构成了一个长度为3的证书链，所以浏览器显示验证通过！
1.1 证书组成
其中Subject标识该证书，通常根据Subject.CN（常用名称COMMON NAME）认识证书（类似与人的姓名，但并不唯一标识）
公钥 Public Key，通常用于非对称加密，跟对端通信若要求非对称加密的话，将证书作为非对称公钥的载体一起发给对端！
而Issuer（签发者）是对其签名的CA（证书颁发机构），通常能通过认证的证书需要跟CA 购买～，相当于出钱让权威给你站台担保啦～
可以把Issuer想象成一个指针，指向下一跳证书。证书中还包含CA用其证书里的公钥对 当前证书的签名。
| 主体名 Subject | 证书持有人的唯一标识符(或称DN-distinguished name) |
| 公钥信息 Public Key | 包括证书持有人的公钥、算法，用于非对称加密 |
| 颁发者名称 Issuer | CA证书颁发者的可识别名（DN），是签发该证书的实体唯一的CA的X.500名字 |
2. 信任传递
本地导入的系统根证书 表示你信任这些根证书，服务端S证书是由根证书（CA）机构签发的（类似与为之担保），表示你也能信任 你信任的机构担保的服务！（传递性：你信任CA，CA信任服务端S => 你信任服务端S）
可能大家都有这样的体验，浏览器访问https网页会出现类似下面的页面，这是由于浏览器不信任这个服务给用户的警告提示，
看图中的的错误码，ERR_CERT_AUTHORITY_INVALID，证书认证不通过。
左图是单向认证，浏览器（客户端）在握手是认证网站（服务端）不通过，解决这个警告的方法是在（右图）浏览器中导入该网站的证书。
但是网站太多了，浏览器一一导入很困难，所以有了一种证书认证机制：
类比生活中，比如我信任我的直接朋友A（链尾），A为我不认识的陌生人B担保，我也可以信任陌生人B。
2. 证书链
证书链本质上就是信任的传递，
百度主页 的证书链 如下图，链长为3，抽象一下如右图所示，百度在申请subject为其域名的证书时，向GlobalSign申请， GlobalSign是中国首屈一指的数字证书授证权威。
baidu.com是head证书（链表的header），下一跳指针是GlobalSign G2，根据这个标识，找到下一跳；
GlobalSign G2是中级证书，下一跳指针是GlobalSign Root CA，继续往下
GlobalSign Root CA是根证书，根证书是自签名的一个证书，（如下图 签发者是自己），没有下一跳，链表的尾巴。
此时的链长就是3.
当你的系统或者浏览器等选择信任GlobalSign Root CA这个证书，当访问baidu.com时，构建好了完整的证书链，所以对baidu.com也是信任的。
双向认证时 时服务端也需要认证 客户端证书，认证的方式时一样的～
总结
因为在认证一个证书的时候，会先构建一个证书链，如果你信任证书链尾，你就可以信任证书链头，因为证书链尾在信任上一跳的情况才会给它签名，这样就达到了信任传递的效果。