TLS Delegated Credentials Edge Key Isolation Playbook

Date: 2026-04-12
Category: knowledge
Audience: security / SRE / platform teams running TLS at the edge

1) Why this deserves operational attention

If you terminate TLS on many edge nodes, POPs, or CDN machines, the ugly trade-off is familiar:

• either distribute the long-lived certificate private key widely,
• or keep the key remote and pay latency / availability tax for every handshake,
• or rotate short-lived CA-issued certs aggressively and inherit issuance dependency.

Delegated Credentials (DCs, RFC 9345) give you a better middle ground.

They let the holder of a normal end-entity certificate mint a short-lived delegated credential for TLS 1.3 use, signed by the certificate key, and push that short-lived keypair to the edge. The edge terminates handshakes with the delegated key, while the long-lived certificate key can stay in a more tightly controlled signer or HSM-backed environment.

This reduces blast radius if an edge key leaks, removes the per-handshake round trip of keyless designs, and gives operators more agility in handshake signature algorithms.

2) Correct mental model

A delegated credential is not a new CA-issued certificate.

It is better thought of as:

• a signed, short-lived TLS authorization object,
• bound to a specific end-entity certificate,
• containing its own public key and signature algorithm,
• usable only when the client explicitly supports delegated credentials,
• valid for TLS 1.3+ only.

If the client does not support DCs, you still need a normal certificate path and normal handshake behavior.

So DCs are an optimization and risk-reduction layer on top of PKI, not a replacement for PKI.

3) What operators gain

A) Smaller compromise window at the edge

RFC 9345 caps default delegated credential validity at 7 days max. That means an exfiltrated edge key is far less durable than a leaked leaf cert key with a 90-day certificate behind it.

B) No per-handshake callback to a remote key server

Compared with keyless/remote-sign designs, DCs convert the problem from pull on every handshake to push short-lived authorization periodically.

Operationally, that means:

• lower handshake latency,
• lower dependency on central signer availability,
• fewer failure modes during traffic spikes.

C) Signature algorithm agility

RFC 9345 explicitly allows operators to use modern handshake signature algorithms for the delegated credential even if the CA ecosystem is slower to support those algorithms in issued certificates.

That makes DCs useful not only for key isolation, but also for controlled algorithm migration experiments.

4) Hard constraints from the RFC

Operators should memorize these:

1. Delegated Credentials are for TLS/DTLS 1.3 or later only.
2. Clients must advertise support before the server can use a DC.
3. The end-entity certificate must include the DelegationUsage X.509 extension.
4. The certificate must also have digitalSignature KeyUsage.
5. The DelegationUsage extension must be non-critical.
6. Default maximum DC validity is 7 days.
7. A DC cannot outlive the parent certificate.
8. Some RSA variants are disallowed for DC use; RFC 9345 forbids rsa_pss_rsae_* schemes in this context.

The DelegationUsage extension OID defined by RFC 9345 is:

1.3.6.1.4.1.44363.44

That detail matters because CA and issuance pipeline support is still one of the real deployment bottlenecks.

5) What DCs fix vs. what they do not

DCs help with

• Limiting exposure of TLS termination keys at the edge
• Reducing reliance on remote signing per handshake
• Faster deployment of newer signature algorithms
• Making edge compromise less catastrophic

DCs do not solve

• General certificate issuance hygiene
• Full revocation agility for stolen delegated credentials
• Client support fragmentation
• Weak edge host security
• All key-management complexity

The RFC is explicit about one painful point: delegated credentials do not introduce a special early revocation mechanism. In practice, expiry is the revocation lever. If a DC private key leaks, you mostly wait out the short lifetime or revoke the parent cert/key relationship at a much higher cost.

So the real protection is not magical revocation; it is short lifetime + better signer isolation + rapid reissuance.

6) Practical deployment architecture

A) Central signer + pushed delegated credentials

This is the canonical design.

• Long-lived certificate private key stays in HSM / tightly controlled signer tier.
• A signing service periodically mints fresh DCs.
• Edge nodes receive short-lived DC keypairs plus metadata.
• Edge terminates TLS locally using the delegated key.

Best default for large fleets.

B) CDN / reverse proxy integration

If your CDN or edge provider supports DCs, they may auto-generate and rotate them once you upload a certificate containing the right extension.

This minimizes custom control-plane work, but you still need to verify:

• client support expectations,
• fallback behavior for non-supporting clients,
• where the parent certificate key lives,
• rotation cadence and propagation lag,
• observability for DC usage vs. normal cert usage.

C) Hybrid keyless + delegated credentials

A sensible migration pattern is:

• use DCs for clients that support them,
• keep keyless or standard certificate termination as fallback,
• gradually measure handshake success / latency / client mix.

This is often the safest real-world rollout because browser and library support is not universal.

7) Operational rules that matter most

Rule 1: Keep the parent certificate key off the edge

If the long-lived leaf key still ends up copied to every edge node, you have defeated the point.

Rule 2: Rotate DCs much faster than the 7-day ceiling

