关于公钥基础设施工作流程的一些理解差距

Question

最近，我偶然发现了对 PKI 实际工作过程的基本了解。我看过关于原则的主要文章，但我仍然觉得理解这个过程很愚蠢。我知道 PKI 不是为了“我的博客”，但为了简单起见，让我们通过简单的示例“我的电子商店”（例如 apache 和 php）和简单的概念。我写了一些可能含糊不清甚至是错误的陈述，但这就是我想了解的有关 PKI 过程的内容：

1. “我的 e-Shop”作为一家公司需要在某个第三方 CA 进行“认证”。这意味着我需要在该 CA 购买某种 1 年的会员资格，然后，他们将在他们的系统上注册“我的 e-Shop”并给我一些东西，比如证书和一对唯一的公钥和私钥。我会得到一些证书文件吗？

2. 颁发的证书包含我的信息和公钥，并存储在我的网络服务器上的某个文件中。证书证明“我的网店”不是盗贼局。

3. 每次用户通过“https”访问“My e-shop”时，他们的浏览器都会“默默地”检查所提供的“My e-shop”证书与在CA注册的证书。

   1. 用户呢？通过https进入“我的网店”时，他们的浏览器会生成本地公钥+私钥吗？

4. 当某些用户通过 https 进入“我的电子商店”时，会发生以下情况：“我的电子商店”（网络服务器）获取用户的公钥 (PK1)。服务器默默地把“我的网店”的证书呈现给用户，这样用户就得到了“我的网店”的公钥（PK2）。经过一些静默检查后，用户的浏览器会验证提供的证书并建立安全管道。

5. 当用户通过安全管道发送请求时，请求会使用“My e-shop”的公钥加密。然后，Web 服务器使用其私钥解密请求。然后，Web 服务器使用用户的公钥发送加密响应。最后，用户的浏览器用他的私钥解密响应。

Answer 1

逐个提问：

(1) “我的网店”作为公司需要 在某些第三方 CA “认证”。 这意味着我需要购买某种 该 CA 的 1 年会员资格，以及 然后，他们将注册“我的电子商店” 在他们的系统上给我发一些 证书和一对之类的东西 唯一的公钥和私钥。 我会得到一些证书文件吗？

是的。此外，这因 CA 而异——一些 CA、1 年会员资格和一张有效的信用卡就足够了（不难获得，即使你碰巧是一群小偷），一些 CA 需要一定数量的文书工作验证你就是你所说的那个人。 CA 的好坏取决于它的客户验证流程，因此通常流程越繁琐，CA 就越好（也越贵）。

当您付款并完成文书工作后，您和 CA 将产生至少 2 件事：

• 公钥/私钥对。通常这是由您生成的，而不是由 CA 生成的。您生成和存储密钥对的质量也是决定另一个实体可以信任您的网站的程度的一个因素。通常，对于标识证书（如 SSL 服务器证书），最好让客户（我的电子商店）生成密钥。
• 您将以标准格式（例如：PKCS10）向 CA 发送证书请求。它将包含大量关于 My e-Shop 和公钥的信息。
• CA 公司将检查您的文书工作并确保您是您本人。然后它将使用它的 CA 为您数字签名证书。该证书包含您刚刚提供的一堆信息、CA 提供商为您设置的一些额外信息、您的公钥以及通过将所有上述数据与 CA 的私钥加密绑定而生成的数字签名。

你会得到两件事之一：

• 只是证书（如果您生成了自己的密钥对）
• 证书和密钥对 - 如果 CA 为您生成密钥对

(2) 颁发的证书填写我的 信息和公钥并存储在 我的网络服务器上的一些文件。这 证书验证“我的 e-shop”不是盗贼局。

是的……有点。您的网络服务器将需要签名证书和密钥对。密钥对用作与最终用户的 SSL 握手的一部分，并且该交换证明您拥有密钥对，而不是某些获得证书的小偷。这就是您要保护密钥对的原因。

(3) 每次用户访问“我的网店” 通过“https”他们的浏览器 “悄悄地”检查呈现的 “我的网店”证书与 在 CA 注册的。

对于“沉默”的一些定义。基线浏览器检查证书： - 当前有效 - 由浏览器信任的 CA 签名（或者拒绝访问或给你一个烦人的弹出窗口）

浏览器插件会走得更远，并执行诸如完整路径检查（一直到自签名根）和证书状态检查之类的事情。通过管道共享信息的风险越高，需要进行的检查就越多。

