为CloudFlare客户提供对源站的免费和高性能加密2014年秋季，CloudFlare推出了Universal SSL，并将通过HTTPS访问的网站数量增加了一倍。在短短几天内，我们颁发了保护数百万客户域的证书，并成为使用SSL/TLS保护您的网站的最简单方法。当时，我们"强烈建议网站所有者在他们的web服务器上安装一个证书，这样我们就可以对到源站的流量进行加密。"这一建议之后，我们在一篇博客文章中描述了两个现成的选择，即创建自签名证书和购买公共信任证书，以及第三个，仍处于测试阶段：使用我们的私人CA。尽管自那次发布以来，获取公共CA证书的自付费用已降至0美元，但我们仍不断收到客户要求提供更简单（更具性能）的选项的请求。操作公共证书颁发机构很困难，因为您不能直接控制HTTPS连接的任何一个端点（浏览器或web服务器）。因此，公共CA在颁发针对服务器间通信而优化的证书的能力以及在证书受到破坏时吊销证书的能力都受到限制。我们在CloudFlare的情况明显不同：我们肯定地控制着我们网络的边缘，因此我们能够灵活地构建和操作一个安全的CA，该CA能够发布高度简化的证书并确保它们被安全地利用。少即是多：去掉多余的东西使用originca，我们对证书颁发和浏览器验证的各个方面提出了质疑，从域控制验证（DCV）到路径绑定和吊销检查。我们扪心自问，如果只需要使用一个浏览器（它们维护的是哪个浏览器的代码库），它们会从证书中删除什么？诸如"当客户只需要与我们基于NGINX的反向代理通信时，为什么要用中间ca膨胀证书"和"当客户已经在区域登录期间演示了控制时，为什么要强制客户重新配置其web或名称服务器以通过DCV检查？"有助于我们的努力。我们提出这些问题并删除任何不需要的东西来确保我们的服务器和您的服务器之间的连接安全，结果如下所述，以及您可能看到的好处和您可能使用的接口。我们很高兴介绍这第三个选项，它比自签名证书更安全，比公开信任的证书更方便、更高效、更经济，并期待着听到您使用它的各种方法。源CA相对于公共证书的增量优势是什么？1发行和续期的便利性使用TLS保护您的来源地最困难和最耗时的部分是获取和更新-a证书。如果使用的提供程序不支持通配符，则为多个证书。通常，此过程需要熟悉OpenSSL或相关命令行工具，重新配置web或DNS服务器以适应域控制验证，并定期安排提醒或cron作业，以便每年（甚至每隔几个月）再次执行此过程。对于Origin CA，我们利用这个机会尽可能多地消除这些障碍。使用GUI的客户只需两次单击，就可以安全地生成一个私钥和通配符证书，我们的系统可以信任它7天到15年。而那些更愿意控制进程的人可以使用我们的API或CLI来颁发指定有效性、密钥类型和密钥大小的证书。不管选择了什么样的用户界面，潜在的复杂验证过程已经被一个简单的API密钥所取代，现在您可以在CloudFlare仪表板上的帐户中使用它；我们已经验证了您是否控制了您的区域，无需再次证明。2通配符证书降低了复杂性如果源服务器处理多个主机名的通信，那么在每个证书请求上放置一长串SAN列表可能会很麻烦。另一种方法是在每个证书上只放置一个SAN，然后使用服务器名称指示（SNI）扩展延迟加载正确的证书，这很容易失控。在这个部署方案中，所需的证书数量是您希望保护的主机名数量的一个重要部分（更不用说，您甚至可能不允许在共享主机上这样做）。除了资源调配工作外，在一个证书上放置过多的SAN会显著增加证书的大小。较大的证书在源站消耗更多带宽（与CloudFlare不同，它可能会向您收取边际带宽消耗的账单）。要保护源站上的多个主机名（甚至域），最明显的方法是使用通配符证书。使用原始CA，您可以为帐户中注册的任何和所有区域请求一个包含通配符的证书；您甚至可以添加覆盖域的多个级别的通配符，例如*。示例.com, *.secure.example.com网站，和*另一个-example.com网站可以在同一个证书上共存。三。撤销的速度和简单性如果您曾经尝试过撤销一个公共信任的证书或者依赖浏览器来不信任一个被撤销的证书，那么您就知道这个过程有多不可靠。从谷歌加密神童亚当·兰利（Adam Langley Revocation Does Not work）（2011年）中挑选解释；不，不启用撤销检查（2014年）；或撤销仍然不起作用（2014年）——它们都得出相同的结论：基于浏览器的撤销检查被破坏，而且没有硬失败。（OCSP Must-spike扩展的出现应该会改善这种情况，但是如果历史可以证明，还需要相当长的时间才能有足够的浏览器、证书颁发机构和已颁发的证书支持它。）幸运的是，对于originca，我们只需要一个"浏览器"来考虑撤销：我们的边缘。当用户代理在内存中有一个包含所有有效证书的列表时，从安全角度来看，唯一可以接受的失败方式非常简单（而且速度很快）。（试着用过去几年几十家CA颁发的数百万个证书来做这件事！）我们的NGINX实例不需要在公共互联网上发出请求并祈祷它们足够快地返回，我们的NGINX实例只需为每个新的HTTPS会话查询一个本地数据库，并在微秒内确认您是否出于任何原因吊销了证书。如果/当需要撤销时，只需单击一次并进行确认，我们的边缘就可以不信任该证书。如果您暴露或放错了您的私钥（在沙发下面或昨天裤子的口袋里找不到），只需导航到"加密"选项卡并单击受损证书旁边的"x"图标。几秒钟之内，我们将在全球范围内推送此吊销状态，我们的边缘服务器将拒绝与服务于被吊销证书的源服务器通信。没有对CA和浏览器生态系统的完全控制，这样的速度、安全性和可靠性是不可能实现的。即使发布到世界各地，要滥用您的CloudFlare源CA证书，攻击者也需要危害您的CloudFlare帐户或控制您的注册商或DNS提供商帐户。无论如何，你要担心的不仅仅是一个受损的证书。4广泛支持的客户群虽然大多数web服务器运营商会选择为他们的证书下载默认的PEM格式（正如apachehttpd和NGINX所期望的那样），但其他许多网络服务器运营商将需要不同的变体。如下面的屏幕截图所示，证书可以几种不同的格式下载，包括DER（相当于PEM的ASCII的二进制文件）和PKCS#7（Microsoft IIS服务器和Apache Tomcat兼容选项）。只需选择适合您的服务器的方法并下载它；无需学习用于转换的神秘命令行方法。除了其他格式，我们还提供了各种操作系统和web服务器的说明。生成证书后，只需从80多个不同的选项中选择所需的目标，并将显示特定于您的环境的说明。5优化的证书提高了性能并减少了源站带宽消耗在用户代理可以安全地将诸如GET和POST之类的HTTP操作传输到web服务器之前，它必须首先建立TLS会话。为此，客户机通过发送自己的功能开始握手，服务器使用协商的密码套件和证书进行响应，这些密码套件和证书应用于保护协商对称密钥的会话。在客户端接收并验证源站通过网络发送的证书之前，它无法完成握手并开始请求数据。因此，性能敏感用户的最佳利益是使此证书尽可能小且无障碍。（理想情况下，包含证书的数据包甚至可以放在一个帧内，并且在传输过程中不会出现碎片。）CA/B论坛的一位成员进行的一项简短调查发现，虽然大多数证书都在1-2 kB之间，但在野外发现的证书大小至少为10 kB，其中一个甚至超过50 kB（！）kB。有了原始CA证书，我们去除了与服务器和您的服务器之间通信无关的所有内容，以产生尽可能小的证书和握手。例如，我们不需要捆绑中间证书来帮助浏览器建立到可信根的路径；不需要为了证书透明性和EV处理而包括签名证书时间戳（sct）；不需要包括到认证实践声明或其他url的链接；而且不需要监听来自第三方的在线证书状态协议（OCSP）响应。消除这些通常在来自公共CA的证书中发现的不必要的组件使我们能够将握手的大小减少到