Keyless SSL now supports FIPS 140-2 L3 hardware security module (HSM) offerings from all major cloud providers

Keyless SSL now supports FIPS 140-2 L3 HSM offerings across major cloud providers

Cloudflare has extended Keyless SSL to work with FIPS 140-2 Level 3 validated hardware security module (HSM) offerings from Amazon Web Services, Google Cloud, IBM Cloud, and Microsoft Azure. The update means organizations with strict key custody requirements can now terminate TLS at Cloudflare's edge while keeping private keys in cloud-hosted HSMs, rather than on premises.

Keyless SSL has been part of Cloudflare's architecture since 2014. The protocol keeps private keys off the machines that perform TLS handshakes at the edge. When a handshake requires a signing operation, the data is sent to a separate system that holds the key. For most customers, Cloudflare manages that system. For customers with security policies that mandate where keys can be stored, the key server has typically run the open source gokeyless daemon, either directly on a server or backed by an on-premises HSM accessed via PKCS#11.

That model became impractical for regulated industries — financial services, healthcare, cryptocurrency — that have moved workloads to the cloud, since they cannot ship physical HSMs to cloud providers. The newly supported offerings are:

• Amazon Cloud HSM
• Google Cloud HSM
• IBM Cloud HSM
• Microsoft Azure Dedicated HSM and Managed HSM

Any other HSM implementing the PKCS#11 standard, including the nCipher nShield Connect and Thales Luna series, continues to be supported.

Why HSMs are held to a higher standard

HSMs are tamper-resistant, purpose-built devices hardened against side-channel attacks and optimized for cryptographic operations such as signing and decryption. The recommended practice is to generate private keys directly on the HSM and never let them leave the device. HSMs offer stronger randomness guarantees than general-purpose servers, and they protect keys in memory before writing them to disk in encrypted form. Services that need to use a key make authenticated API calls into the device via vendor-provided libraries.

FIPS 140-2 defines four levels of security requirements for cryptographic modules, covering approved algorithms, security functions, role-based access control, and tamper-evident protections. Level 3, which all the new cloud HSM offerings meet, is the level most commonly mandated by security policies in regulated industries. NIST administers the Cryptographic Module Validation Program and maintains a searchable database of validated modules.

Existing Keyless SSL customers can start using the new cloud HSM support immediately. Instructions are available at developers.cloudflare.com, with source code on GitHub.

End-to-end example: Microsoft Azure Managed HSM

Azure Key Vault's Managed HSM offering is FIPS 140-2 Level 3 validated and integrated with Azure services including Storage, SQL, and Information Protection. It is currently in public preview in East US 2, South Central US, North Europe, and West Europe.

The following walkthrough provisions a Managed HSM and configures gokeyless to use it. Commands were run on an Ubuntu VM created in the same region (South Central US) as the HSM, which is also where the Keyless SSL daemon will be deployed.

Provision and activate the HSM

Start by logging in via the Azure CLI and creating a resource group in a supported region. Preview-related warnings from commands are expected.

Next, provision the HSM resource and activate it by downloading the security domain. The example below grants administrative access to the signed-in user and another administrator, whose OID can be retrieved via the same oid=$(...) command from a CLI session where that user is logged in.

Record the hsmUri property returned by the provisioning command — you will need it when configuring Keyless SSL on the VM.

The HSM must be given at least three RSA public keys before it is ready for use. The HSM encrypts the security domain with these keys and returns it to you. If you encounter a "Failed to connect to MSI" error when using the Azure Portal cloud shell, run az login again; this is a known issue.

Once the HSM is provisioned, import your private key into the key vault. The returned URI will be added to the Keyless YAML file to indicate where the private key is stored.

Deploy the key server

Create a VM where the gokeyless daemon will run. This example uses an Ubuntu Xenial VM in the same resource group and region as the HSM. Note the VM's public IP for remote access.

Configure the VM as a key server by adding the Cloudflare Package Repository, updating the OS package listings, and installing the gokeyless server.

Then update the gokeyless YAML file with the keyserver hostname — which should have a DNS record pointing to the VM — along with the zoneID and Origin CA API key from the Cloudflare dashboard. Add the URI that points to your private key's directory under private_key_stores before starting the keyless server.

Back in the Azure portal, open the required TCP ports for the VM. Under Networking → Add inbound port rule, allow traffic on any source port with destination port 2407.

In the Cloudflare dashboard, upload your SSL certificate via "Upload Keyless SSL Certificate" under the SSL/TLS tab's Edge Certificates section. Enter the key server label, the hostname from the YAML file, port 2407 (the default), and paste the SSL certificate.

Test with curl -v https://zone.com and confirm the TLS handshake completes successfully.

Other cloud HSM options

Beyond Managed HSM, Azure customers can use keys stored in the Dedicated HSM offering, based on the SafeNet Luna Network HSM 7 Model A790 series. That offering is validated against both FIPS 140-2 Level 3 and eIDAS Common Criteria EAL4+. After deploying the HSM, follow the Azure-specific Keyless SSL instructions.

AWS CloudHSM provides FIPS 140-2 Level 3 validated HSMs. The official AWS Terraform Provider supports the aws_cloudhsm_v2_cluster resource, which is the version Cloudflare supports. After provisioning a cluster, follow the AWS-specific instructions.

Google Cloud HSM uses Cloud KMS as a front end for keys hosted in FIPS 140-2 Level 3 validated HSMs. Google also offers colocation for customer-managed HSMs; contact your GCP account representative for details. After creating a key ring and key, follow the Google Cloud-specific instructions. More on asymmetric keys with GCP KMS is available here.

IBM Cloud HSM 7.0 provides FIPS 140-2 Level 3 validated capabilities based on the SafeNet Luna A750 series. After provisioning, refer to the IBM-specific instructions.

Troubleshooting and support

HSMs provide strong key protection but can be complex to deploy. For issues with provisioning the HSM itself, Cloudflare recommends starting with the cloud provider's support channels. For help configuring an HSM to work with Cloudflare's edge, or to provide feedback on the process, contact your Solutions Engineering team to be connected with Cloudflare's Keyless SSL specialists.