Introducing CloudFlare Origin CA

In the fall of 2014 CloudFlare launched Universal SSL and doubled the number of sites on the Internet accessible via HTTPS. In just a few days we issued certificates protecting millions of our customers’ domains and became the easiest way to secure your website with SSL/TLS.

At the time, we "strongly recommend[ed] that site owners install a certificate on their web servers so we can encrypt traffic to the origin." This recommendation was followed by a blog post describing two readily-available options for doing so—creating a self-signed certificate and purchasing a publicly trusted certificate—and a third, still-in-beta option: using our private CA. Even though out-of-pocket costs of acquiring public CA certificates have since fallen to $0 since that post, we have continued to receive requests from our customers for an even easier (and more performant) option.

Operating a public certificate authority is difficult because you don't directly control either endpoint of the HTTPS connection (browser or web server). As a result, public CAs are limited both in their ability to issue certificates optimized for inter-server communication, as well as in their ability to revoke certificates if they are compromised. Our situation at CloudFlare is markedly different: we affirmatively control the edge of our network so we have the flexibility to build and operate a secure CA that’s capable of issuing highly streamlined certificates and ensuring they are utilized securely.

With Origin CA, we questioned all aspects of certificate issuance and browser validation, from domain control validation (DCV) to path bundling and revocation checking. We asked ourselves what cruft public CAs would remove from certificates if they only needed to work with one browser, whose codebase they maintained? Questions such as "why bloat certificates with intermediate CAs when they only need to speak with our NGINX-based reverse proxy" and "why force customers to reconfigure their web or name server to pass DCV checks when they’ve already demonstrated control during zone onboarding?" helped shape our efforts.

The result of us asking these questions and removing anything not needed to secure the connection between our servers and yours is described below, along with the benefits you may see and the interfaces you may use. We’re excited to introduce this third option for protecting your origin—more secure than self-signed certificates and more convenient, performant, and cost effective than publicly trusted certificates—and look forward to hearing about all the various ways you may use it.

1. Ease of issuance and renewal

The most difficult and time-consuming part of securing your origin with TLS is obtaining—and renewing—a certificate. Or many certificates if you’re using a provider that doesn’t support wildcards. Often this process requires intimate knowledge of OpenSSL or related command line tools, a reconfiguration of your web or DNS server to accommodate domain control validation, and a regularly scheduled reminder or cron job to perform this process again every year (or even every few months). With Origin CA, we took the opportunity to remove as many of these obstacles as possible.

Customers more comfortable in the GUI can, with just two clicks, securely generate a private key and wildcard certificate that will be trusted by our systems for anywhere from 7 days to 15 years. And those who prefer more control over the process can use our API or CLI to issue certificates of specified validity, key type, and key size. Regardless of the user interface chosen, the potentially complicated validation process has been replaced by a simple API key now available in your account on the CloudFlare dashboard; we’ve already verified you control your zone, there’s no need to prove it again.

2. Wildcard certificates reduce complexity

If your origin server handles traffic for more than a few hostnames, it can get unwieldy to place a long list of SANs on each certificate request. The alternative—placing just one SAN on each certificate and using Server Name Indication (SNI) extension to lazy load the correct certificate—can easily get out of hand. In this deployment scenario the number of certificates required is a non-trivial fraction of the the number of hostnames you wish to protect (not to mention you may not even be allowed to do so on shared hosts).

Beyond provisioning efforts, placing too many SANs on a single certificate can significantly increase the size of the certificate. Larger certificates consume more bandwidth at your origin (which, unlike CloudFlare, may bill you for marginal bandwidth consumption). The obvious answer for protecting more than a few hostnames (or even domains) on your origin is to use wildcard certificates. With Origin CA, you can request a single certificate containing wildcards for any and all of the zones registered in your account; you can even add wildcards covering multiple levels of a domain, e.g., *.example.com, *.secure.example.com, and *.another-example.com can all co-exist on the same certificate.

3. Speed and simplicity of revocation

