如何准确验证 SSL 证书 (CA)？
How SSL Certificates (CA) are validated exactly?
我正在搜索有关如何执行 SSL 验证过程的算法，但几乎所有地方都将证书验证步骤解释为“客户端检查证书”或类似内容，但我想知道这背后的场景是什么.
我知道的是：
当客户端收到属于website/server你想尝试握手的证书副本时，有一些指示器显示 public网络服务器信息（我认为这是为了匹配您的浏览器已安装的缓存证书条目中的条目。）
一旦客户端将缓存证书与网络服务器的证书相匹配，它就会开始验证它。 它使用缓存证书的 public 密钥来解密网络服务器的签名。（？[不确定，因为 public 密钥用于“加密”数据，而不是解密. 还有这一步可能完全错了。])
解密后，它会比较缓存的签名和网络服务器的签名。如果相同，则证书有效。
我也听说过锁链。我真的很想知道一个链是如何被知道的，以及如何确定网络服务器的证书是否只属于一个链。(?)
客户端如何检查 SSL 证书？我需要一步一步的回答和澄清。谢谢:)
编辑：
我认为这里的public密钥是用来“解密”而不是“加密”的。所以public密钥不负责每次加密，它也可以解密而不加密 一些数据。这里的神奇之处在于，由于 public 密钥在这里解密，如果您想伪造证书，您应该拥有该 CA 的私钥以应用加密的更改（因为只有 private 密钥可以加密数据）。但是现在，另一个问题来了......如果我们使用网络服务器的public密钥解密它，然后更改签名中的条目，然后使用我们的自己的[=再次加密它会怎么样？ 45=]私钥（我们手动生成的，它不属于服务器。），这实际上让我们表现得像一个CA；最后覆盖证书以保存我们的 own public 密钥，该密钥能够解密使用我们的 own 私钥加密的数据？
加密和签名之间存在差异。
Public客户端使用密钥加密只有服务器可以用服务器的私钥解密的数据。
Public Key 用于客户端验证Server 发送的数据的signature，只能由Server 的Private Key 签名。
当客户端想要访问服务器时，服务器会向您发送包含 public 密钥的证书。客户端通常 Web 浏览器将检查其集成 CA 的列表证书（如果包含）。
- 如果包含它，则客户端继续并获取授权此证书的 CA（证书颁发机构）。
- 如果未找到但签名验证通过，客户端将收到警告，指出该证书可能是自签名的并且可能是恶意的。
- 如果客户端无法验证签名，则表示证书无效。
对于信任链，您可以查看维基百科：
https://en.wikipedia.org/wiki/Chain_of_trust
您需要在此信任链中才能在 CA 的 Web 浏览器集成“数据库”中注册。
希望它能回答您的问题，此致，
男
简单地说：
私钥 -> 解密并签名
Public 密钥 -> 加密和验证
认证机构
是签署并保证认证真实性的权威机构。如果您信任 CA，那么您也信任它的证书。
朋友也是一样：如果你有一个你信任的朋友，这告诉你“我有一个我信任的朋友”，那么你也信任你朋友的朋友。
证书颁发机构链。
你可以有多个中间CA，比如你可以有
- 根证书颁发机构
由根证书颁发机构签署的 WebServer 中间证书颁发机构
- Web 服务器中级证书颁发机构签署的 Web 服务器证书
用于签署代码的中间证书颁发机构，由根证书颁发机构签署
- 等等
为什么？
因为万一其中一个中间机构遭到破坏，您只能撤销其子证书。
在企业层面，每个CA都有不同的安全级别，例如，根证书颁发机构可以存放在保险箱内，只有在有两个或多个管理员时才使用。
对于中级，相反，也许只有一个管理员可以管理它。
我正在搜索有关如何执行 SSL 验证过程的算法，但几乎所有地方都将证书验证步骤解释为“客户端检查证书”或类似内容，但我想知道这背后的场景是什么.
我知道的是：
当客户端收到属于website/server你想尝试握手的证书副本时，有一些指示器显示 public网络服务器信息（我认为这是为了匹配您的浏览器已安装的缓存证书条目中的条目。）
一旦客户端将缓存证书与网络服务器的证书相匹配，它就会开始验证它。 它使用缓存证书的 public 密钥来解密网络服务器的签名。（？[不确定，因为 public 密钥用于“加密”数据，而不是解密. 还有这一步可能完全错了。])
解密后，它会比较缓存的签名和网络服务器的签名。如果相同，则证书有效。
我也听说过锁链。我真的很想知道一个链是如何被知道的，以及如何确定网络服务器的证书是否只属于一个链。(?)
客户端如何检查 SSL 证书？我需要一步一步的回答和澄清。谢谢:)
编辑：
我认为这里的public密钥是用来“解密”而不是“加密”的。所以public密钥不负责每次加密，它也可以解密而不加密 一些数据。这里的神奇之处在于，由于 public 密钥在这里解密，如果您想伪造证书，您应该拥有该 CA 的私钥以应用加密的更改（因为只有 private 密钥可以加密数据）。但是现在，另一个问题来了......如果我们使用网络服务器的public密钥解密它，然后更改签名中的条目，然后使用我们的自己的[=再次加密它会怎么样？ 45=]私钥（我们手动生成的，它不属于服务器。），这实际上让我们表现得像一个CA；最后覆盖证书以保存我们的 own public 密钥，该密钥能够解密使用我们的 own 私钥加密的数据？
加密和签名之间存在差异。
Public客户端使用密钥加密只有服务器可以用服务器的私钥解密的数据。
Public Key 用于客户端验证Server 发送的数据的signature，只能由Server 的Private Key 签名。
当客户端想要访问服务器时，服务器会向您发送包含 public 密钥的证书。客户端通常 Web 浏览器将检查其集成 CA 的列表证书（如果包含）。
- 如果包含它，则客户端继续并获取授权此证书的 CA（证书颁发机构）。
- 如果未找到但签名验证通过，客户端将收到警告，指出该证书可能是自签名的并且可能是恶意的。
- 如果客户端无法验证签名，则表示证书无效。
对于信任链，您可以查看维基百科： https://en.wikipedia.org/wiki/Chain_of_trust
您需要在此信任链中才能在 CA 的 Web 浏览器集成“数据库”中注册。
希望它能回答您的问题，此致，
男
简单地说：
私钥 -> 解密并签名
Public 密钥 -> 加密和验证
认证机构
是签署并保证认证真实性的权威机构。如果您信任 CA，那么您也信任它的证书。 朋友也是一样：如果你有一个你信任的朋友，这告诉你“我有一个我信任的朋友”，那么你也信任你朋友的朋友。
证书颁发机构链。
你可以有多个中间CA，比如你可以有
- 根证书颁发机构
由根证书颁发机构签署的 WebServer 中间证书颁发机构
- Web 服务器中级证书颁发机构签署的 Web 服务器证书
用于签署代码的中间证书颁发机构，由根证书颁发机构签署
- 等等
为什么？
因为万一其中一个中间机构遭到破坏，您只能撤销其子证书。
在企业层面，每个CA都有不同的安全级别，例如，根证书颁发机构可以存放在保险箱内，只有在有两个或多个管理员时才使用。
对于中级，相反，也许只有一个管理员可以管理它。