HTTPS公钥到底存放在哪里

Question

HTTPS流程如下：
1、客户端向服务器发起一次请求。
2、服务器向客户端返回自己的证书
3、客户端检验证书的合法性

————————————————

修改：
证书中存放了一个公钥A，这个A将用来之后对对称加密密钥进行加密；再服务器存在一个私钥B，这个B对对称密钥解密。

服务器在发送证书的时候需要对内容进行加密签名，这个加密是用的私钥B吗，然后之后使用公钥A对其解密。

我还看到的一种说法是，使用的是存放在系统里面的公钥（CA公钥）进行解密，相应的，加密的时候使用的也是CA私钥？（这个系统里面的公钥是什么东西，反正我觉得肯定和公钥A，私钥B不一样。然后如果使用证书里面存放的密钥就可以为什么还需要麻烦使用CA公钥，私钥呢

Answer 1

你这个问题里有一个隐含知识，就是非对称加密。

与之相对的是对称加密，只有一把“钥匙”，加密解密都是它。

通俗的讲，非对称加密有两把“钥匙”，用钥匙 A 上锁、就只能用钥匙 B 打开，用别的钥匙甚至钥匙 A 自己都打不开；反过来，用钥匙 B 上锁、就只能用钥匙 A 打开。那这两把钥匙本身有什么区别呢？没啥区别。你把哪个给别人公用，哪个就是所谓的“公钥”；另一把你藏好，就是“私钥”。二者可以互换，公和私只是相对的。

（题外话：你可能会注意到 OpenSSL 之类的生成出来的公私钥长度不一样啊，私钥更长？那是因为 OpenSSL 为了方便已经帮你指定好了哪个是公、哪个是私，并且把私钥信息也一并写入了公钥的 PEM 里，其实你完全可以自行提取后把二者互换）。

---

下面先说 HTTPS 的加密流程：

公钥本身也是存储在服务器上的，当你访问一个带有 SSL 的网站，流程大致是：

1. 服务器把它的证书告诉你，证书内容里带着公钥（其实前面还有一步是你告诉服务器你会啥加密算法）；
2. 你检验证书是否有效（怎么检验后面再讲）；
3. 你生成一个随机的对称加密密钥（注意这个密钥是对称加密的啊），用第一步里的公钥对它加密；
4. 你把第三步的结果告诉服务器（一并的还有要传输的数据，即 HTTP 请求，当然也是被对称加密过的）；
5. 服务器收到以后用私钥解开得到第三步传过来的对称加密密钥，并用它解密传输过来的数据；
6. 服务器处理这些数据后，把要传给你的数据（即 HTTP 响应）还是用对称加密密钥加密后再传；
7. 你收到后用对称加密密钥解密。
8. 重复 4-7 步骤。

这里你会发现，SSL 的公私钥仅仅用来保证那个对称加密的密钥的私密和安全，真正对 HTTP 请求响应加密的不是非对称的、还是对称的。

而第一步也解答了你的第一个问题，公钥是存储在服务器上的，具体以什么格式存储还要看 WebServer 支持啥，常见的有 PEM / PFX。（可能你会发现你只配置过私钥文件啊，因为公钥被包含在了私钥里，原因上面说 OpenSSL 的时候提到了。）

---

再说第二个问题，怎么验证证书？

这里先说 SSL 证书解决了什么问题，可以看我以前的一个回答：《为什么需要申请SSL证书？》

还跟非对称加密有关。

首先服务器的公钥信息是被写入到了证书中了，上面的步骤一里提到过。

证书里还有一个叫“签发者公钥”的密钥，注意跟服务器公钥（也叫“使用者公钥”）相区别。

这个签发者就是签发这张证书的机构，他们自己有一对公私钥，签发的时候用他们的私钥对证书内容做签名，你拿到证书以后就可以用公钥验签。验签通过你就直到这张证书确实是这个机构签发的、没被伪造或篡改了。

这里还有一个信任链的问题。签发机构也分三六九等，最下级的签发机构的证书，是由它上一级的签发机构给它签发的（有点儿像各级经销商，都从上一级拿货）。

证书内容里也包含了完整的信任链：这张证书谁“作保”，“保人”的上一级“保人”是谁……

那么怎么直到最源头的那个“保人”是否可靠呢？这就是系统内置的根证书了。不展开讲了，自行学习 CA 相关知识吧。

---

总结一下你的两个问题答案：

• HTTPS 中服务器公钥存放在服务器上，浏览器请求时由服务器返回。
• 验证证书合法性时候使用的是签发者公钥、和服务器公钥是不同的。
• 验证签发者合法性的使用的是其上一级签发者公钥，直到根证书，内置在系统中。为了节省验签消耗，一些大的 CA 机构证书也一并内置在系统中了。