If you’ve ever tried revoking a publicly trusted certificate—or relying on browsers to distrust a revoked certificate—you know how unreliable the process can be. Take your pick of explanations from Google crypto-wunderkind Adam Langley—Revocation doesn’t work (2011); No, don’t enable revocation checking (2014); or Revocation still doesn’t work (2014)—they all reach the same conclusion: browser-based revocation checking is broken and useless without hard fails. (The advent of the OCSP Must-Staple extension should improve the situation, but if history is any indication it will be quite a while before sufficient browsers, certificate authorities, and issued certificates support it.)

Fortunately with Origin CA, we only need one "browser" to respect revocation: our edge. Failing hard—the only acceptable way to fail from a security perspective—is incredibly simple (and fast) when your user agent has an in-memory list of all valid certificates. (Try doing that with the millions of certificates issued by dozens of CAs over the past few years!) Rather than fire requests across the public Internet and praying they return quickly enough, our NGINX instances can just query a local database for each new HTTPS session and confirm in microseconds whether you’ve revoked the certificate for any reason.

And if/when the time comes to revoke, a single click and confirmation is all that’s required for our edge to distrust the certificate. If you expose or misplace your private key (and can’t find it under the couch or in the pockets of yesterday’s pants), simply navigate to the Crypto tab and click the "x" icon next to the compromised certificate. Within seconds we’ll push this revocation status worldwide and our edge servers will refuse to communicate with origins serving the revoked certificate. Such speed, security, and reliability is impossible without total control over the CA and browser ecosystem.

Even if published to the world, to abuse your CloudFlare Origin CA certificate an attacker would either need to compromise your CloudFlare account or take control of your registrar or DNS provider account. In any case, you'd have a lot more to worry about than just a compromised certificate.

4. Widely supported install base

While most web server operators will elect to download the default PEM format for their certificate (as expected by Apache httpd and NGINX), many others will require a different variation. As illustrated in the screenshots below, certificates can be downloaded in several different formats, including DER, the binary equivalent of PEM’s ASCII, and PKCS#7, the Microsoft IIS Server and Apache Tomcat-compatible choice. Simply pick what works for your server and download it; there’s no need to learn cryptic command-line methods for converting.

Besides additional formats, we also have instructions for a wide variety of operating systems and web servers. After generating your certificate simply select your desired destination from the 80+ different options and instructions specific to your environment will be displayed.

5. Optimized certificates increase performance and reduce origin bandwidth consumption

Before a user agent can securely transmit HTTP actions like GET and POST to a web server, it must first establish the TLS session. To do so, the client kicks off a handshake by sending its own capabilities and the server responds with the negotiated cipher suite and certificate that should be used to protect the conversation agreeing upon a symmetric key.

Until the client receives—and validates—the certificate(s) sent across the network by the origin, it is unable to complete the handshake and commence with requesting data. As such, it’s in the best interest of performance-sensitive users to make this certificate as small and unencumbered as possible. (Ideally the packet containing the certificate even fits within a single frame and is not fragmented during transmission.) One brief survey by a member of the CA/B Forum found that while the majority of certificates were between 1-2 kB, several thousand were found in the wild at least 10 kB in size, with one even over 50(!) kB.

With Origin CA certificates, we’ve stripped everything that’s extraneous to communication between our servers and yours to produce the smallest possible certificate and handshake. For example, we have no need to bundle intermediate certificates to assist browsers in building paths to trusted roots; no need to include signed certificate timestamps (SCTs) for purposes of certificate transparency and EV treatment; no need to include links to Certification Practice Statements or other URLs; and no need to listen to Online Certificate Status Protocol (OCSP) responses from third-parties.

Eliminating these unnecessary components typically found in certificates from public CAs has allowed us to reduce the size of the handshake by up to 70%, from over 4500 bytes in some cases to under 1300. You can replicate this test yourself using the following two OpenSSL s_client calls:

$ for host in google.com bing.com cloudflare.com patriots.com; do echo -en "$host\t" && openssl s_client -connect www.$host:443 -servername www.$host 2>/dev/null </dev/null | grep "has read"; done
google.com      SSL handshake has read 3747 bytes and written 497 bytes
bing.com        SSL handshake has read 4252 bytes and written 583 bytes
cloudflare.com  SSL handshake has read 3845 bytes and written 501 bytes
patriots.com    SSL handshake has read 4507 bytes and written 499 bytes

