客户端如何验证 SSL 中的服务器证书？
我阅读了很多关于这个主题的内容，所有“详细”的解释似乎都遗漏了一个步骤：
对于客户端验证服务器，它执行以下操作（根据我的理解）：
- 它从服务器获取证书。证书将包含公钥和数字签名。
2?) 客户端使用公钥验证签名是否正确。
这就是我困惑的原因。说我是中间的那个人。我可以连接到服务器并获取服务器提供给我的任何信息，然后将其转发给客户端。客户如何知道谁实际出示了证书？
以下是我一般也知道的：
客户端知道公钥。它用它加密消息并将其发送到服务器。
服务器知道私钥，解密消息并将其发回。
现在客户端可以与服务器共享对称密钥。
中间可以有一个人，但这没关系，因为没有私钥就无法解密数据。
那么这与证书中的（静态？）数字签名有什么关系呢？
请帮助我理解该特定步骤（验证签名）。
小智 30
证书的创建
首先，您通过提供证书签名请求 (CSR) 向证书颁发机构 (CA) 请求证书，该请求包含域详细信息和服务器的公钥。
CA将按照以下步骤颁发数字证书：
CSR 使用哈希算法进行签名，即 SHA256/md5 tp 生成哈希（CSR）
然后使用其CA/签名者私钥之一对散列 CSR 进行加密。即，加密（散列（CSR））
然后将加密的(hash(CSR))附加到CSR上，我们可以将其称为数字证书
简而言之：
数字证书 = CSR + 加密(hash(CSR))
证书验证：
服务器在建立 TLS 连接时将证书发送到用户代理（浏览器）。
然后用户代理（浏览器）查看证书，检查证书是否来自受信任的 CA。
如果它来自受信任的 CA，则用户代理会解析证书，我们将在其中获取 CSR 和加密（哈希（CSR））。
现在我们使用散列算法创建CSR的散列，我们生成散列（CSR）。
Encrypted(hash(CSR)) 使用 CA 的公钥进行解密。由此，我们将得到哈希值（CSR）。
如果步骤 4 中的 hash(CSR) == 步骤 5 中的 hash(CSR)，则证书已验证。
有关 TLS 中的密码套件和协商过程的更多详细信息，请参阅 TLS 握手过程。
如何/为何
我们的浏览器有受信任 CA 的公钥列表。
据推测，CA 是值得信赖的，并且拥有只有 CA 知道的私钥。
创建加密（散列（CSR））只能由 CA 使用私钥来完成。
因此，如果我们使用CA的公钥将加密的(hash(CSR))转换为哈希(CSR)，并验证这是正确的，我们就可以证明CA确实创建了加密的(hash(CSR))
经过进一步挖掘，我发现了我缺少的东西。
服务器提供带签名的证书文件。我缺少的是“数字签名算法”或类似的算法。
假设P是公钥，R是私钥。
基本上，如果 H 是输入，R 是私钥，我们得到 C 作为输出。
由于C是数字签名算法的结果，因此我们可以使用公共P和输出C来获得H。
这回答了我的问题的原因是：假设有人假装是服务器并且有能力准确重放 C。当然，证书看起来有效，但 C 无法继续进行，因为进一步的消息将使用公共 P 进行加密。
这是我从未见过的答案。
我在这里找到了信息： http ://www.jscape.com/blog/what-is-a-digital-signature
发现搜索结果底部的这篇旧文章是迄今为止最好的解释：
\n（较长的版本在这里，SSL Handshake (Sun Java System Directory Server Enterprise Edition 6.0 Reference)。如果它不起作用，这里是存档版本。）
\n\n\nSSL 握手期间的服务器身份验证
\n支持 SSL 的客户端软件始终需要服务器身份验证，或客户端对服务器\xe2\x80\x99s 身份进行加密验证。服务器向客户端发送证书以对其自身进行身份验证。客户端使用证书\n来验证证书声明所代表的身份。
\n要验证公钥与包含公钥的证书\n所识别的服务器之间的绑定，\n启用 SSL 的客户端必须收到对下图中所示的四个问题\n的肯定答案。
\n\n
图 2\xe2\x80\x939 在 SSL 期间验证客户端证书\n握手
\n启用 SSL 的客户端通过以下步骤来验证服务器\xe2\x80\x99s 身份：
\n\n
\n- \n
今天\xe2\x80\x99s日期是否在有效期内？
\n客户端检查服务器证书\xe2\x80\x99s的有效期。如果\n当前日期和时间超出该范围，\n身份验证过程将\xe2\x80\x99 不会继续进行。如果当前日期和时间在证书\xe2\x80\x99s 有效期内，客户端将继续执行下一步。
\n- \n
颁发 CA 是否是受信任的 CA？
\n每个启用 SSL 的客户端都维护一个可信 CA 证书列表，由图 2\xe2\x80\x939 右\xe2\x80\x94 侧的阴影区域表示。此列表确定客户端\n接受哪些服务器证书。如果颁发 CA 的可分辨名称 (DN) 与客户端\xe2\x80\x99s 受信任 CA 列表中的 CA DN 匹配，则此问题的答案\n为“是”，客户端将继续执行下一步。如果颁发的 CA 不在列表中，则不会对服务器进行身份验证，除非客户端可以验证以列表中的 CA 结尾的证书链。
\n- \n
颁发 CA\xe2\x80\x99s 公钥是否验证颁发者\xe2\x80\x99s 数字签名？
\n客户端使用 CA\xe2\x80\x99s 证书中的公钥（在步骤 2 中在受信任的 CA 列表中找到该证书）来验证所提供的服务器证书上的 CA\xe2\x80\x99s\n数字签名。如果服务器证书中的信息自 CA 签名后\n发生了更改，或者 CA 证书\xe2\x80\x99s 公钥与\nCA 用于签名的私钥不\n对应服务器证书，\n客户端不会验证服务器\xe2\x80\x99s 的身份。如果可以验证 CA\xe2\x80\x99s 数字\n签名，则服务器将用户\xe2\x80\x99s 证书\n视为来自该 CA 的有效\xe2\x80\x9d 简介\xe2\x80\x9d，并且收益。此时，客户端已确定服务器证书有效。
\n- \n
server\xe2\x80\x99s 证书中的域名与服务器本身的域名是否匹配？
\n此步骤确认服务器实际上位于服务器证书中\n域名指定的同一\n网络地址。尽管从技术上讲，步骤 4 不是 SSL 协议的一部分，但它提供了针对称为中间人的安全攻击形式的唯一保护。如果域名不\xe2\x80\x99 匹配，客户端必须执行此步骤，并且\n必须拒绝对服务器进行身份验证或建立连接。如果服务器\xe2\x80\x99 的实际域名\n与服务器证书中的域名\n匹配，则客户端\n继续下一步。
\n- \n
服务器已通过身份验证。
\n客户端继续进行 SSL 握手。如果客户端出于任何原因\xe2\x80\x99t\n未执行步骤 5，则无法对证书标识的服务器\n进行身份验证，并且会警告用户该问题并\n告知无法\n加密和经过身份验证的连接\n n成立。如果服务器需要客户端身份验证，服务器将执行 SSL 握手期间的客户端身份验证中描述的步骤。
\n完成此处描述的步骤后，服务器必须成功使用其\n私钥来解密客户端发送的预主密钥。
\n
| 归档时间： |
|
| 查看次数： |
11561 次 |
| 最近记录： |