Summary

  • RFC 9525 requires the client to construct acceptable reference identifiers independently of the identifiers a server presents in its certificate.
  • Certificate matching can validate that prior identity; it cannot repair corrupt input, promote a DNS intermediate or alternate endpoint into the origin, or prove every other certificate and application property.

Authentication begins before the certificate arrives

Most descriptions of TLS identity start with a certificate on the screen. RFC 9525 starts one step earlier. A server offers presented identifiers in its leaf certificate. The client compares them with reference identifiers it already expects. A match succeeds only between those two deliberately different sets.

The distinction prevents a circular test. If the client learned what name to trust from the very certificate being evaluated, almost any certificate could define its own passing condition. The specification therefore says the acceptable reference list must be constructed independently of the server's identifiers.

A reference identifier is not simply a hostname-shaped string. It comes from a source domain and may include an application service type. Depending on the protocol, the client can work with a DNS-ID, IP-ID, SRV-ID or URI-ID. Choosing among those types and assigning local priority to them is part of application policy.

Once a presented identifier matches, the matched reference identifier becomes the validated service identity. The direction matters: the certificate satisfies an expectation; it does not create the expectation.

Intent has provenance

Where does the source domain come from? RFC 9525 names several ordinary routes: a URI typed by a person, account configuration, a hyperlink or another application input that yields a domain and perhaps a service type. Each route carries different authority and different failure modes.

A manually configured mail host might express an administrator's intended service. A link inside an authenticated page can inherit a secure context. A link supplied by a malicious sender can lead to an unexpected application service. TLS might authenticate that unexpected service accurately because the comparison began with the attacker's input.

This is not a weakness in string matching. It is a boundary around what matching can know. The certificate has no independent record of the user's earlier intent, the administrator's approved account setting or the trustworthiness of the page that supplied the URL. It can answer “does the presented identity match this reference?” but cannot answer “was this the right reference to construct?”

Protocols that rely on RFC 9525 must therefore own the derivation rule. They can restrict URI schemes, define a one-to-one mapping from scheme to service type, require secure input context and specify which identifier types are acceptable. Leaving the rule implicit makes the most important authentication input unauditable.

Discovery names are not free replacements

After the client has an intended service name, DNS and other discovery mechanisms may lead it through several names and addresses. Some look exactly like plausible certificate identities. RFC 9525 warns that intermediate values are not reference identifiers merely because resolution produced them.

That rule keeps a resolver answer from silently rewriting the authentication target. An application may define an authenticated procedure that promotes an intermediate value, but in the ordinary case the original reference remains. Connection routing and identity validation can use different names without contradiction.

The separation is especially important for outsourcing and content delivery. A service can direct traffic to infrastructure operated under another domain. The endpoint needs a certificate capable of speaking for the original service identity under the applicable rules. Matching only the infrastructure target would prove a different proposition.

SVCB changes the road, not the destination's identity

RFC 9460 makes this explicit for SVCB and HTTPS records. AliasMode can delegate operational control, and ServiceMode can describe alternative endpoints plus connection parameters. Yet these forms do not alter the origin or its validation authority. TLS clients continue to validate the certificate for the original service name.

For HTTPS, the same boundary reaches SNI and the HTTP authority: they indicate the origin, not the SVCB TargetName. The TargetName helps establish a connection. It is not automatically the identity the user or application intended to authenticate.

This is a useful model beyond one DNS record type. A route can change without transferring semantic authority. Load balancing, failover, an alternate port or a provider hostname may alter where packets go while leaving the service identity stable. Operations needs evidence for both facts rather than one ambiguous “host” field.

The match is typed, not approximate

RFC 9525 does not reduce matching to a loose visual resemblance. DNS labels are compared under defined rules. IP identifiers require exact octet equality. SRV-ID and URI-ID comparisons can include an application service type, and a client must not splice the service part from one reference identifier onto the domain of another.

Wildcard handling is similarly narrow. When a protocol allows it, the wildcard is one complete left-most label and matches only one label. The rule improves interoperability and limits some abuse; it does not assert that every matching host is well run or controlled by the same trustworthy operator.

The possibility of multiple acceptable reference identifiers is itself policy. A more permissive client might accept several identifier types. Each additional acceptable form enlarges the set of certificates and certification-authority constraints that must be reasoned about. Compatibility is not a free security property.

A successful name check is not the whole certificate decision

RFC 9525 confines itself to identity forms in the leaf server certificate. It does not create or validate the certification path. Expiration, revocation, trust anchors, key usage and other certificate checks remain necessary. A name match can be exact while another part of validation fails.

Nor does the match attest to everything behind the name. It does not authenticate a URI path or query, grant access to a resource, certify server behavior or prove an application transaction succeeded. TLS 1.3 itself is application-protocol independent; higher layers still decide how to initiate TLS and interpret the authentication material they receive.

Certificates containing many names introduce another boundary. RFC 9525 notes that compromise of any server able to use such a certificate can affect the other names in the set. A successful match proves membership in the certificate's scope, not that every holder of the corresponding key has the same operational strength.

Fail closed without forgetting the input

When no presented identifier matches, automated clients should terminate with a bad-certificate error, and user-driven clients should normally do the same after explaining the mismatch. The specification treats an immediate user override with strong caution. That is sound failure behavior, but it does not remove the need to preserve how the reference was obtained.

An incident record should be able to reconstruct the source input, derived source domain, service type, complete reference set, discovery chain, actual connection endpoint, presented identifiers, exact match and the remaining certificate-validation outcome. Without that sequence, a successful comparison can conceal whether the wrong name was chosen correctly.

Sources