HTTP Message Signatures for CDN: Signing Requests and Responses for Integrity

About eighteen months ago we caught a subtle request tampering incident that TLS never would have flagged. An intermediary between our origin and an edge PoP was re-writing a cache key header to force a poisoned object into cache, and because the TLS sessions terminated correctly on both sides, nothing alerted. That’s the gap HTTP Message Signatures was designed to close, and since we rolled out RFC 9421 across our CDN, we’ve finally got end-to-end integrity that survives TLS termination.

Why TLS Termination Breaks Your Trust Model at the Edge

I've spent the last decade watching CDNs get more distributed and more complex, and the assumption that TLS gives you message integrity is one that doesn't hold up in practice. At any modern CDN, TLS terminates at the edge, at mid-tier caches, at WAF layers, and often at a separate origin shield. Each hop decrypts, inspects, potentially modifies, and re-encrypts. The channel is secure, but the message itself isn't protected against a compromised or buggy proxy inside your own infrastructure. We learned this the hard way when a partner's header normalization logic stripped an authorization parameter before it hit origin, causing signed URLs to validate incorrectly.

RFC 9421 solves this by moving integrity from the transport layer to the message layer. Instead of trusting the pipe, you sign the HTTP components themselves — method, target URI, selected headers, derived components like @method and @authority, and optionally the content digest. The signature travels as standard HTTP fields (Signature-Input and Signature), so it persists through any number of terminating proxies. It’s not a replacement for TLS, it’s a complement that lets the origin verify that what the client sent is exactly what arrived, and lets the client verify the response wasn’t altered by cache or edge logic.

For CDN use cases, this matters most for three flows: signed origin pulls where the edge proves to origin it hasn't tampered with the request, signed responses where the client can verify a cached asset came from the authoritative origin, and purged-in-flight protection where stale objects can be validated. If you're already tuning transport performance with techniques like HTTP/2 Flow Control Tuning for CDN: Window Sizes and Stream Management, message signatures are the next logical layer — you're optimizing how bytes move, now you're guaranteeing what those bytes mean hasn't changed.

# Origin pull request with RFC 9421 signature
GET /assets/app.3a8f2.js HTTP/1.1
Host: origin.example.com
Date: Tue, 15 Oct 2024 14:32:00 GMT
Content-Digest: sha-256=:LCa0a2j/xo/5m0U8HTBBNBNCLXBkg7+g+YpeiGJm564=:
Signature-Input: sig1=("@method" "@target-uri" "host" "content-digest");
                 created=1729007520;keyid="edge-key-2024a";alg="ed25519"
Signature: sig1=:wB5zJd6c7Q9lK8p3...mN2vXyZqR4tU6wA==:

# Signature-Input declares covered components and metadata
# alg, created, and keyid are all part of Signature-Input, not the signature itself

Constructing the Signature Base: What You Actually Sign

The trickiest part of implementing RFC 9421 isn’t the crypto — it’s deciding what to cover and getting canonicalization right. The spec defines a signature base as a deterministic serialization of covered components. You’re not signing raw headers; you're signing name + value pairs built from the message plus derived components. I’ve seen more verification failures from whitespace and header ordering than from bad keys. The @method, @target-uri, @status, @query-param, and content-digest components are where the real value is for CDN integrity, because they bind the signature to the intent of the request and the body fingerprint.

For request signing at the edge, we cover @method, @target-uri, @authority, content-digest if there's a body, and any headers that affect routing or access control — typically authorization, date, and our custom x-cdn-cache-key. For response signing at origin, we cover @status, content-digest, content-type, and cache-control. You don't want to sign hop-by-hop headers like connection or transfer-encoding that intermediaries are supposed to strip. We also use expires and created parameters in Signature-Input to prevent replay — a five-minute window has worked well for us without adding too much clock-skew pain.

