浏览器如何验证HTTPS证书的合法性？

一 前提：

1. 证书存在的目的就是避免中间人攻击，避免发生经典的传令兵问题。
2. 证书都是由CA组织下认可的根证书Root签发的（其中有两种形式，第一种是该组织有一个Root，每一家的Root Ca都需要其签名，该方案基于利益考量几乎没人采用，而是第二种方案，每家都有自己的Root CA 可以自签或者互相签名)。这个组织很难进，目前几乎完全由欧美控制,每年都有轮值主席负责该年CA组织工作，主要涉及到新的RFC审核和修改，新的CA申请和已有CA日志审核以及提出新的CA方案等。其他不通过该组织认证的证书签发者都是不安全的，此外该组织会对每年每个CA签发的证书进行审核。因此可以保证正常途径签发的证书根是绝对可信的。所有改组织通过的CA会强迫浏览器和系统安装(常见的厂商有VeriSign, Microsoft, Oracle和Molliza 这也是强制力的来源)
3. 证书分为DV(Digital Verification)，OV(Organization Verification)和EV(Extended Verification)，其中EV证书最贵，可以在浏览器中看到绿色的就是EV证书。证书从申请到批准要走很久的流程，需要提供很多的公司认证信息和个人信息，否则是不会通过的。因此可以保证签发的证书内容是可信的。
4. 证书是需要预装的，特别是根证书。IE和Chrome是通过内置在Windows系统中的TrustStore来管理根证书（当然自己也可以手动导入自签证书，浏览不会认可的因为有OCSP和CRL--之后细讲）；而Firefox则是内置在自己的浏览中。
5. 综上，通俗的来说一个CA如果要商业化，要做以下几步：申请加入CA组织，然后向Microsoft提申请加入TrustStore(通过Windows自我更新或者通过其他证书导入时加入）和Mozilla组织申请加入Firefox TrustStore。

二 证书工作原理

以访问https://www.google.com(https)举例。
1. 浏览器发现此为HTTPS请求，握手拿到google的证书，先从系统(Windows)或者浏览器内置（Firefox）检查证书链是否正确。
【补充】简略步骤如下
a. 客户端发送信息，带上支持的SSL或者TLS版本(注意不同浏览器版本支持不同)
b. 服务器返回确认使用的加密通信协议版本以及加密随机数和证书
c. 浏览器验证证书 -> OCSP或者CRL 结合自带truststore
注意此处验证分为双向验证和单向验证，单向验证客户浏览器即可完成，即客户端truststore存放服务器public证书；双向验证客户浏览器需要带客户端证书到服务器端由服务器端验证，客户端truststore存放服务器端public证书，keystore存放自身private证书，服务器端truststore存放客户端public证书，keystore存放自身private证书。

 

2. 如果验证失败则会拦截(Edge浏览器)

3. 之后浏览器会尝试查CRL(证书吊销列表)和OCSP(在线证书检查)，其中OCSP是前者的替代和新技术，这是由于CRL发布时间一般是7天(不过接到新通知要改为1天了）并且很大不方便。但是考虑到老浏览器只能用CRL，并且CRL可以缓存本地对于网速差情况还是有用的，此外Firefox虽然支持OCSP但是可以手动关闭也是CRL存在的原因。

注意：CA不会直接暴露到外网的，如果需要访问CA服务器需要使用硬件Token并且多人在场录像，且只能远程访问。OCSP相当于证书数据库的备份而已是直接暴露在外网的可以通过HTTP或者HTTPS访问
4. 如果发现证书并没有被吊销或者过期则浏览器对EV证书会显示为绿色，对OV证书则是通过放行。否则弹出通知---该网站不可信(不同浏览器不同--Edge浏览器）

三 证书存在的问题

1. CA错签证书，最近比较经典的就是google被其他CA乱签了证书，这在CA界是很恐怖的一件事。谷歌是怎么发现的呢？ 这就要提到chrome采用了不同的CA管理机制叫做CT Log，每个CA在签证书前都要先把证书post到谷歌CA服务器去备份，这个谷歌就能知道自己的域名是不是被乱签了。
2. 依然有可能发生中间人攻击，比如使用真实CA签发的证书(要求证书链完整，即该软件必须有认证过的CA）替换掉要访问的网站的证书（需要拦截底层请求），模拟浏览器去验证OCSP等

转自：https://www.zhihu.com/question/37370216/answer/74060132
参考：https://blog.csdn.net/junwua/article/details/80506399