Summary

  • The HTTP Working Group's secondary server certificate draft, revision 03, updated 2 November 2026, remains an Internet-Draft. It proposes a SERVER_CERTIFICATE frame so an HTTP/2 or HTTP/3 server can prove possession of an additional site's certificate after the TLS connection exists.
  • Both peers must first signal support. The RFC 9261 exported authenticator binds the extra certificate's proof to the existing TLS session; the client still has to decide whether that certificate and the server are acceptable for the second origin.
  • Section 7.3 names the awkward cutover: moving a site's CNAME to a new provider directs new connections elsewhere, while a former provider may continue offering the site's secondary certificate over connections opened for other sites. The draft leaves that persistence problem to the provider and customer to manage.

Imagine a publisher moving its site away from a hosting provider. It changes a CNAME and sees fresh connections reach the successor. Meanwhile, a reader has an HTTP/2 connection to another site at the former provider. That provider still holds a certificate for the publisher's site and sends it over the established connection. If the client treats the proof as enough authority, a later request for the moved site can follow the old connection. This is a protocol test drawn from the draft's stated risk.

The attraction is obvious. HTTP/2 and HTTP/3 can reuse a connection for multiple origins when the server is authoritative for each. A single TLS handshake certificate can cover many names, but an operator may prefer separate certificates for different customers and separate renewal or revocation. The draft offers a way to keep those certificates separate while sharing transport. The policy question arrives after the optimization: which evidence says the second origin still belongs on this connection today?

One connection can gain a second identity

The proposal starts with explicit consent in protocol settings. Both client and server send SETTINGS_HTTP_SERVER_CERT_AUTH with value 1; otherwise they cannot use this certificate exchange. The server can then send a SERVER_CERTIFICATE frame at any time. On HTTP/2 it belongs on stream 0; on HTTP/3 it belongs on the control stream. The frame carries an exported authenticator. RFC 9261 supplies the session-derived proof that the sender holds the private key corresponding to the additional certificate. A bare certificate file would not establish that possession on this connection.

The client validates the authenticator and then checks the certificate for the intended origin. Those checks fail in different ways. An invalid authenticator is a connection error under the draft. An expired, revoked or otherwise unacceptable certificate is a certificate decision; the draft recommends a new connection to an authoritative server rather than treating the whole connection as a protocol failure. That distinction matters in an outage report: the transport can remain healthy while the extra origin is refused.

The security section sharpens the stakes. With a compromised secondary certificate and key, a hostile server need only draw the client to some HTTPS site it controls before presenting the stolen credential for another origin. The draft says clients should consult DNS for a secondary hostname when they would have done so for that name in the primary handshake. If they skip DNS, another authority signal such as an ORIGIN frame can strengthen the decision. The certificate proves key possession; current routing and authority require their own checks.

Moving DNS does not close an old connection

The CNAME case is less dramatic than a stolen key and more likely to be missed during routine operations. A site owner changes the DNS alias to leave a provider. New connections take the new route. The former provider may still receive connections for other sites and may still have the departing site's secondary certificate configured. Section 7.3 says it could continue claiming that site on those shared connections. The draft calls this behavior proper under the old provider's configuration while acknowledging that it may defeat the owner's intent.

The proposed protocol has no built-in cure for this persistence; it asks providers to warn customers before using the feature.

That makes exit a sequence, not a DNS edit. The owner needs to know which provider retains the private key, which HTTP connections can carry the certificate, when certificate issuance or revocation changes, and whether clients recheck the second origin's authority. The former provider needs a deletion and deactivation path for the secondary credential. A test must observe the new DNS answer and the requests still arriving over old shared connections; either record alone misses half the story.

The draft also forbids a client from treating a previous secondary certificate as validated after TLS session resumption. A server may present it again, forcing a fresh decision. During one connection, the set of accepted certificates can change while a request is in flight, so the client may have to reevaluate which origin the connection can serve. That is a state-management burden at precisely the layer where operators hoped to save connection overhead.

The official sources report no deployment count or measured cutover failure. A controlled provider move with DNS traces, open-connection inventory, certificate frames and request destinations would establish whether a client crosses this boundary. Until then, the operational lesson of the proposal is concrete: a domain owner leaving a provider must retire its secondary certificate path as deliberately as its DNS alias. The key in the old building can remain useful after the sign on the street changes.

HTTP secondary certificate draft · RFC 9261 · RFC 9113 · RFC 9114 · RFC 8336