一个多月前，我们发表了几篇关于如何提高SSL速度的博客文章。具体来说，我们在我们的网络上启用了OCSP装订。简言之，当您通过HTTPS访问页面时，您的浏览器通过一个称为OCSP的协议来检查SSL证书是否仍然有效。这些检查可能很慢，所以我们采取了多个步骤来加快速度。最终的效果是，对于支持OCSP装订的浏览器，CloudFlare上HTTPS站点的访问者在SSL握手时的性能将提高30%。这是个好消息。接下来发生的是许多人检查了我们的SSL设置以验证我们的声明。虽然我们在OCSP检查方面提高了性能，但这些调查发现了许多我们没有以最佳方式部署SSL的方式。特别是，williamchan写了一篇关于SSL部署的博客文章，并提出了一些改进SSL部署的建议。我们把这些批评放在心上，今天发布了一个改进的SSL进程。我们的目标是提供最快、最强大的SSL和最普遍的浏览器支持。由于许多其他云服务提供商可能会面临同样的挑战，而且由于我们还没有发现其他任何人能够智能地自动优化证书捆绑包，所以我们想记录下我们所做的。SSL：信任链简单来说，SSL很简单。当您的浏览器通过HTTPS连接到网站时，站点的web服务器会将SSL证书返回给浏览器。此证书用于验证网站的身份，并加密浏览器和web服务器之间交换的数据。

为了执行这些功能，浏览器必须信任证书。网站的SSL证书由证书颁发机构（CA）颁发。CA保证网站的证书是有效的。然后CA拥有浏览器信任的根证书。由于浏览器信任CA的根目录，并且CA信任web服务器的SSL证书，因此通过可传递属性，浏览器信任SSL证书，并且可以建立安全的HTTPS连接。挑战在于SSL的世界并不总是那么干净。首先，大多数CA不使用其根证书来直接对其颁发给客户端的SSL证书进行签名。相反，他们使用"中间"证书。中间证书链可以是任意长度的，串在一起将信任从根传递到web服务器使用的最终证书。更复杂的是，一个中间证书可以有多个证明其身份的父证书。例如，GoDaddy有一个例子，他们自己的根证书和Valicert的根证书都是GoDaddy中间证书的担保。长链=性能缓慢虽然信任可以传递任何长度的SSL链，但是链越长，对设置HTTPS连接的性能影响就越大。虽然这些开销的一部分来自验证链中的所有证书，但大部分开销也与只需传输组成中间证书的所有数据有关。正如William Chan所指出的，CloudFlare包含的数据超出了我们的需要，因此每个数据包的数据量达到了最大值。这会对web性能产生特别大的影响，因为SSL数据是要交换的第一件事，在SSL握手发生之前，不能再交换更多的数据，所以在SSL握手过程中取消往返可以加快其他所有事情的速度。CloudFlare的智能SSL捆绑程序对于我们自己颁发的SSL证书（例如我们为专业客户创建的证书），这不是问题。然而，对于定制的SSL证书，比如那些可用于商业和企业订户的SSL证书，我们对SSL捆绑包中包含的内容并不明智。在减少这些证书的大小方面，最不容易实现的是从证书包中删除根证书。没有理由包含这些内容，因为它们应该已经存在于浏览器中，即使它们不存在，浏览器也不会信任它们。我们想在如何构建bundle方面更加聪明，因此我们花了一些时间开发一个系统，该系统可以在用户上传到我们系统的证书和浏览器中存在的根证书之间找到最短路径。为此，我们需要构建一个web最常见的中间证书目录。你可能会认为这是有人收集并出版的东西。我们找了好长时间才找到这些东西，但在任何地方都找不到，所以我们自己创造了一个。（请注意，其他人不必经历同样痛苦的练习，我们将在未来几天内在GitHub上发布该目录，并在找到更多中间证书时保持更新。）建立链条，挑选最好的今天，当有人上传自定义SSL证书时，我们使用中间证书目录来构建从上传的证书到可信浏览器根目录的所有可能的链。然后，我们根据一系列因素对这些链进行排序，包括：证书链的长度根证书在浏览器和其他客户端中的普遍存在链中每一步的安全性密钥使用包括服务器身份验证）链中所有步骤的有效期长度其结果是一个小型、快速和强大的服务器捆绑包，同时拥有无处不在的浏览器和客户端支持。这些都是关注性能和安全性的组织应该手工进行的优化。我们感到兴奋的是，我们已经自动化了这个过程，并使任何想要为其给定证书使用尽可能快的SSL的人变得容易。如果您已经通过CloudFlare使用SSL，那么您的SSL捆绑包已经自动优化。如果你的网站看起来有点快，那就是原因。接下来，除了在Github上发布中间SSL证书的目录外，我们还计划将SSL绑定器作为免费服务发布，这样您就可以尽可能高效地打包SSL证书，即使您不使用CloudFlare。这只是我们努力使网络快速和安全的另一种方法。