The RFC ceiling is not your target.

A production-friendly stance is usually:

• mint DCs at least daily,
• overlap generations,
• distribute replacements well before expiry,
• keep expiry short enough that theft has a narrow shelf life.

Think of 7 days as the maximum legal speed, not the recommended cruising speed.

Rule 3: Design for clock skew

RFC 9345 explicitly calls out client clock skew as an operational risk. If client clocks are far ahead or behind, they may reject a DC that looks valid from the server side.

That means your validity window must leave room for:

• issuance lag,
• propagation lag,
• client skew,
• rollback / canary overlap.

Overly aggressive lifetimes can turn into mystery handshake failures.

Rule 4: Always preserve a clean fallback path

Because support is uneven, you should assume some clients will continue using the ordinary certificate path.

Treat DCs as a conditional fast path, not an exclusive requirement, unless you fully control the client population.

Rule 5: Treat DC telemetry as first-class

If you cannot answer “what fraction of handshakes used DCs?” you are flying blind.

8) Minimum observability

Track at least:

• percentage of TLS handshakes using delegated credentials,
• handshake failure rate split by DC-capable vs. non-DC path,
• DC issuance success/failure rate,
• propagation lag from minting to edge availability,
• remaining lifetime distribution of active DCs,
• signer/HSM latency and failure rate,
• certificate chain validation failures,
• client-clock-related rejection patterns if available.

Useful alerts:

• no fresh DC minted within expected interval,
• more than X% of edges serving a DC near expiry,
• sudden drop in DC usage rate without client-mix explanation,
• handshake failures spike after rotation,
• signer reachable but propagation incomplete.

9) Session resumption caveat people miss

RFC 9345 warns that if a peer caches the certificate chain and re-validates it on resumption, it should also cache and re-validate the associated delegated credential. Otherwise, a resumed connection may incorrectly proceed after the DC has expired.

This is one of those “works in test, weird in prod” edges.

If you operate custom TLS infrastructure, review your resumption and cache behavior carefully.

10) CA and ecosystem reality

The protocol is standardized, but deployment still depends on ecosystem support in three places:

1. CA issuance support for the DelegationUsage extension
2. TLS stack / proxy support for generating and presenting DCs
3. Client support for advertising and validating them

That means the main operational question is not “is RFC 9345 good?”

It is:

Can my issuance pipeline, my edge software, and enough of my client population all meet in the same place?

If not, DCs remain a targeted optimization for specific traffic segments rather than a universal default.

11) Safe rollout sequence

Phase 0 — capability check

• confirm your CA can issue the DelegationUsage extension;
• confirm your edge stack can generate, load, and rotate DCs;
• confirm your metrics can distinguish DC from non-DC handshakes.

Phase 1 — dark canary

• enable issuance and edge loading;
• expose DCs to a tiny slice of traffic;
• compare handshake success, latency, and CPU cost.

Phase 2 — broad fallback rollout

• expand usage while retaining ordinary certificate fallback;
• validate rotation reliability under real traffic and deploy events;
• watch for clock-skew and resumption-related anomalies.

Phase 3 — tighten signer isolation

• reduce who/what can access the parent cert key;
• move parent-key operations behind stricter controls;
• treat edge DC distribution as disposable and high-frequency.

Phase 4 — optimize cadence

• shorten DC validity if your control plane is reliable enough;
• improve overlap windows and rollback speed;
• document failure policy for expired or missing DCs.

12) Common anti-patterns

• Enabling DCs without checking whether the CA can actually issue the required extension.
• Treating the 7-day RFC cap as the desired operational lifetime.
• Removing the standard certificate path too early.
• Ignoring clock skew when choosing validity windows.
• Failing to measure which handshakes actually used DCs.
• Assuming DCs solve revocation problems; they mostly shrink the blast radius instead.
• Copying the parent certificate key into broad automation just to mint DCs “conveniently.”

13) Bottom line

Delegated Credentials are one of those rare protocol ideas that are both cryptographically elegant and operationally sane.

They let you push trust outward to the edge without pushing your most valuable TLS private key everywhere. That is the real win.

If you run a large TLS footprint, the key question is not whether DCs are interesting. They are.

The question is whether your stack is mature enough to support:

• CA extension handling,
• safe delegated-key rotation,
• observability of client uptake,
• and a disciplined fallback path.

If yes, DCs are a strong tool for edge key isolation with much better latency characteristics than per-handshake remote signing.

References

1. RFC 9345 — Delegated Credentials for TLS and DTLS
   https://www.rfc-editor.org/info/rfc9345
2. Cloudflare — Delegated Credentials for TLS
   https://blog.cloudflare.com/keyless-delegation/
3. Cloudflare Docs — Keyless delegation
   https://developers.cloudflare.com/ssl/keyless-ssl/reference/keyless-delegation/
4. Mozilla Security Blog — Validating Delegated Credentials for TLS in Firefox
   https://blog.mozilla.org/security/2019/11/01/validating-delegated-credentials-for-tls-in-firefox/