了解公钥基础设施工作流程的差距

Question

最近,我偶然发现了对PKI行动过程的基本了解.我看过关于这些原则的主要文章,但我仍然对理解这个过程感到愚蠢.我知道PKI不适用于"我的博客",但为了简单起见,我们来看看简单的例子"我的电子商店"(例如apache和php)和简单的概念.我写了一些可能含糊不清甚至错误的陈述,但这就是我想知道的关于PKI过程的内容:

1. 作为公司的"我的电子商店"需要在某些第三方CA"认证".这意味着我需要在该CA购买某种1年的会员资格,然后,他们将在他们的系统中注册"我的电子商店"并向我发送一些证书和一对独特的公钥和私钥等内容.我会得到一些证书文件吗？

2. 已发行的证书中包含我的信息和公钥,并存储在我的网络服务器的某个文件中.证书证明"我的电子商店"不是盗贼局.

3. 每当用户通过"https"访问"我的电子商店"时,他们的浏览器"默默地"检查所呈现的"我的电子商店"证书与在CA注册的证书.

   1. 用户怎么样？当他们通过https输入"我的电子商店"时,他们的浏览器会生成本地公共+私钥吗？

4. 当某些用户通过https输入"我的电子商店"时,会发生以下情况:"我的电子商店"(网络服务器)获取用户的公钥(PK1).服务器默默地向用户呈现"我的电子商店"证书,因此用户获得"我的电子商店"的公钥(PK2).在一些静默检查之后,用户的浏览器验证所呈现的certiticate并建立安全管道.

5. 当用户通过安全管道发送请求时,请求使用"我的电子商店"的公钥加密.然后,Web服务器使用其私钥解密请求.然后,Web服务器使用用户的公钥发送加密响应.最后,用户的浏览器用他的私钥解密响应.

Answer 1

逐个问题地回答这些问题：

\n\n

(1) \xe2\x80\x9c我的 e-Shop\xe2\x80\x9d 作为一家公司需要\n \xe2\x80\x9c在某个第三方 CA 进行\xe2\x80\x9d 认证。\n 这意味着我需要在该 CA 购买某种\n 1 年会员资格，\n 然后，他们将在他们的系统上注册 \xe2\x80\x9cMy e-Shop\xe2\x80\x9d\n 并向我发送一些\n 类似的东西一个证书和一对唯一的公钥和私钥。\n 我会得到一些证书文件吗？

\n\n

是的。此外，每个 CA 的情况各不相同 - 有些 CA 需要 1 年会员资格和有效的信用卡就足够了（并不难获得，即使您碰巧是一群小偷），有些 CA 需要一定数量的文书工作验证您的身份。CA 的好坏取决于其客户验证流程，因此通常流程越繁琐，CA 就越好（也越贵）。

\n\n

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

\n\n

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

\n\n

您将得到以下两件事之一：

\n\n

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

\n\n

(2) 颁发的证书包含我的信息和公钥，并存储在我的网络服务器上的某个文件中。该\n 证书验证\xe2\x80\x9cMy\n e-shop\xe2\x80\x9d 不是盗贼局。

\n\n

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

\n\n

(3) 每次用户通过\xe2\x80\x9chttps\xe2\x80\x9d访问\xe2\x80\x9c我的网店\xe2\x80\x9d\n时，他们的浏览器\n \xe2\x80\x9csilently\xe2\ x80\x9d 将 \xe2\x80\x9cMy e-shop\xe2\x80\x9d 所提供的\n 证书与在 CA 注册的\n 证书进行检查。

\n\n

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

\n\n

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

\n\n

(4) 当某些用户通过 https 输入 \xe2\x80\x9cMy e-shop\xe2\x80\x9d\n 时，会发生以下情况： \xe2\x80\x9cMy\n e-shop\xe2\x80\x9d (网络服务器)获取用户的公钥 (PK1)。服务器默默地将\n \xe2\x80\x9cMy e-shop\xe2\x80\x9d 的证书呈现给用户，因此用户\n 获得\n \xe2\x80\ 的公钥(PK2) x9c我的网店\xe2\x80\x9d。经过一些静默检查后，用户的浏览器会验证所提供的证书并建立安全管道。

\n\n

\n
• 用户呢？通过 https 输入 \xe2\x80\x9cMy e-shop\xe2\x80\x9d 时，他们的浏览器是否会生成本地公钥+私钥？
\n

\n\n

好吧——这里的事情有点脱轨了。

\n\n

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

\n\n

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

\n\n

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

\n\n

(5) 当用户通过安全管道发送请求时，请求将使用 \xe2\x80\x9cMy\n e-shop\xe2\x80\x9d 的公钥进行加密。然后，Web 服务器使用其私钥解密请求。然后，Web 服务器使用用户的公钥发送加密的响应。最后，用户的浏览器用他的私钥解密响应。

\n\n

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

\n\n

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

\n