(4)当有用户进入“我的网店”时 通过 https 会发生以下情况：“我的 e-shop”（网络服务器）向公众开放 用户的密钥（PK1）。服务器 默默地出示证书 “我的电子商店”给用户，所以 用户获取公钥（PK2） “我的电子商店”。一阵沉默后 检查用户的浏览器 验证提交的证书和 已建立安全管道。

• 用户呢？他们的浏览器通过https进入“我的网店”时是否会生成本地公钥+私钥？

好的 - 这里的东西正在脱轨。

有关详细信息，请查看 SSL 协议 - 握手部分将为您提供确凿的事实。

浏览器和网络服务器确实会来回传递信息，以便它们创建会话加密密钥。浏览器确实会生成一些用于设置会话的起始材料，但它不是“用户的公钥 (PK1)”。除非服务器已配置为进行客户端身份验证，否则用户不需要拥有 PKI 凭据。在我的 e-Shop 的常规运行中，服务器具有 PKI 凭据，浏览器正在为该会话生成一些动态的关键材料。服务器完全不知道浏览器用户是谁，SSL 方面 - 所有用户标识都来自密码或应用程序级别的其他内容。

注意：这是针对常规商业交易。风险越高，保护越大。高风险交易经常需要客户身份验证。

(5) 当用户通过 请求的安全管道 用“我的”公钥加密 电子商店”。然后，Web 服务器解密 请求及其私钥。 然后，网络服务器发送加密 用公钥响应 用户。最后，浏览器 用户用他的解密响应 私钥。

不完全是。这是杂草——Web 应用程序的开发人员相对地从所有这些中抽象出来。但是 - 会话内容没有使用非对称密钥加密 - 这将非常耗费 CPU。服务器的 PKI 和动态浏览器生成的握手数据用于交换会话加密密钥。其中一部分是客户端选择并发送在服务器的公钥中加密的密钥。由于只有服务器拥有私钥，所以只有服务器才能解密客户端发送的数据。

此密钥是对称的（确切地说，哪个算法也是握手的一部分）并用于会话的其余部分。

Answer 2

您的步骤在几个不同的级别上不正确。让我重述它们，希望以清晰的方式。

1. 您的网站需要拥有来自受信任第三方 CA（威瑞信等）的 SSL 证书。您需要从他们那里购买。您将生成公钥/私钥对，向他们提供您的公钥（这是证书请求的一部分），然后他们将生成证书。

2. 证书包含您网站的域名、您的公钥和一些其他附加信息。它不会验证任何内容，尤其是您的网站不是“盗贼局”。它通常只证明您拥有您申请证书的域名。这并不意味着您的网站在任何方面都是值得信赖的。

3. 当用户通过 HTTPS 访问您的站点时，您的服务器会将证书发送到客户端的浏览器。客户端绝不会与 CA 通信以验证您的证书。

3.1。通常，最终用户（客户、客户）不需要他们自己的证书和私钥。这称为相互验证 SSL，并且涉及双方（您的客户和您的站点）都拥有证书。这在电子商务网站中很少（如果有的话）使用。

1. 当用户通过 HTTPS 访问您的站点时，您的服务器会将证书发送到客户端浏览器。客户端将使用它来执行 SSL 握手。浏览器和您的站点之间的这种握手是建立安全隧道的原因。握手协议的细节比您需要的更具技术性。

2. 当请求通过 SSL 隧道发送到服务器时，服务器会以与任何其他请求相同的方式处理它。唯一的区别是您的客户和您的服务器之间的通信是加密的。您的网络服务器可能会处理来自请求的数据解密并将其呈现给您的网络服务器进行处理。同样，响应数据通过 SSL 隧道以加密形式返回给客户端。

更好？

Answer 3

关于第 3 点：

据我所知，这并不完全正确。由于实际上并没有一种已建立的实时测试基础设施（与 DNS 等服务相比），因此 Web 服务器会将完整的证书链发送到浏览器。 另一方面，浏览器或操作系统附带一组受信任的根证书（有时需要更新、Windows 更新、新的浏览器版本等）

是的，浏览器应该生成一个“不受信任”的密钥对，因为在正常情况下，标准用户不会生成他或她自己的证书。

关于第 5 点：

这也不完全是事实。异步加密的计算需要大量时间。所以 RSA 算法只是用来交换密钥以获得更快的同步加密标准（即 AES、3TES）。