HTTPS如何工作的？

还有一个问题是互联网上的某个网站不能对每个访问者验证其公钥的有效性，因为现今互联网的规模大到这么做是不经济的。想象一下Facebook16.9亿用户，每个用户至少得发起一次请求，鉴于HTTP的无状态特性，每次请求都要验证一下这个公钥的有效性，这个规模是非常大的。为了解决这个问题，我们使用证书机构或者简称CA。

证书机构(CA)能正确工作的前提是我们首先得信任他。这听起来有很多顾虑，但是实践中却工作的很好。CA是依靠信任的，所以当CA做了一些可疑的事情，浏览器马上就不再信任这些CA，这些CA也就该倒闭了。即使是CA方面的简单错误也足以永久破坏其声誉。

那CA是如何解决我们的身份认证问题的呢？CA收钱为网站提供这种身份认证服务。DigiCert是一家有名的CA，同时也是Facebook使用的CA，我们就用她作为CA的例子。Facebook想证明她的公钥的有效身份，从而让用户安全的访问。所以她就花钱请DigiCert确认她就是真正的Facebook，一旦做了这个，DigiCert就会知道哪个公钥真的就是Facebook的。现在当你访问Facebook的时候，你就不需要Facebook证明她自己的身份了，你只需要Facebook证明DigiCert已经验证过她的身份就可以了。DigiCert为许多网站提供这种服务，你不需要弄清楚如何信任某个网站，你只需要信任DigiCert就可以了。如果你信任DigiCert，而DigiCert信任Facebook，那么理论上你就可以信任Facebook了。我们叫这个信任链。

从抽象的高度看，这就是HTTPS的工作原理了。但是，我们需要弄清楚该过程的中的两个具体细节，才能理解详细的工作原理。

这看起来又回到问题的起点了。如果我们拥有DigiCert的公钥，则可以验证其身份。但是我们需要以某种方式确保我们拥有DigiCert的公钥，而不是别人的。这里的解决办法是什么呢？其实是我们使用的操作系统或浏览器已经存储了DigiCert的公钥。现如今，我们信任很多CA，只不过她们是众所周知的，才能让现代操作系统或者浏览器存储她们的公钥。这部分公钥存储在计算机的“受信任的根证书颁发机构存储区(Trusted Root Certificate Authority Store)”中。存储的密钥数量似乎很多，但这总比为互联网上的每个网站存储一个公钥要容易多了。

一旦DigiCert验证过Facebook就是Facebook之后，DigiCert就知道了Facebook的真正公钥，然后使用自己的私钥对Facebook的公钥进行数字签名，并且将这个签名后的公钥给Facebook。这种交互完全发生在Facebook和DigiCert之间，而且远远早于用户连接到Facebook的时间，一般网站上线之前就发生了。现在，当你连接到Facebook时，Facebook会给你发送一个已由DigiCert的私钥签名的公钥。然后你可以使用操作系统存储的公钥来验证DigiCert对Facebook的公钥进行了签名。

整个过程中有两对公钥和私钥，一对是网站的，一对是CA的。双方都对外公布自己的公钥，并安全保存自己的私钥。网站的公钥先是给了CA，被签名之后间接的最终还是给了用户，这个公钥在协商阶段还会用到。而CA的公钥则直接被操作系统或者浏览器存储下来了，也相当于给了用户。CA用自己的私钥对网站的公钥进行数字签名，发给网站，这就是服务器的证书。当用户连接到服务器的握手环节，服务器发送证书给用户，用户通过本地的CA的公钥来解密网站发来的证书(CA私钥签名过的网站公钥)，如果成功则完成了验证问题。