Summary

  • RFC 9538 lets an upstream CDN publish an MI.ACMEDelegationMethod object so an authorized downstream CDN can generate its own key pair and obtain a certificate without receiving the upstream party’s long-lived private key.
  • The delegation object, CSR check and CA issuance prove bounded facts. They do not prove that DNS points to the intended fleet, that every endpoint installed and selected the certificate, or that a client received the intended content.
  • STAR cancellation and ordinary certificate revocation end authority differently. Operations need separate receipts for authorization, issuance, DNS, deployment, TLS, content and termination.

The certificate can be impeccable and the service still wrong.

Imagine a downstream CDN has generated a private key, submitted a CSR permitted by its upstream partner, received a valid certificate and recorded a clean ACME order. One region is still serving the previous certificate. Another region has the new key on disk but its SNI rule selects a default certificate. A CNAME has propagated to most resolvers but not all. The TLS handshake that does succeed reaches a cache holding the wrong customer’s object. None of those failures contradicts the certificate.

RFC 9538, published on the IETF Standards Track in February 2024, solves a real coordination problem. When an upstream CDN delegates HTTPS delivery to a downstream CDN through DNS redirection, the downstream operator needs a certificate for the content provider’s name. Copying a long-lived private key across organisations would widen the secret’s exposure. RFC 9538 instead connects CDNI metadata to the delegation model in RFC 9115: the downstream CDN owns its new key pair, while the upstream identity owner constrains what certificate may be requested.

Four fields bootstrap a certificate path

The registered metadata type is MI.ACMEDelegationMethod. Its mandatory acme-delegation field is an HTTPS URL for the delegation object associated with the downstream CDN’s account on the upstream CDN’s ACME server. time-window supplies the relevant validity interval. The presence of lifetime selects a short-term, automatically renewed STAR certificate; its absence selects an ordinary non-STAR certificate. Optional lifetime-adjust refines the STAR lifetime request.

That is a compact and useful contract. The live IANA CDNI parameters registry records the payload type for both metadata and capability interfaces. RFC 8006 supplies the CDNI metadata framework and its authentication and confidentiality duties; RFC 8008 supplies footprint-and-capability semantics. The broader actor model comes from RFC 7336.

But the four fields do not name every edge node. They carry no install acknowledgement, DNS observation, SNI probe, certificate fingerprint per point of presence, HTTP content digest or client result. A dashboard that turns “delegation advertised” into “HTTPS delivery ready” has crossed several unrecorded boundaries.

The account authorizes a requester, not an outcome

RFC 9115 calls the upstream side the Identity Owner and the downstream side the Name Delegation Consumer. The downstream account is preregistered out of band. It retrieves a delegation object containing a CSR template and, optionally, CNAME mappings. It creates its own key pair and CSR. The Identity Owner checks the CSR against the permitted shape, then uses its own CA account to pursue issuance under base ACME, RFC 8555.

This separation keeps the upstream party’s private key out of the downstream fleet. It also makes the downstream account key exceptionally important. Account authentication plus the configured delegation replaces the ordinary ACME challenge on that leg. RFC 9115 therefore requires each account to be tied to exact policies describing which names it may request and how.

A valid CSR answers whether a request matches that template. A valid order answers whether the CA’s issuance process completed. X.509 path rules in RFC 5280 and service-identity checks in RFC 9525 can establish whether a client should accept the presented identity. TLS 1.3 and SNI define how that identity participates in a connection. None of these statements says which object the HTTP layer returned.

DNS is an independent lever

RFC 9115’s delegation object can carry CNAME mappings. RFC 9538 notes that a later update could add SVCB and HTTPS records. Either way, the name-to-service projection remains its own control surface. The content provider may deliberately retain sole authority over the DNS zone because a CDN able to change both content and validation state may acquire broader certificate power than intended.

CAA can restrict which certification authorities may issue. The ACME-specific parameters in RFC 8557 can narrow issuance to a particular account and validation method. These controls reduce the authorization surface. They do not prove that a resolver observed the new record, that the resulting address belongs to the intended deployment, or that traffic reached every planned site.

The operator therefore needs an authoritative DNS change receipt, the exact RRset and its timing, multi-vantage resolution, and a mapping from returned endpoints to the deployment inventory. “Certificate issued” should never substitute for those observations.

Cancellation and revocation use different clocks

RFC 8739 defines STAR certificates: short-lived credentials that are automatically renewed and repeatedly downloaded. The upstream Identity Owner can cancel future issuance. Yet cancellation does not erase the last certificate already installed. Effective authority persists until that certificate expires. A useful incident clock records the cancellation acknowledgement, last issuance, last download, last activation and final expiry.

For a non-STAR certificate, the Identity Owner can request revocation through ACME. The downstream operator, because it owns the certificate private key, may also be capable of revocation and should bypass the upstream only when security demands it. CA acceptance of a revocation request is still not an edge-cleanup receipt. A node can continue presenting the certificate, and relying-party behaviour depends on the status mechanisms and validation path in use.

Certificate Transparency v2 can make issuance observable. It cannot attest that the certificate was deployed, selected or removed. RFC 9325 provides TLS deployment guidance, but compliance with guidance is not a probe result.

Build the missing chain of receipts

The defensible operating record has at least seven links. First, preserve the content provider’s instruction: exact domains, exact downstream account, time window and redelegation rule. Second, hash the delegation object and CSR template. Third, retain the CSR, key fingerprint, order and CA authorization. Fourth, record the issued serial, SANs, chain and validity. Fifth, verify authoritative DNS and its observed projections. Sixth, reconcile every delivery endpoint against the activated certificate fingerprint and SNI rule.

Seventh, probe TLS and HTTP from independent networks and verify the returned content, then repeat the chain for renewal or termination.

Those receipts should not be collapsed into one status. “Issued but not installed” is actionable. “Installed on 92 percent of edges” is actionable. “DNS moved while the target fleet was incomplete” is actionable. “Cancellation accepted; last STAR certificate valid for 47 more minutes” is actionable. A green word—secure, ready or revoked—conceals the very boundary an operator needs during a cutover.

RFC 9538 does not make that category mistake. Operators do when they treat a coordination artifact as a witness for running reality.

Sources and limits

The publication and status record can be checked on the RFC Editor information page, the IETF history and the RFC Editor errata surface. The analysis above also uses RFCs 9538, 9115, 8739, 8555, 8006, 8008, 7336, 9460, 9325, 9525, 5280, 8659, 8557, 8446, 6066 and 9162, plus the IANA registry.

No named CDN deployment, incident, endpoint inventory or packet capture was examined. The article does not claim that RFC 9538 is defective, that every deployment uses the same DNS or revocation design, or that one observed connection represents an entire fleet.