HTTPS和证书

Question

HTTPS如何在接受证书方面发挥作用？

Answer 1

非常吝啬地提出小故事：

  

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

     

服务器 :(取得客户端）“你好。这是我的加密详情。这是我的证书。” （握手协商完成。客户检查证书）

     

客户：太棒了，这是我的钥匙！因此，从现在开始，所有内容都使用此密钥加密。 OK？

     

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

     

客户：太棒了，这是我的数据通过HTTP !!

Certificates中使用了

SSL handshake。服务器向客户端发送的证书signed由Certificate Authority（CA）（如VeriSign）提供，并且特定于服务器。 SSL握手中会发生各种检查。其中一个重要的事项是证书的 Common Name 属性必须与服务器的主机/ DNS名称匹配。

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

Answer 2

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

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

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

接下来，关于验证本身。

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

1. 查找颁发者（CA）证书并使用颁发者证书检查服务器证书的签名（跳过技术详细信息）。
2. 检查证书有效期（从何时到应该接受证书）。
3. 检查证书的预期用途（每个证书仅限于某些用途）。
4. 检查是否已为服务器所在的域名（或IP地址）颁发了证书。
5. 检查CA是否未取消（撤销）证书。这是通过检查证书吊销列表（CRL）和使用OCSP协议发送动态请求来完成的。
6. 由于CRL和OCSP响应是使用证书签名的，因此其签名也会按上述方式进行验证。
7. 对步骤（1）中提到的CA证书重复该过程，这将持续到您获得受信任的根CA证书（假设客户端具有一组受信任的根证书）。

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