介绍
HTTPS（通过SSL /TLS）用途 公钥加密 以防止浏览器通信在Internet传输过程中被读取或修改。 服务器为访问的浏览器提供一个公用密钥，该公用密钥用于为所有后续数据交换建立加密连接。
但是，只收到一个 加工 单独的公共密钥并不能保证它（以及扩展服务器）确实由正确的远程拥有。 主题 （即个人，公司或组织）。 人在这方面的中间人 攻击者可以操纵网络提供自己的密钥，从而破坏任何通信。
浏览器通过 认证中 HTTPS服务器使用 证书，这些数字文档 绑定 单个主题的公共密钥。 绑定是通过具有信任来声明的 认证机构 （CA），例如 SSL.com 通过针对合格数据库的自动和手动检查，验证潜在证书所有者的身份。
这种信任关系意味着Web用户的安全性不是绝对的。 相反，它要求用户信任浏览器和CA以保护其安全性。 因此，我们认为对证书验证的工作原理有一个基本的了解符合每个用户的利益。
请注意，证书验证过程（在标准文档中有详细说明 RFC 5280）非常复杂。 在本文中，我们将尝试引导您走一条路（通过浏览器验证主机的SSL /TLS 证书）并浏览对大多数用户而言无关紧要的复杂细节。
证书和X.509格式
证书在各个方面都是数字文件，这意味着它们需要遵循一种文件格式来存储信息（例如，签名，密钥，颁发者等）。 虽然私人 PKI 配置可以为其证书实施任何格式，并且是公共信任的 PKI（即浏览器信任的）必须符合RFC 5280，这要求使用 X.509 v3 格式。
X.509 v3允许证书包含其他数据，例如使用限制或策略信息，如下所示： 扩展，每个扩展名是 危急 or 非关键。 浏览器可以忽略无效或无法识别的非关键扩展，但是它们需要处理和验证所有关键扩展。
认证路径和路径处理
CA使用私钥对所有颁发的证书进行加密签名。 这样的签名可以不可撤销地证明证书是由特定的CA颁发的，并且在签名后没有被修改。
CA通过持有自行签发的证书（称为证书颁发机构）来建立其签名密钥的所有权。 根）对应的公钥。 CA必须遵守严格控制和审核的程序才能创建，管理和利用根，并且为了最大程度地减少暴露，通常会使用根来发布 中间 证书。 然后可以使用这些中间体来发行其客户的证书。
浏览器附带了受信任根的内置列表。 （这些是来自CA的根，这些CA已经通过了浏览器的严格包含标准。）为验证证书，浏览器将获得一系列证书，每个证书都对该序列中的下一个证书进行了签名，并将签名CA的根与服务器的根相连。证书。
此证书序列称为 认证路径。 路径的根称为 信任锚 服务器的证书称为 叶 or 最终实体 证书。
路径建设
通常，浏览器必须考虑多个证书路径，直到找到给定证书的有效证书路径为止。 即使路径可能包含正确地“链接”到已知锚点的证书，但由于路径长度，域名，证书使用或策略的限制，路径本身可能会被拒绝。
对于浏览器遇到的每个新证书，构造和评估所有可能的路径是一个昂贵的过程。 浏览器已经实现了各种优化，以最大程度地减少拒绝的候选路径的数量，但是深入研究此类细节超出了本文的范围。
路径验证
构建候选证书路径后，浏览器将使用证书中包含的信息对其进行验证。 如果浏览器可以用密码证明从信任锚直接签名的证书开始，则每个路径的相应私钥都被用来颁发路径中的下一个证书，直到下一个叶子证书为止，该路径才有效。
认证路径验证算法
RFC 5280描述了 标准算法 浏览器遵循以验证X.509证书的认证路径。
基本上，浏览器从信任锚（即根证书）开始遍历路径中的所有证书，从而验证每个证书的基本信息和关键扩展。
如果该过程以路径中的最后一个证书无误结束，则该路径被视为有效。 如果产生错误，则将该路径标记为无效。
基本证书处理
无论任何扩展，浏览器都必须始终验证基本证书信息，例如签名或发行者。 以下各节显示了浏览器执行的检查顺序。
1.浏览器验证证书的完整性
- 签名 可以使用普通的公钥密码学来验证证书上的密码。 如果签名无效，则证书在颁发后被视为已修改，因此被拒绝。
2.浏览器验证证书的有效性
证书的 有效期 是签名CA保证将保留有关其状态的信息的时间间隔。 浏览器拒绝任何有效期在验证检查的日期和时间之前或之后开始的证书。
3.浏览器检查证书的吊销状态
颁发证书后，预计将在整个有效期内使用该证书。 当然，各种情况都可能导致证书在自然过期之前失效。
此类情况可能包括主体更改其名称或怀疑其私钥受到损害。 在这种情况下，CA需要吊销相应的证书，用户也将信任放在CA中，以将其证书的吊销状态通知浏览器。
RFC 5280 建议CA为此目的使用吊销列表。
证书吊销列表（CRL）
CA定期发布签名的，带时间戳记的吊销证书列表，称为“ a”。 证书吊销列表 （CRL）。 CRL分布在公共存储库中，浏览器可以在验证证书时获取并查阅CA的最新CRL。
此方法的一个缺点是吊销的时间粒度仅限于CRL颁发期。 仅在所有当前发布的CRL被安排更新后，浏览器才会收到撤销通知。 根据签署CA的政策，这可能需要一个小时，一天甚至长达一周的时间。
在线证书状态协议（OCSP）
还有其他方法来获取吊销状态信息，其中最流行的是 在线证书状态协议 （OCSP）。
在标准文件中描述 RFC6960，通过OCSP，浏览器可以从在线OCSP服务器（也称为OCSP服务器）中请求特定证书的吊销状态 回应者）。 正确配置后，OCSP会更加即时，并且可以避免上述CRL更新延迟问题。 此外， OCSP装订 提高性能和速度。
4.浏览器验证发行者
证书通常与两个实体关联：
浏览器检查证书的 发行者 字段与 主题 路径中先前证书的字段。 为了增强安全性，大多数 PKI 实现还验证发行者的密钥与签署当前证书的密钥相同。 （请注意，对于信任锚，这不是正确的，因为根是自我颁发的，即，它们具有相同的颁发者和主题。）
约束处理
X.509 v3格式允许CA定义关于如何验证每个证书并将其用作关键扩展的约束或限制。 路径中的每个证书都可能施加所有后续证书必须遵守的附加约束。
尽管证书约束在企业SSL解决方案中很常见，但很少影响普通的Internet用户。 功能约束可以用于多种操作目的，但最重要的用途是减轻已知的安全问题。
5.浏览器检查名称约束
具有适当功能的私有（但受公共信任）中间CA 名称限制 可以为组织提供对证书管理和颁发的精细控制。 证书可以限于公司或组织域名的特定域或域树（即包括子域）。 名称约束通常用于从公共信任的CA购买的中间CA证书，以防止中间CA为第三方域颁发完全有效的证书（例如， google.com).
6.浏览器检查策略约束
证书策略是由CA发布的法律文档，正式详细说明了证书颁发和管理证书所遵循的过程。 CA可能会根据一个或多个策略来颁发证书，并且所颁发的每个证书中都包含这些证书的链接，以便依赖方可以在决定信任该证书之前评估这些策略。
出于法律和运营方面的原因，证书可能会对所遵循的策略施加限制。 如果发现证书包含关键策略约束，则浏览器必须在继续之前验证它们。 （但是，关键的政策约束在现实世界中很少遇到，因此在本文的其余部分中将被忽略。）
7.浏览器检查基本约束（又名路径长度）
X.509 v3格式允许颁发者定义证书可以支持的最大路径长度。 这样可以控制每个证书可以放置在证书路径中的距离。 这实际上很重要–在研究人员于2009年证明之前，浏览器曾经无视认证路径的长度 ，他如何使用网站的叶子证书为大型电子商务网站伪造有效证书。
8.浏览器验证密钥用法
“密钥用法”扩展说明了证书中包含的密钥的用途。 此类目的的示例包括加密，签名，证书签名等。 浏览器拒绝违反其密钥使用限制的证书，例如遇到带有仅用于CRL签名的密钥的服务器证书。
9.浏览器继续处理所有剩余的关键扩展
处理完上述扩展后，浏览器将继续验证当前证书指定为关键的所有其余扩展，然后再继续进行下一个扩展。 如果浏览器没有错误地到达路径的叶证书，则该路径被视为有效。 如果产生任何错误，则将路径标记为无效，并且不会建立安全连接。
结语
万维网是由相互连接且不断发展的运动部件组成的复杂系统。 因此，浏览器的安全性不是一个解决的问题，我们希望本文能够对我们在此介绍过的一个组件的复杂性提供一些见识。 信任在确保您的在线安全方面起着重要作用，因此，我们敦促您询问有关CA证书策略的更多信息。 （随时查看 SSL.com的政策在这里， 事实上。）
感谢您选择SSL.com，我们相信 更安全 互联网是一个 更好 互联网上。