$ openssl s_client -connect [ORIGIN_IP]:443 -servername [ORIGIN_HOSTNAME] 2>/dev/null </dev/null | grep "has read"
SSL handshake has read 1289 bytes and written 496 bytes

Now that you've learned why you may want to use Origin CA-issued certificates on your origin, let’s explore the various interfaces you have for issuing (and revoking) them. Effective immediately, certificates for your origin can be issued in an automated fashion through our API or CLI, or through a guided wizard in the Crypto app on the CloudFlare Dashboard. Each of the three available methods is described below along with examples:

1. GUI: Crypto app in the CloudFlare Dashboard

To get started, login to the dashboard and click on the Crypto icon.

Next, scroll down to the Origin Certificates card and click the "Create Certificate" button.

At this point, you must decide whether you wish to provide your own certificate signing request (CSR) or let your browser create one using its cryptographic libraries.

If you’ve already generated a private key and CSR, select the radio button labeled "I have my own CSR" and paste the CSR contents into the textbox that appears. Alternatively, leave the default option of “Let CloudFlare generate a key pair using my browser” selected. (If you are accessing the dashboard using an older browser, i.e., one that does not support Web Crypto API, you will only see one option.)

By default, the list of hostnames your origin certificate covers includes the apex of the currently selected zone (example.com) and one level of wildcard (*.example.com). If you’d like to protect additional hostnames outside this list (e.g., *.secure.example.com), simply type them in the input box at the bottom of the modal. You may add up to 100 hostnames (or wildcards) on a single certificate, spanning multiple zones, provided they are for zones active in your account. Please keep in mind that each additional SAN increases the size of your certificate, so applications requiring frequent updates to the origin (and thus TLS handshakes) you should use as few SANs as possible.

After entering additional hostnames (or confirming the defaults will suffice), click Next and your certificate will be generated. By default, it will be displayed in PEM format, which is what web servers such as Apache httpd and NGINX expect. If you require an alternative format, such as PKCS#7 for Microsoft’s IIS or Apache Tomcat, change the dropdown box appropriately and save the contents to your server. Or if you’d like to use a binary format such as DER, select that and click the download button.

Lastly, choose your web server from the select box at the bottom of the window and click "Show instructions". Doing so will open installation instructions in a new browser window that, once followed, will allow you to adjust your SSL setting (at the top of the Crypto app) to "Strict" mode.

2. API: Application Programming Interface

If you would like to automate the process of issuing certificates for your origin, or require more control over the parameters (e.g., shorter-lived certificates, greater key size, etc.), you can make use of our certificates API endpoint.

Before calling the API you will first need to generate a certificate signing request. To do so, you can use cfssl or OpenSSL. Instructions for the former can be found here, while our friends at DigiCert have provided an easy-to-use wizard for the latter. Don't worry about including subject alternative names (SANs) in the CSR — we’ll take those in separately through the JSON payload.

i. Generate a private key and CSR

$ openssl req -new -newkey rsa:2048 -nodes -out www_example_com.csr -keyout www_example_com.key -subj "/C=US/ST=California/L=/O=/CN=www.example.com"
Generating a 2048 bit RSA private key
.............................+++
.....................................................................................................................................+++
writing new private key to 'www_example_com.key'

ii. Obtain your Certificate API token

Log in to the CloudFlare dashboard, and click My Settings under your username in the top-right  hand corner. Scroll down to the API Key panel and click "View API Key".

Click within the window that pops up and then copy the contents that is auto-selected to your clipboard. Save the key to an environment variable as it will be used in the subsequent curl command.

$   export CF_API_KEY="v1.0-c9..."

iii. Make the API call

Note that you will need to remove newlines from the CSR as newlines are not permitted in JSON and add them back into the certificate that’s returned. When you remove them you should replace the newline character (hex code 0A) with the string "\n".

