TLS证书验证详情

信息安全 tls 证书 公钥基础设施 证书颁发机构 电子签名
2021-08-15 22:51:12

我确实了解密码学基础知识,但我不确定以下三个步骤:

第 1 步:如何计算 TLS 证书

如果我错了,请纠正我:证书颁发机构在相关证书信息(包括证书申请者的公钥)上计算哈希值,然后使用颁发机构的私钥对该哈希值进行签名。此过程的输出是单个证书文件,可以将其部署在有权访问相应私钥的服务器上。

第二步:如何验证服务器是否拥有TLS证书对应的私钥?

客户端在 TLS 握手期间从服务器获取证书。但仅凭证书不足以验证数据的真实性。(因为任何人都可以在不拥有私钥的情况下发送证书副本)因此我认为必须传输一些额外的随机信息,需要使用相应的私钥进行签名(也许也可以通过计算哈希)?

客户端是否使用证书的公钥解密此随机信息?这个检查是如何进行的?

第 3 步:如何验证证书是否由受信任的机构签署?

我认为这主要适用于预装的浏览器表,其中包含受信任机构的公钥(以及其他信息)。

证书颁发机构的公钥是否用于解密哈希值并检查它是否与整个证书上的自计算哈希值匹配?

1个回答

问题1的答案:

是的,除非 CA 的根在保管库中的 HSM 中脱机,不能以电子方式被盗。根用于签署一些中间证书(备份和 OCSP 响应者证书和其他东西),这些证书位于 HSM 中,这些证书直接连接到可以通过电子方式访问的计算机。

要颁发证书,CA“后端”:

  1. 接受企业社会责任
  2. 使用某种验证方法(ACME 协议、人工在管理网站上单击“确定”等)
  3. 记录所有用于做出决定的决定和信息,以供以后审计检查
  4. 使用模板和新的序列号/随机源生成以 X.690 DER 编码的证书数据 (X.509 v3)。
  5. 可能会获得证书透明度 SCT。
  6. 要求 HSM 签署 blob(或 blob 的哈希)。
  7. 将签名附加到证书并将其发送到面向客户的存储。

问题2的答案:

在 RSA 密钥交换中,客户端生成一个随机的字节序列,并使用服务器证书中的公钥执行 RSA 加密。然后客户端将生成的密文发送到服务器,并期望服务器对其进行解密(使用与证书中的公钥对应的私钥)并使用 KDF 中的随机值与其他值一起生成对称密钥和发送使用生成的对称密钥加密的 Finished 消息。客户端验证 Finished 消息。服务器只有通过解密 RSA 加密消息才能成功生成预期的对称密钥。https://www.rfc-editor.org/rfc/rfc5246#appendix-F.1.1.2

在与 PFS 的 DHE/ECDHE 密钥交换中,服务器使用与证书中的公钥对应的私钥对其临时密钥进行签名,并将其发送到 ServerKeyExchange。客户端使用证书中的公钥验证签名。https://www.rfc-editor.org/rfc/rfc5246#appendix-F.1.1.3

问题 3 的答案:浏览器包含可信根列表(Mozilla Firefox 这样做)或使用操作系统提供的可信根列表(谷歌浏览器使用 OS 根存储)。根存储包含自签名证书和一些关于它们的元数据,这些元数据可能会限制它们的用途。浏览器还包含添加额外检查的代码,例如要求赛门铁克拥有的 CA 提供证书透明度的 Chrome 以及允许使用 SHA1 证书的截止日期。

使用根存储验证叶服务器/域证书的方式是构建一个中间证书链,一个签名另一个,从受信任的根到叶。根标记中间,中间标记叶子。一条链中可以有多个中间体。中间件与叶子一起由服务器发送。 https://en.wikipedia.org/wiki/Certification_path_validation_algorithm

不同的计算机有不同的根存储,通过使用交叉签名,可以构建许多不同的路径。目前,浏览器会尽可能尝试构建仅限 sha256 的路径,有时会失败并产生错误,指出仅构建了 sha1 路径,因此连接可能不安全。

不要将数字签名与加密混淆:https ://security.stackexchange.com/a/87373/70830