HTTPS公钥到底存放在哪里

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

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

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

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

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

阅读 14.2k
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 机构证书也一并内置在系统中了。
宣传栏