This approach interacts nicely with modern protocol work. When you're prioritizing critical assets with HTTP/2 Stream Prioritization at CDN Edges: Delivering Critical Resources First, you don't want signature verification to block streaming. And with HTTP/3 Connection Migration: Seamless Handoffs Across Network Changes keeping connections alive across networks, persistent signatures give you continuity that connection-bound security can't. The HTTP Working Group Specifications (https://httpwg.org/specs/) are the authoritative reference for component identifiers, and the practical implementation notes in web.dev Articles (https://web.dev/articles/) helped our front-end team understand how signatures behave in browsers that support them.

// Building an RFC 9421 signature base (Node.js / WebCrypto pseudo-code)
import { createPrivateKey } from 'crypto';

const coveredComponents = [
  '"@method"',
  '"@target-uri"',
  '"@authority"',
  '"content-digest"',
  '"cache-control"'
];

function buildSignatureBase(req) {
  // Each line is: "component-name": value
  const lines = [];
  lines.push(`"@method": ${req.method}`);
  lines.push(`"@target-uri": ${req.url}`);
  lines.push(`"@authority": ${req.headers.host}`);
  lines.push(`"content-digest": ${req.headers['content-digest']}`);
  lines.push(`"cache-control": ${req.headers['cache-control']}`);
  // @signature-params is always last and contains Signature-Input params
  lines.push(`"@signature-params": ${signatureInputParams}`);
  return lines.join('\n');
}

// Sign with Ed25519 - fast, small signatures, ideal for edge
const signatureBase = buildSignatureBase(incomingRequest);
const signature = await ed25519.sign(privateKey, Buffer.from(signatureBase));

Signature Parameters and Real-World Performance Costs

Choosing your algorithm and parameters isn't just a security decision, it's a performance and operational one. We started with RSA-PSS and quickly moved to Ed25519 after seeing CPU costs at 80k requests per second. RSA verification is cheaper than signing, which is nice for origin-heavy verification, but Ed25519 gives you 64-byte signatures, fast sign and verify, and no parameter complexity. HMAC-SHA256 with a shared secret is even faster if you control both edge and origin and can rotate keys safely — we use it for internal edge-to-shield traffic where public key distribution isn't worth the overhead.

Key management is where most teams underestimate the work. RFC 9421 doesn't dictate how you distribute keys, it just references them via keyid. We've settled on a short-lived key model with 7-day rotation, published via a well-known JWKS endpoint that both edge and origin can fetch. The origin caches the JWKS for 5 minutes and we pre-publish the next key 24 hours before activation, so there's no flag day. Don't forget to sign the expires parameter itself — without it, an attacker can replay a valid signature for a stale, vulnerable asset that you've already purged.

We've benchmarked this thoroughly on our production fleet (Intel Ice Lake, OpenSSL 3.1, 10G edge nodes). The numbers below are median over 1M requests with 5 covered components and payloads under 128KB. Larger bodies don't change signature cost much because you're signing the Content-Digest, not the body itself, which keeps verification O(1) regardless of object size.

Implementing Signatures at the Edge: From Origin Keys to Edge Verification

You don't need to roll your own crypto to get this working - most of the heavy lifting's already done if you're on a modern stack. At the origin, you're generating a `Signature-Input` and `Signature` header pair for every response you want the edge to trust. At the edge, your worker or compute layer verifies that signature before it even thinks about caching. We've found ed25519 is the sweet spot for CDNs: verification runs around 0.12-0.18ms on a standard Xeon 3.2GHz edge core, compared to ~0.75ms for rsa-pss and ~0.02ms for hmac-sha256. That hmac speed is tempting, but symmetric keys mean sharing secrets with every PoP, which we wouldn't recommend outside of mTLS-bound origin-to-edge links.

