Certificate hostnames and the requested service identity

Certificate hostname validation compares the requested service identity with appropriately typed certificate names, keeping wildcard scope and direct IP identities distinct.

A client requests https://media.example.net/. The certificate must present an appropriate identity for media.example.net under the client’s service-validation rules.

The address obtained from DNS can change without changing that requested DNS name.

Match the requested name to typed certificate evidence

Use this original reduced descriptor:

{
  "dnsNames": ["*.example.net"],
  "ipAddresses": []
}

The DNS identity is a wildcard for one leftmost label. Under the stated RFC 9525 rule:

Requested host Match to this DNS wildcard?
media.example.net Yes
tv.example.net Yes
example.net No
room.media.example.net No

The wildcard is the complete leftmost label and matches one label. It is not an arbitrary substring pattern.

An IP-literal URL asks for an IP identity

Now request https://192.168.50.20/. The original certificate projection has no IP address identity, so its DNS wildcard does not satisfy that direct IP request.

Even if media.example.net resolves to that IP, the two URL forms retain different reference identities. Reverse lookup of an address should not silently replace the name the client actually requested.

Likewise, equivalent IPv6 spellings identify the same address bits when checking an IP identity. DNS wildcard matching is another operation.

Current RFC 9525 uses appropriately typed presented identities and prohibits using free-form Common Name text as the service identifier. A familiar subject label does not replace the relevant SAN evidence.

SNI helps select a certificate before the HTTP request

A client can send the intended DNS name in the TLS handshake’s server-name indication. A shared TLS endpoint uses that context to choose a certificate/virtual service.

The later HTTP Host information is application data inside the established connection. It cannot retroactively make an already rejected certificate handshake succeed.

A proxy’s default certificate or missing name selection can therefore produce a mismatch even when its HTTP routing would have selected the correct application later.

Keep identity through local and remote DNS paths

With split DNS, media.example.net can resolve to an inside or outside endpoint. Both need certificate evidence appropriate to the unchanged hostname.

An internal address answer does not turn the requested name into an IP-literal identity. A different TLS termination endpoint can, however, serve another certificate.

See Also

References