逐个提问：
(1) “My e-Shop”作为公司需要在某个第三方 CA 进行“认证”。这意味着我需要在那个 CA 购买某种 1 年的会员资格，然后，他们将在他们的系统上注册“我的 e-Shop”并给我一些东西，比如证书和一对唯一的公钥和私钥。我会得到一些证书文件吗？
是的。此外，这因 CA 而异 - 一些 CA、1 年会员资格和一张有效的信用卡就足够了（不难获得，即使你碰巧是一群小偷），一些 CA 需要一定数量的文书工作验证你就是你所说的那个人。CA 的好坏取决于它的客户验证流程，因此通常流程越繁琐，CA 就越好（也越贵）。
当你支付了你的钱并完成了你的文书工作，那么你和 CA 将产生至少 2 件事：
- 公钥/私钥对。通常这是由您生成的，而不是由 CA 生成的。您生成和存储密钥对的质量也是决定其他实体对您网站的信任程度的一个因素。通常，对于标识证书（如 SSL 服务器证书），最好让客户（我的 e-Shop）生成密钥。
- 您将以标准格式（例如：PKCS10）向 CA 发送证书请求。它将包括一堆关于 My e-Shop 和公钥的信息。
- CA 公司将检查您的文书工作并确保您是您本人。然后它将使用它的 CA 为您数字签名证书。该证书包含您刚刚提供的一堆信息、CA 提供商为您设置的一些额外信息、您的公钥以及通过将所有上述数据与 CA 的私钥加密绑定而生成的数字签名。
你会得到以下两件事之一：
- 只是证书（如果您生成了自己的密钥对）
- 证书和密钥对 - 如果 CA 为您生成了密钥对
(2) 颁发的证书包含我的信息和公钥，并存储在我的网络服务器上的某个文件中。该证书验证“我的网店”不是盗贼局。
是的……有点。您的网络服务器将需要签名证书和密钥对。密钥对用作与最终用户进行 SSL 握手的一部分，并且该交换证明您拥有密钥对，而不是某些获得证书的小偷。这就是您要保护密钥对的原因。
(3) 每次用户通过“https”访问“我的网店”时，他们的浏览器都会“默默地”将出示的“我的网店”证书与在CA注册的证书进行核对。
对于“沉默”的一些定义。基线浏览器检查证书： - 当前有效 - 由浏览器信任的 CA 签名（或者它拒绝访问或给你一个烦人的弹出窗口）
浏览器插件将更进一步，并执行完整路径检查（一直到自签名根）和证书状态检查等事情。通过管道共享信息的风险越高，需要进行的检查就越多。
(4) 当一些用户通过https进入“我的网店”时，会发生以下情况：“我的网店”（网络服务器）获取用户的公钥（PK1）。服务器默默地把“我的网店”的证书呈现给用户，这样用户就得到了“我的网店”的公钥（PK2）。经过一些静默检查后，用户的浏览器会验证提供的证书并建立安全管道。
- 用户呢？他们的浏览器通过https进入“我的网店”时是否会生成本地公钥+私钥？
好的 - 这里的东西正在脱轨。
有关详细信息，请查看 SSL 协议 - 握手部分将为您提供确凿的事实。
浏览器和网络服务器确实会来回传递信息，让它们创建会话加密密钥。浏览器确实会生成一些用于设置会话的起始材料，但它不是“用户的公钥 (PK1)”。除非服务器已配置为进行客户端身份验证，否则用户不需要拥有 PKI 凭据。在我的 e-Shop 的常规运行中，服务器具有 PKI 凭据，浏览器正在为该会话生成一些动态的关键材料。服务器完全不知道浏览器用户是谁，SSL 方面 - 所有用户标识都来自密码或应用程序级别的其他内容。
注意：这是针对常规商业交易。风险越高，保护越大。高风险交易经常需要客户身份验证。
(5) 当用户通过安全管道发送请求时，请求被“My e-shop”的公钥加密。然后，Web 服务器使用其私钥解密请求。然后，Web 服务器使用用户的公钥发送加密响应。最后，用户的浏览器用他的私钥解密响应。
不完全的。这是杂草——Web 应用程序的开发人员相对地从所有这些中抽象出来。但是 - 会话内容没有使用非对称密钥加密 - 这将非常耗费 CPU。服务器的 PKI 和动态浏览器生成的握手数据用于交换会话加密密钥。其中一部分是客户端选择并发送在服务器的公钥中加密的密钥。由于只有服务器拥有私钥，所以只有服务器才能解密客户端发送的数据。
此密钥是对称的（确切地说，哪个算法也是握手的一部分）并用于会话的其余部分。