The trickiest part isn't the crypto - it's key distribution and rotation. Don't hardcode keys in your edge workers. Publish your public keys via a well-known JWKS endpoint (e.g., `/.well-known/http-signatures/jwks.json`) and cache it at the edge with a 5-minute TTL. Use `keyid` to version your keys and rotate every 30 days with a 7-day overlap where both old and new keys are valid. Your edge logic should fetch, cache, and gracefully fall back if verification fails due to a stale key - a single failed fetch shouldn't poison your entire cache. This pattern becomes especially important when you're proxying more complex protocols like WebTransport Through CDN Proxies: Bidirectional Streams Over HTTP/3, where you can't just re-sign a long-lived bidirectional stream the same way you would a simple GET.

// Origin: Node.js signing with @http-message-signatures/core
import { signMessage, generateKeyPair } from 'http-message-signatures';

const keyPair = await generateKeyPair('ed25519', { keyid: 'origin-key-2024-05' });

// What you sign matters - include what you cache on
const signatureInput = {
  sig1: {
    components: ['@method', '@target-uri', 'content-digest', 'content-type', 'cache-status'],
    params: {
      created: Math.floor(Date.now() / 1000),
      expires: Math.floor(Date.now() / 1000) + 300, // 5 min validity
      keyid: 'origin-key-2024-05',
      alg: 'ed25519',
      tag: 'cdn-response'
    }
  }
};

const headers = {
  'content-digest': 'sha-256=:X48E9qOokqqrvdaQd1CUAdYhUWoGBegbxcjG2BxGskY=:',
  'content-type': 'application/json',
  'cache-status': 'HIT'
};

const { 'signature-input': sigInput, signature } = await signMessage(
  { method: 'GET', url: 'https://cdn.example.com/api/data', headers },
  { key: keyPair.privateKey, ...signatureInput.sig1 }
);

// Edge Worker (Cloudflare/Fastly Compute) verification
// Verify BEFORE cache lookup - ~0.15ms overhead, saves you from serving poisoned content
const isValid = await verifyMessage(request, signature, sigInput, jwksPublicKey);
if (!isValid) {
  // Fail closed for sensitive origins, fail open with revalidation for others
  return fetch(request, { cf: { cacheTtl: 0 } });
}

Advanced Patterns: Clock Skew, Trailer Signatures, and Debugging Failures

Here's where most teams get burned: clock skew. The `created` and `expires` parameters give you a 5-10 minute window by default, but we've seen edge PoPs drift by 30-45 seconds during NTP hiccups. Set your verification window to allow at least 60 seconds of skew in both directions, and always use `created` rather than relying on the `Date` header, which intermediaries love to rewrite. If you're seeing intermittent `expired signature` errors that correlate with specific PoPs, it's almost always clock drift, not a key issue. Log the `signature-input` `created` value versus edge `now()` on every failure - you'll spot the drift in minutes.

Another pattern we use heavily is signing the `Content-Digest` instead of the full body, and deferring checksum verification to trailers for large objects. For 100MB+ video segments or log deliveries, you don't want to buffer the entire body to verify. Instead, sign the `content-digest` and `trailer` signatures separately. The edge can stream the body while verifying the digest on-the-fly, then validate the trailer signature at the end. If you're doing post-body checksums or streaming logs, check out how HTTP Trailers for CDN: Post-Body Checksums, Timing, and Logging handles this without breaking the signature base. And don't forget that message signatures interact with conditional requests - if you're signing responses that use `ETag` or `If-None-Match`, you must include `etag` and `if-none-match` in your covered components or a 304 revalidation can bypass your signature check entirely. We cover that edge case in detail in Advanced HTTP Conditional Requests: If-Match, If-Range, and Partial Updates.

When verification fails, don't just log "invalid signature." Log the reconstructed signature base. 90% of failures we've debugged were canonicalization issues: a missing `:authority` vs `host` header, lowercasing mistakes, or a CDN adding a `cf-ray` or `x-cache` header after signing. Use the spec's exact serialization - quoted strings, `sf` values, and byte sequences are brutal if you get them wrong. Our go-to debug flow: dump the `signature-input`, reconstruct the `@signature-params` line, and diff it byte-for-byte against what the origin sent. Tools like `http-signature-debug` will save you hours here.

Frequently Asked Questions