Axelspire

Edge TLS & Key Exposure Strategy: Who Holds Your Private Keys?

When you upload a TLS certificate to Cloudflare, Akamai, AWS CloudFront, or any other CDN or cloud load balancer, you are handing your private key to a third party. That third party terminates TLS on your behalf, using your private key, on infrastructure you don't control, in data centres you've never visited.

TLS at the CDN or cloud edge trades performance and DDoS absorption for custodial private keys—make that trade consciously.
TLS at the CDN or cloud edge trades performance and DDoS absorption for custodial private keys—make that trade consciously.

For most organisations, this is an acceptable trade-off. CDN-terminated TLS provides better performance (TLS handshakes closer to the user), DDoS protection (the CDN absorbs attack traffic before it reaches your origin), and operational simplicity (the CDN handles certificate deployment and renewal).

What most organisations haven't done is consciously evaluate the trade-off. The private key upload happened when someone set up the CDN five years ago. Nobody asked what the CDN's key protection practices are. Nobody checked the contract for key handling obligations. Nobody assessed the exposure if the CDN is compromised.

Featured Tool Runs fully in-browser

PKI Health Radar

Drag the sliders to assess your current posture — scores update instantly.

6 more tools: Cost & Risk Explorer Timeline Builder Shadow Heatmap Process Transform Slider Scenario Comparator What-If Demo All tools & guide →

The strategic question isn't whether to use CDN-terminated TLS — for most architectures, it's the right answer. The question is: what's your key exposure posture, and does it match your risk tolerance?

TLS Termination Architecture: Edge, Origin, and Re-Encryption

TLS can terminate at three points, and the architecture you choose determines who holds your keys and what's encrypted between them.

Edge termination is the most common model. The CDN or cloud load balancer terminates TLS, decrypts the request, and forwards it to your origin server. Traffic between the CDN edge and your origin may be unencrypted (HTTP), encrypted with a separate certificate (HTTPS re-encryption), or carried over a private network (VPN or dedicated connection).

The security consideration is that your content exists in plaintext at the CDN edge. The CDN's infrastructure processes your decrypted request and response. If the CDN is compromised — or if a CDN employee with access acts maliciously — your traffic is exposed. Your private key, sitting on the CDN's edge servers, could be extracted.

Origin termination means the CDN passes encrypted traffic through to your origin server without decrypting it. Your origin server holds the private key and terminates TLS. This model protects your private key and your content from CDN compromise, but it sacrifices most of the CDN's TLS performance benefits — the TLS handshake happens at your origin, not at the edge, increasing latency for geographically distant users.

Re-encryption (end-to-end encryption) is the hybrid model. The CDN terminates the client's TLS connection at the edge, then establishes a separate TLS connection to your origin. Two TLS sessions, two certificate pairs. Traffic is encrypted in transit at all points, but the CDN still has access to decrypted content for the brief period between termination and re-encryption. This model protects against network interception between CDN and origin but doesn't protect against CDN infrastructure compromise.

Most enterprises use edge termination with re-encryption. It's the default configuration for most CDN providers and provides a reasonable balance of performance and security. But "reasonable" is a risk-calibrated judgment that should be made explicitly, not accepted by default.

Keyless SSL and Key Delegation

For organisations that need CDN performance benefits but can't accept the key exposure of edge termination, two architectural patterns keep private keys under your control.

Keyless SSL (pioneered by Cloudflare) splits the TLS handshake between the CDN edge and your infrastructure. During the handshake, the CDN edge forwards the key-exchange operation to a key server you operate in your own infrastructure. Your key server performs the private key operation (decryption or signing) and returns the result. The CDN edge completes the handshake using the result but never possesses your private key.

The trade-off is latency: every new TLS connection requires a round-trip between the CDN edge and your key server. For initial handshakes, this adds measurable latency. TLS session resumption and TLS 1.3's 0-RTT mechanism mitigate the impact for repeat connections, but the first connection to a given edge node for a given session is slower.

Keyless SSL also introduces a dependency: if your key server is unavailable, new TLS connections fail. Your key server needs the same availability characteristics as a production service — redundancy, monitoring, geographic distribution. You're essentially operating a critical infrastructure component to protect a key.

