Synopsis
This chapter describes how transport security and certificate management function in a multi-CDN deployment. Topics include certificate lifecycle and automation, subject naming choices, OCSP and certificate transparency, origin authentication with mutual TLS, session behavior across providers, and controls that keep the security posture consistent while avoiding service disruption.
Scope and goals
The transport layer must present a uniform and reliable interface regardless of which CDN serves a connection. Users should see correct certificates, modern protocol support, stable cipher policy, and predictable session behavior. Operations should see an automated lifecycle that avoids expirations, supports rapid revocation, and provides clear observability. The origin path should authenticate CDNs in a way that cannot be replayed from the public internet.
Host identity and SNI
Public endpoints should present names that match application hostnames. Subject Alternative Name lists can group related hosts on a single certificate when operational simplicity is a priority. Wildcard names reduce issuance churn for subdomains while increasing blast radius during incidents. Dedicated certificates per hostname isolate risk at the cost of more objects to manage. Server Name Indication must be present on all inbound connections so edge and origin select correct certificates and virtual hosts. Any shield or proxy in front of origin should preserve the upstream Host and SNI identity that origin logic expects.
Certificate lifecycle and automation
An automated path is required from order to renewal and revocation. ACME is the standard method for domain validation and renewal at scale. HTTP-01 works when edges can terminate challenges consistently. DNS-01 avoids path conflicts and is convenient for hosts that share routing layers, at the cost of DNS automation and propagation time. For high churn environments, short lived certificates reduce risk if automation is reliable. Renewal windows must include alerting and safe retries. Expiration monitoring should track both published notAfter dates and effective deployment on each CDN.
Key management
Private keys must be generated and stored with strong permissions. Hardware backed storage on provider infrastructure reduces exposure but can limit portability. Where export is allowed, strict controls for custody and audit are required. Key sizes and algorithms should follow current guidance. RSA remains widely compatible. ECDSA reduces handshake overhead and is preferable when client support is adequate. Dual stack deployment with RSA and ECDSA allows gradual migration. Delegated credentials can limit exposure of long term keys where supported.
OCSP, stapling, and revocation
Online Certificate Status Protocol responses can add latency if fetched on demand. Stapling at the edge removes that latency and reduces reliance on client side fetching. Multi-CDN deployments should confirm that each provider staples consistently, rotates responses before expiry, and handles responder outages gracefully. For emergency revocation, CRL and OCSP effectiveness varies by client. Rapid replacement with new keys and certificates is the primary control. Certificate Transparency logging is mandatory for publicly trusted certificates and provides an audit trail of issuance.
Protocol versions and ciphers
TLS 1.3 is the default. TLS 1.2 remains enabled for legacy clients where business requirements justify it. Older versions should remain disabled. Cipher policy must be aligned across providers. Differences in default suites can lead to inconsistent performance or client failures. ALPN negotiation should allow HTTP/2 and HTTP/3 where supported. Session tickets and resumption work within a provider but not across providers because ticket keys are not shared. Observed behavior such as 0-RTT acceptance should be configured consistently or disabled where replay risk is not acceptable.
HTTP/3 and QUIC
HTTP/3 reduces connection setup time and can improve performance in lossy networks. Multi-CDN adds variability because QUIC implementations differ across providers. Alt-Svc advertising and migration between H3 and H2 should be consistent. Telemetry must distinguish protocol versions to diagnose regional issues. Where HTTP/3 is enabled, packet filtering and load balancers must pass UDP traffic reliably.
Certificate choices and naming strategy
Certificate objects can be shared across providers or issued separately. Shared objects simplify audits but require secure transfer and storage. Separate issuance reduces sharing risk but increases the number of renewals. Subject naming should reflect routing plans. If a hostname may migrate between providers frequently, a name that all providers can serve is required. If a provider specific hostname exists behind a proxy, public names should stay stable while internal names handle routing.
Origin authentication and mTLS
The path from CDN to origin should authenticate the caller. IP allowlists reduce unsolicited traffic but do not provide strong identity. Mutual TLS authenticates the CDN at the transport layer. Client certificates issued by a private CA allow revocation and rotation without touching public trust stores. Origin servers should validate client identity, enforce authorization by hostname or path, and log certificate fingerprints for investigations. Token based authorization at the application layer can complement mTLS and carry fine grained context.
Certificate deployment and rollover
Zero downtime replacement requires overlap between old and new certificates on all providers. The sequence begins with issuance and verification, followed by staged deployment across providers, then a short overlap period, and finally removal of the old material. During the overlap, monitoring should confirm that clients in all regions receive the new certificate and that stapled OCSP responses match. Any failure should trigger a revert on the affected edge only, not a global rollback.
HSTS and pinning considerations
HTTP Strict Transport Security reduces downgrade risk and should be enabled for hosts that will remain HTTPS only. Preload entries require careful validation and long term commitment. Public key pinning is deprecated on the web due to operational risk and should not be used. Internal pinning in applications should prefer pinning to a private CA rather than specific keys to avoid brittle deployments.
DNS controls and CAA
Certification Authority Authorization records constrain which authorities may issue for a domain. Multi-CDN does not change this control but increases the need to keep records correct when providers assist with issuance. Each chosen CA must appear in CAA with relevant parameters, including account identifiers where supported. DNS updates must be propagated before issuance attempts to avoid failed orders.
Monitoring and observability
Monitoring must track certificate expiry, chain correctness, staple freshness, protocol mix, handshake errors, and cipher distributions. Measurements should be regional and provider specific. Synthetic probes should validate full handshakes for RSA and ECDSA names where both are offered. Real user telemetry should record negotiated protocol and cipher where privacy policy allows. Dashboards should surface differences between providers so configuration drift is visible.
Incident response
Key compromise, misissuance, and protocol defects require defined actions. Key compromise triggers immediate stop of traffic on affected names, revocation or replacement, and redeployment across providers. Misissuance requires replacement and CA engagement. Protocol defects may require disabling features such as 0-RTT or HTTP/3 temporarily. Runbooks should list contacts at each provider and the CA, with steps that avoid cross-provider regressions.
Interactions with steering layers
Routing changes can expose clients to different TLS stacks even when hostname remains constant. Any planned steering shift should confirm certificate and protocol parity beforehand. During incidents that pin traffic to a single provider, the remaining provider must carry both certificate sets and protocol options required by current clients.
Related chapters
For access control on the origin path see /multicdn/origin-architecture/. For alignment of controls across providers see /multicdn/security-parity/. For measurement of user visible outcomes see /multicdn/signals-telemetry/.
Further reading
RFC 8446 defines TLS 1.3. RFC 8555 defines ACME. RFC 6962 describes Certificate Transparency. RFC 7301 defines ALPN. IETF drafts and provider documentation should be reviewed for delegated credentials and QUIC updates.