HTTPS 和证书答案

【问题标题】：HTTPS and certificatesHTTPS 和证书
【发布时间】：2011-04-09 05:18:25
【问题描述】：

HTTPS 在接受证书方面如何工作？

【问题讨论】：

【解决方案1】：

非常简单地加上一个小故事：

客户端：（连接到服务器并伸出手）“你好！这是我的加密细节。”

服务器：（握住客户端）“您好。这是我的加密详细信息。这是我的证书。” （握手协商完成，客户检查证书）

客户：太好了，这是我的钥匙！所以从现在开始，一切都使用这个密钥加密。好吗？

服务器：好的！（SSL 握手完成）

客户端：太好了，我的 HTTP 数据来了！！

Certificates 用于SSL handshake。服务器交给客户端的证书是 signed 由 Certificate Authority (CA) （如 VeriSign）提供，并且特定于服务器。 SSL 握手中会发生各种检查。需要了解的重要内容之一是证书的 Common Name 属性必须与服务器的主机/DNS 名称匹配。

客户端拥有 CA 的 public certificate (key) 的副本，因此可以使用它（例如使用 SHA1 计算）来查看服务器的证书是否仍然正常。

【讨论】：

【解决方案2】：

首先我们需要区分服务器端证书和客户端证书。

在大多数情况下，仅使用服务器端证书。它用于让客户端通过验证服务器的证书来验证客户端连接的服务器的真实性（验证过程将在下面描述）。这样做应该可以防止中间人 (MITM) 攻击。

当我们需要限制对服务器的访问仅限于某些用户时，使用客户端证书。为此，客户端使用证书对自己进行身份验证。由于用户集通常是有限的（根据某些标准，它在现实生活中可能非常大），验证过程通常与服务器证书验证过程有点不同。

接下来，关于验证本身。

在客户端验证服务器证书时，客户端采取以下步骤：

查找颁发者 (CA) 证书并使用颁发者证书检查服务器证书的签名（跳过技术细节）。
检查证书有效期（从什么时候到什么时候应该接受证书）。
检查证书的预期用途（每个证书只能用于某些用途）。
检查是否已为服务器所在的域名（或 IP 地址）颁发证书。
检查证书是否未被 CA 取消（吊销）。这是通过检查证书撤销列表 (CRL) 并使用 OCSP 协议发送即时请求来完成的。
由于 CRL 和 OCSP 响应是使用证书签名的，因此它们的签名也会按照上述方式进行验证。
对步骤 (1) 中提到的 CA 证书重复该过程，并一直持续到您获得受信任的根 CA 证书（假设客户端具有一组受信任的根证书）。

当服务器验证客户端的证书时，上述过程通常会被简化，因为同一个系统是一个 CA 和一个服务器对其的访问被验证。在这种情况下，证书可以直接与允许的证书列表匹配，也可以不需要上述大多数步骤。

【讨论】：