Delegated credentials (RFC 9345) are a newer approach. Your origin server issues a short-lived "delegated credential" — a signed authorisation that allows the CDN edge to act on behalf of your certificate for a limited time (typically hours). The CDN edge uses the delegated credential for TLS handshakes without needing your long-lived private key. If the credential is compromised, it expires within hours. Your long-lived private key never leaves your infrastructure.

Delegated credentials are not yet universally supported by CDN providers or clients, but they represent the direction the industry is moving: short-lived, constrained authorisations rather than long-term key sharing.

Certificate Lifecycle at the Edge

CDN-terminated TLS introduces certificate lifecycle coordination challenges that are distinct from origin-managed TLS.

Renewal coordination. When you manage your own certificates, renewal is a single operation: issue a new certificate and deploy it. With CDN-terminated TLS, you issue the certificate and then deploy it to the CDN — either by uploading it via the CDN's API/portal, or by configuring the CDN to use its own managed certificates. If you use CDN-managed certificates (AWS Certificate Manager, Cloudflare Universal SSL, Akamai CPS), the CDN handles issuance and renewal automatically, eliminating this coordination — but also removing your control over the CA, certificate type, and lifecycle.

Multi-CDN environments compound the coordination problem. If you distribute traffic across multiple CDN providers for redundancy or performance, each provider needs a copy of your certificate (or its own managed certificate). Renewal must happen across all providers within the same window. A certificate that's valid on one CDN but expired on another creates inconsistent behaviour that's difficult to diagnose.

CDN-managed certificates versus customer-managed certificates is a strategic choice. CDN-managed certificates are operationally simpler but limit your control: you may not be able to choose your CA, you may not get OV or EV validation, and you lose the ability to use the same certificate across CDN and non-CDN infrastructure. Customer-managed certificates provide full control but require you to maintain the certificate lifecycle and coordinate deployment to the CDN.

For organisations with a multi-CA strategy, CDN-managed certificates may create shadow CA relationships that fall outside your CA governance. The CDN chooses the CA — often a CA you haven't evaluated against your CA selection criteria.

Multi-Edge and Hybrid Architectures

Large organisations rarely have a single TLS termination point. The typical enterprise architecture includes external CDN edges, cloud provider load balancers, on-premises reverse proxies, and application-level TLS — each with its own certificates, keys, and lifecycle.

The strategic challenge is maintaining a coherent key exposure posture across all of these. Your private keys might be in Cloudflare's edge (CDN), AWS ALB (cloud load balancer), Nginx on your DMZ servers (reverse proxy), and the application itself (end-to-end application TLS). Four different key management contexts, four different exposure profiles.

Your certificate observability needs to cover all of these surfaces. A certificate that's correctly deployed at the CDN edge but misconfigured on the origin server causes intermittent failures that are difficult to diagnose without visibility into both layers.

The key exposure assessment should map each TLS termination point to its key protection characteristics: who has access to the key, what contractual protections exist, what happens if that party is compromised, and what's the remediation path (re-issue from a different CA, deploy to a different provider, rotate keys).

Contractual and Compliance Considerations

When you upload a private key to a CDN or cloud provider, the contractual framework matters.

Review your CDN contract for: key handling obligations (how the provider stores, protects, and eventually destroys your keys), incident notification requirements (are they obligated to notify you if their key storage infrastructure is compromised?), compliance certifications (SOC 2, ISO 27001, PCI DSS — relevant if your certificates protect regulated data), and data residency (where are your keys physically stored, and does this comply with your regulatory requirements?).

For organisations subject to PCI DSS, the key management requirements in Section 3 apply to TLS private keys held by third parties. Your PCI compliance assessment should include the CDN's key handling practices.

For organisations where key exposure is a regulatory concern (financial services, government, healthcare), the keyless SSL or delegated credentials architecture may be required rather than optional. The latency cost is the price of compliance.

Sector context: regulated key and contract expectations in financial services and healthcare layered on edge termination choices.

Traffic path: browser to edge termination (third-party key custody) to origin—where trust and contracts must follow the data.
Traffic path: browser to edge termination (third-party key custody) to origin—where trust and contracts must follow the data.

← Back to Certificate Strategy: The Framework Most Organisations Skip

External References