In late 2014, popular browsers announced their intention to no longer consider SSL/TLS certificates using the SHA-1 algorithm secure for HTTPS purposes. This change was made due to collision attacks becoming more feasible than previously thought. However, some parts of the world still have a non-trivial percent of users that possess devices unable to use (or upgrade to use) the new standard, SHA-2. As a result, this deprecation leaves those with older devices (particularly in developing nations) unable to access the web using HTTPS.
As of late 2015, Cloudflare customers on Pro, Business, and Enterprise plans automatically have three certificates generated for their zones during sign-up, with the optimal one being served at the edge based on the user agent's capabilities.
If you are are a Business or Enterprise customer using your own custom-uploaded certificates, you should continue reading to learn how you can take advantage of this same capability.
What are custom certificate packs?
A custom certificate pack is a group of custom certificates with varying signature algorithms (SHA-2 ECDSA, SHA-2 RSA, and SHA-1 RSA). So long as the certificates share the same hostnames and wildcards (i.e., the same "host group"), they will automatically be grouped together in the UI and served to visitors based on their browser's crypto capabilities.
The types "primary" and "secondary" indicate the order in which the certificates were uploaded to Cloudflare, where the primary certificate in a pack is the first certificate added to the pack. The primary certificate defines the host group for a pack and cannot be deleted if secondaries are present in the pack.
What are host groups?
A host group is a common set of hostnames or wildcards. For example, a host group could include:
*.example.com. These values typically appear in the Subject Alternative Name (SAN) field of the certificate, but one may also be in the Common Name (CN). Regardless of where they can be found in X509, the hostnames are grouped together and used to determine if a newly uploaded certificate should be used as a "fallback" option to an existing certificate, or create a new pack.
Why are we offering custom certificate packs?
Uploading duplicate certificates with different signature algorithms allows Cloudflare to fallback to a certificate with a more widely-accepted signature algorithm for visitors who do not support the latest standards.
For customers at a paid level of service using Cloudflare-issued certificates, we already issue a pack of three certificates for each zone containing certificates with SHA-2 ECDSA, SHA-2 RSA, and SHA-1 RSA signature algorithms.
What certificates can I put in a pack?
You are able to create a pack containing up to three certificates, containing one of each of the three different signature algorithms; SHA-2 ECDSA, SHA-2 RSA, and SHA-1 RSA. Only certificates which contain the exact same set of hostnames in the common name (CN) and subject alternative name (SAN) can be bundled.
It should be noted that the SHA-2 family consists of six hash functions with digests (hash values) that are 224, 256, 384 or 512 bits in length. If you were to upload a SHA-512 RSA, this would be counted as the SHA-2 RSA certificate in the pack. If you tried to upload another SHA-2 RSA certificate with a digest of a different bit length into the same certificate pack, you'll get an error unless the host group is different.
Which certificate will my visitors see?
We serve the certificate with the most up-to-date security standards that your visitor's client supports, based on the information the client provides in the ClientHello message of the initial TLS handshake. For example, if your visitors are using the most recent versions of popular web browsers such as Google Chrome, Mozilla Firefox, Microsoft Internet Explorer, Apple Safari, etc., they'll likely see a SHA-2 ECDSA certificate. If, on the other hand, the visitor is still using IE 6 then they'll see a SHA-1 certificate.
How can I upload a custom certificate?
You can upload custom certificates by following the instructions listed here.
What happens when a custom certificate expires?
Expired custom certificates will remain available ninety (90) days past their expiration date, at which point they will be deleted and no longer available at our edge. Custom certificate packs containing expired certificates will also be deleted ninety days past the expired certificate's expiration date even if the pack contains certificates that are still valid.