简单来说就是网站站长把证书上传到CloudFlare。

有关详细信息，请参阅本文。

Keyless 模式没有这个要求。它改为使用本地密钥服务器来提供服务器的私钥。有关其工作原理的详细信息，请参见此处的图表。

免费帐户

Cloudflare在他们的博客中声明：

对于所有客户，我们现在将在 CloudFlare 的网络上自动配置 SSL 证书，该证书将接受客户域和子域的 HTTPS 连接。这些证书包括根域（例如，example.com）的条目以及所有第一级子域（例如，www.example.com、blog.example.com 等）的通配符条目。

Cloudflare确实控制了域，因为客户已将其 DNS 记录指向它，这意味着他们可以获得域验证证书。域验证过程不必涉及向域发送电子邮件，这对于 Cloudflare 来说是不可能拦截的，因为 MX 记录没有被重新指向。相反，他们可以通过放置一个包含随机密钥的随机命名的文本文件来证明他们拥有该域，以供 CA 查询以证明对域的控制。CA 将指定该文件的名称和内容，然后他们将能够检查。然后，Cloudflare 可以拦截对 URL 的请求并显示必要的验证代码。

确切地！您将 DNS 指向 CloudFlare。但是，如果您没有商业（200 美元/月）或企业（5000 美元/月）计划，则不允许您使用自己的 SSL 证书。您可以使用他们提供的灵活 SSL 证书。所以如果你想使用你自己的 EV-SSL 证书，你需要做计划。我建议改用 Incapsula Enterprise。具有 DDoS 保护的更好的 Web 应用程序防火墙！

CloudFlare 现在拥有自己的 CA，因此他们可以制作任何他们想要的证书。他们的政策是仅为托管在其 DNS 服务器上的域创建证书，但没有也不可能存在此类技术限制。

更正： CloudFlare 正在运行Origin CA，但它们不是公共 CA。“源 CA”允许 CloudFlare 签署和撤销 CloudFlare 和真实源主机（通常不公开）之间连接的证书。这些证书没有到常用用户代理的信任存储的信任链。这意味着由“Origin CA”签名的证书不受 Firefox、Chrome 或 Safari 等的信任。没关系，因为这些证书的用例是保护 CloudFlare 前端服务器（技术上支持 TLS 的 HTTP 反向代理）和真实主机后端服务器之间的连接。

对于通过 CloudFlare 服务的所有站点，它们都支持通用 SSL，目前似乎由公共 COMODO CA 支持。检查通过 CloudFlare 运行的几个站点的证书表明他们正在从 COMODO 获得“域控制验证”证书，其中CN记录指向实际 CloudFlare 控制的反向代理（例如sni9922.cloudflaressl.com）并Subject Alternative Names列出通过 CloudFlare 提供服务的实际域。每个证书用于少数域。

我不确定他们为什么会有这样的安排。他们显然需要 SNI 来确定为任何新连接提供哪个证书，但他们应该能够为他们控制的任何域获取真实证书（也就是说，每个证书都可以有CN直接指向实际托管域的记录，而不是看起来像sni9922.cloudflaressl.com）。

他们显然能够为通过它们运行的​​任何主机获得“域控制验证”证书，因为它们控制 DNS 记录（您的 DNS 记录必须指向 CloudFlare 才能为您的主机使用 CloudFlare），并且任何新的 HTTP（或 HTTPS）连接都会转到他们的前端服务器。

TL;DR：CloudFlare 无法为不受其控制的域提供有效的 SSL/TLS 证书。但是，CloudFlare 的所有客户端都必须在 CloudFlare 上托管他们的 DNS 记录，因此，CloudFlare 对其所有客户端都有域控制。