$ curl -sX POST https://api.cloudflare.com/client/v4/certificates/ \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "X-AUTH-USER-SERVICE-KEY: $CF_API_KEY" \
--data '{"hostnames":["example.com","*.example.com"],"requested_validity":"365","request_type":"origin-rsa","csr":"-----BEGIN CERTIFICATE REQUEST-----...-----END CERTIFICATE REQUEST-----"}'

iv. Extract certificate from API response

{
  "success": true, "errors": [], "messages": [],
  "result": {
    "id": "0x47530d8f561faa08",
    "certificate": "-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----",
    "hostnames": [ "example.com", "*.example.com" ],
    "expires_on": "2014-01-01T05:20:00.12345Z",
    "request_type": "origin-rsa",
    "requested_validity": "365",
    "csr": "-----BEGIN CERTIFICATE REQUEST-----...-----END CERTIFICATE REQUEST-----"
  }
}

3. CLI: Command Line Interface (Linux only)

Lastly, if you’re using a Linux platform that supports RPM or DEB packages, the easiest way to request certificates is with the Origin CA CLI. Before proceeding, make sure you follow the instructions above in the API example to save your API key in the CF_API_KEY environment variable.

To get started, browse to https://pkg.cloudflare.com/ and follow the instructions to add the CloudFlare Package Repository to your system. With the new package server in place, use apt or yum to install the "cfca" package (binary placed in /usr/local/bin on DEbian, e.g.,) and then issue a certificate in a manner similar to the following examples:

i. Default parameters (RSA key, 15 year validity)

$ /usr/local/bin/cfca getcert -hostnames example.com,*.example.com
2016/04/25 19:47:23 [INFO] generate received request
2016/04/25 19:47:23 [INFO] received CSR
2016/04/25 19:47:23 [INFO] generating key: rsa-2048
2016/04/25 19:47:24 [INFO] encoded CSR
2016/04/25 19:47:24 [INFO] Connecting to https://api.cloudflare.com/client/v4/certificates/
2016/04/25 19:47:25 [INFO] Successfully issued certificate for:
*.example.com
example.com
2016/04/25 19:47:25 [INFO] Saved generated private key to wildcard.example.com.key
2016/04/25 19:47:25 [INFO] Saved issued certificate to wildcard.example.com.pem

ii. Short-lived multi-zone ECC example (ECDSA key, 7 day validity)

$ /usr/local/bin/cfca getcert -days 7 -hostnames *.foo.com,*.bar.com -key-type ecdsa -key-size 256
2016/04/26 12:24:24 [INFO] generate received request
2016/04/26 12:24:24 [INFO] received CSR
2016/04/26 12:24:24 [INFO] generating key: ecdsa-256
2016/04/26 12:24:24 [INFO] encoded CSR
2016/04/26 12:24:24 [INFO] Connecting to https://api.cloudflare.com/client/v4/certificates/
2016/04/26 12:24:28 [INFO] Successfully issued certificate for:
*.foo.com
*.bar.com
2016/04/26 12:24:28 [INFO] Saved generated private key to wildcard.foo.com.key
2016/04/26 12:24:28 [INFO] Saved issued certificate to wildcard.foo.com.pem

$ cat wildcard.foo.com.pem | openssl x509 -noout -text | grep "Not After\|Public Key Algorithm\|DNS"
Not After : May  3 19:19:00 2016 GMT
Public Key Algorithm: id-ecPublicKey
DNS:*.foo.com, DNS:*.bar.com

As you use Origin CA to generate certificates and secure your origin servers, keep these recommendations in mind:

1. Use Origin CA to generate certificates for your origin servers, using wildcards for each zone to keep SANs to a minimum.

2. Upgrade each zone’s SSL setting from "Flexible" or "Full" to "Strict" mode you have Origin CA or public CA certificates installed protecting all hostnames in that zone.

3. If you were previously enrolled in our beta Origin CA program, you should issue new certificates so they include revocation endpoints.

4. When pausing CloudFlare or gray-clouding individual zones, be aware that you and your visitors may receive errors in their browsers until you orange-cloud (reverse proxy) them again.

If you encounter any difficulty issuing certificates, or have any other concerns or suggestions, please open a support ticket and we will be happy to assist you.