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

Question

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

“我的电子商店”作为一家公司需要在某个第三方 CA 进行“认证”。这意味着我需要在那个 CA 购买某种 1 年的成员(member)资格，然后，他们将在他们的系统上注册“我的电子商店”，并向我发放一些东西，比如证书和一对唯一的公钥和私钥。我会得到一些证书文件吗？

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

用户每次通过“https”访问“我的网店”时，他们的浏览器都会“静默”检查“我的网店”出示的证书和在CA注册的证书。

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

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

当用户通过安全管道发送请求时，请求会使用“我的电子商店”的公钥进行加密。然后，Web 服务器使用其私钥解密请求。然后，Web 服务器使用用户的公钥发送加密响应。最后，用户的浏览器用他的私钥解密响应。

Answer 1

逐一回答这些问题:

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

是的。此外，这因 CA 而异 - 有些 CA，1 年的成员(member)资格和有效的信用卡就足够了(不难获得，即使您碰巧是一群盗贼)，有些 CA 需要一定数量的文书工作以验证您就是您所说的那个人。 CA 的好坏取决于它的客户验证过程，因此通常过程越繁重，CA 越好(且成本更高)。

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

公钥/私钥对。这通常是由您生成的，而不是由 CA 生成的。您生成和存储 key 对的方式的质量也是确定另一个实体可以信任您网站的程度的一个因素。通常，对于身份证书(如 SSL 服务器证书)，最好让客户(我的电子商店)生成 key 。

您将以标准格式(例如:PKCS10)向 CA 发送证书请求。它将包括一堆关于我的电子商店和公钥的信息。

CA 公司将检查您的文书工作并确保您是您本人。然后它将使用它的 CA 为您数字签名证书。该证书包含您刚刚提供的一堆信息、CA 提供商为您设置的一些额外信息、您的公钥以及通过将所有上述数据与 CA 的私钥加密绑定(bind)而生成的数字签名。

你会得到两件事之一:

只是证书(如果您生成自己的 key 对)

证书和 key 对 - 如果 CA 为您生成了 key 对

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

是的……有点。您的网络服务器将需要签名证书和 key 对。 key 对用作与最终用户的 SSL 握手的一部分，该交换证明您拥有 key 对，而不是某些拿到证书的窃贼。这就是您要保护 key 对的原因。

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

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

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

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

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

好的 - 事情在这里出轨了。

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

浏览器和网络服务器确实来回传递信息，让他们创建 session 加密 key 。浏览器确实会生成一些用于设置 session 的起始 Material ，但它不是“用户的公钥 (PK1)”。除非为客户端身份验证配置了服务器，否则用户不需要拥有 PKI 凭据。在正常运行的 My e-Shop 中，服务器有一个 PKI 凭证，浏览器正在为那个 session 动态生成一些关键 Material 。服务器完全不知道浏览器用户是谁，SSL-wise - 所有用户标识都来自密码或应用程序级别的其他东西。

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

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

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

这个 secret key 是对称的(确切地说哪个算法也是握手的一部分)并且用于 session 的剩余部分。