· Development

TLS Certificate Name Mismatch: What a Client Actually Compares (RFC 9525)

What a TLS client compares with the certificate's SAN under RFC 9525: reference identifiers, DNS-ID and IP-ID, the Common Name ban, wildcards, mismatch handling, and a checklist.

TLScertificatesRFC 9525PKIsecurity

When a browser or HTTP client drops a connection with a “certificate name mismatch” error, it has compared two things. One is the name or address the client meant to reach. The other is the set of names written into the server’s certificate. The current IETF document that defines this comparison is RFC 9525, “Service Identity in TLS”. It was published in November 2023 as a Proposed Standard and obsoletes RFC 6125.

RFC 9525 is written to apply to TLS, DTLS, and protocols such as QUIC that use the TLS handshake (§1.4.1). This post focuses on the cases you are most likely to hit with HTTPS.

Reference identifiers and presented identifiers

RFC 9525 names the two sides of the comparison (§1.5):

  • Reference identifier: the identifier the client expects. It is built from the source domain, which comes from client-side input such as a URL the user typed, prior configuration, or a link in a web page, plus an application service type when relevant.
  • Presented identifier: an identifier the server presents inside its PKIX certificate. A certificate can carry more than one.

The central rule is in §6.1.1. The client MUST construct a list of acceptable reference identifiers, and MUST do so independently of the identifiers the server presents. If a client filled its list by reading names out of the certificate, the check would prove nothing.

DNS resolution may pass through other domain names on the way to an address. Unless an application defines a way to authenticate those intermediate names, they are not reference identifiers and MUST NOT be treated as such (§6.1.1). The RFC notes that this keeps DNS and DNS resolution out of the attack surface. The resolution process itself is out of scope for RFC 9525 (§1.4.2); for how it works, see DNS resolution.

The procedure runs like this (§6, §6.2):

  1. The client builds its list of reference identifiers from the source domain (and service type, if any).
  2. The server presents its identifiers in a certificate.
  3. The client checks each reference identifier against the presented identifiers. A single match is a success, and the client SHOULD stop searching at that point. If the list is exhausted with no match, the search fails.

On success, the client MUST use the matched reference identifier as the validated identity of the service (§6.6).

The identifiers used for HTTPS: DNS-ID and IP-ID

Every identifier type in RFC 9525 lives in the certificate’s subjectAltName (SAN) extension (§1.5):

Identifier SAN entry type Used when
DNS-ID dNSName Connecting by domain name
IP-ID iPAddress Connecting directly to an IP address
SRV-ID otherName (SRVName) Protocols that locate services via DNS SRV
URI-ID uniformResourceIdentifier Protocols that specify URIs in certificates

SRV-ID and URI-ID bind “which service” (for example IMAP or SIP) in addition to “which host”. The RFC gives XMPP and SIP as examples (§4.1). It also states that HTTP does not specify the use of URIs in server certificates (§4.2), so for ordinary HTTPS, DNS-ID and IP-ID are what matter.

The RFC’s own examples (§6.1.2):

  • A browser connecting to https://www.bigcompany.example/ has a single reference identifier, the DNS-ID www.bigcompany.example. A presented DNS-ID of web.bigcompany.example would be rejected.
  • Connecting to https://192.0.2.107/ gives a single IP-ID reference identifier, 192.0.2.107. Connecting to https://[2001:db8::abcd] gives the IP-ID 2001:db8::abcd.

Common Name is not used

Under RFC 9525, the Common Name (CN) RDN in the certificate subject MUST NOT be used to identify a service (§2). It is not strongly typed, being essentially free-form text, so its interpretation is ambiguous. For the same reason, other RDNs in the subjectName MUST NOT be used either.

RFC 6125 called this a CN-ID. The list of changes in RFC 9525 (Appendix A) says the server identity can only be expressed in the subjectAltName extension and that using the commonName RDN is no longer valid. The summary in §1.3 puts it as: do not include or check strings that look like domain names in the subject’s Common Name.

In practical terms (our reading of these rules): a certificate that carries a hostname only in the CN, with no matching DNS-ID in the SAN, gives an RFC 9525 client nothing to match on.

DNS name matching and internationalized names

If the reference domain is not an internationalized domain name, matching MUST compare the domain name labels using a case-insensitive ASCII comparison (§6.3). For example, WWW.BigCompany.Example is lower-cased to www.bigcompany.example for comparison. Every label must match, except as allowed by the wildcard rule below.

For internationalized names:

  • A DNS-ID may not contain characters outside US-ASCII, and internationalized labels are represented as A-labels (the ASCII form beginning with xn--) (§2).
  • If the reference identifier contains U-labels (the Unicode form), the client MUST convert them to A-labels before comparing, and A-labels MUST be compared as case-insensitive ASCII (§6.3).
  • Matching happens on A-labels only. The RFC draws a line here: confusion caused by visually similar characters is a matter for application protocols and user interfaces, not certificate matching (§7.3).

Conversion between A-labels and U-labels is covered in Punycode and internationalized domain names.

One more scope note: the source domain in RFC 9525 is an FQDN. Names that are not fully qualified are out of scope and may result in unexpected or undefined behavior (§1.5).

Wildcard rules

RFC 9525 treats wildcard support as the default in certificates (§1.3), although a protocol specification may disallow wildcards (§3). Where wildcards are supported, a * in a presented identifier must meet both conditions (§6.3):

  1. There is only one wildcard character.
  2. The wildcard character appears only as the complete content of the left-most label.

If either condition fails, the presented identifier is invalid and MUST be ignored. A wildcard also matches only one label of the reference identifier. The RFC points out that this differs from DNS wildcards, which can match more than one label.

The example in the RFC text is that *.bigcompany.example is allowed while *.*.bigcompany.example is not (§7.1). The other rows below are examples we derived by applying the rules.

DNS-ID in certificate Name connected to Result (examples derived from the rules)
*.bigcompany.example www.bigcompany.example Match: * covers one label (www)
*.bigcompany.example a.b.bigcompany.example No match: a wildcard does not cover two labels
*.bigcompany.example bigcompany.example No match: there is no label for * to cover
w*.bigcompany.example www.bigcompany.example Ignored: * is not the whole label
www.*.example www.bigcompany.example Ignored: * is not in the left-most label
*.*.bigcompany.example a.b.bigcompany.example Ignored: two wildcards (RFC example)

Preventing wildcards that cover a public suffix, such as *.co.uk or *.com, is outside the scope of RFC 9525 (§7.1). The RFC also notes that a wildcard certificate vouches for every single-label hostname in its domain, which risks vouching for rogue or buggy hosts.

Connecting directly to an IP address

If the URL contains an IP address, the reference identifier is an IP-ID (§6.1.1). The rules are short and strict:

  • An IP-ID reference identifier MUST exactly match the value of an iPAddress entry in the SAN, with no partial (for example, network-level) matching (§6.2).
  • The comparison is octet for octet between the bytes of the reference identity and the bytes in the iPAddress entry (§6.4). IPv4 is 4 octets and IPv6 is 16, and a textual representation may need converting to obtain that value (§2).
  • An IP address obtained from a DNS query is indirect, and the use of indirect IP-IDs is out of scope for RFC 9525 (§2).

RFC 9525 does not mention reverse DNS lookups by name. What it does say is that when the reference identifier is an IP address, it is an IP-ID (§6.1.1), and that a DNS-ID reference identifier is built from an FQDN contained in or securely derived from the inputs, or explicitly associated with the source domain by user configuration. So, in our reading, connecting to an IP and then checking a hostname obtained by lookup against the certificate’s DNS-IDs is not a procedure RFC 9525 defines.

There is an operational catch with IP connections. The TLS SNI extension only carries domain names, so a client whose reference identifier is an IP-ID has no way to tell the server about it. A server that wants to present an IP-ID therefore needs to present that certificate on connections made without SNI (§7.4).

Also, the textual form of an IPv4 address is a valid DNS name (§3). If one part of a system classifies a value as an IP address and another treats it as an FQDN, security rules can fall between the two, so the RFC calls for consistent classification (§7.4). §3 gives the example of testing first whether the identifier is a valid IPv4 address, as the URI specification does.

What happens on a mismatch

When no presented identifier matches, the expected behavior depends on the kind of client (§6.6). Keeping the requirement levels as written:

Automated applications

  • SHOULD terminate the communication attempt with a bad certificate error and log the error appropriately.
  • MAY offer a configuration setting to disable this behavior, but MUST NOT disable it by default.

Clients directly controlled by a human user

  • SHOULD inform the user of the identity mismatch and automatically terminate the attempt with a bad certificate error.
  • MAY give advanced users the option to proceed despite the mismatch. The RFC says this needs extreme caution, and gives the example of first encouraging the user to stop and, if they proceed anyway, making them view the entire certification path.
  • MAY let the user accept the presented certificate as valid for subsequent connections. Such ad hoc “pinning” SHOULD NOT restrict future connections to just the pinned certificate, and a policy that statically enforces a given certificate for a given peer SHOULD be available only as prior configuration, not as a just-in-time override for a failed connection.

In short, terminating the connection is a SHOULD-level default in RFC 9525, while not disabling the check by default is a MUST NOT for automated clients.

Implementation and configuration checklist

These items restate RFC 9525’s rules as checks. For how a specific library or tool exposes them, see its official documentation.

When implementing or configuring a client

  • Build reference identifiers from client-side input such as the URL or configuration, never from the certificate (§6.1.1).
  • Do not treat intermediate names seen during DNS resolution as reference identifiers (§6.1.1).
  • Do not fall back to the CN for name checks (§2).
  • Compare DNS names label by label as case-insensitive ASCII; convert IDNs to A-labels first (§6.3).
  • Accept a wildcard only if it is the sole * and the entire left-most label, and let it match exactly one label (§6.3).
  • For IP connections, compare octet for octet against SAN iPAddress entries (§6.2, §6.4).
  • Classify IP addresses and domain names consistently across the system (§3, §7.4).
  • For automated clients, fail closed and log on mismatch by default. If there is an option to disable the check, it starts enabled (§6.6).
  • Confirm that path, expiration, and revocation checks run separately from the name check (§1.2, §6).

When requesting a certificate or configuring a server

  • Make sure the hostnames clients use appear as SAN dNSName entries, not only in the CN (§2, Appendix A).
  • Do not assume *.bigcompany.example covers bigcompany.example or names several levels down (§6.3; derived examples in the table above).
  • Put internationalized names in A-label form (§2).
  • If clients connect by IP address, include that address as an iPAddress entry and make sure the certificate is served on connections without SNI (§4.2, §7.4).
  • Include only as many names as needed to identify the service. The weakest server among those named determines the strength of the whole set (§5, §7.5).

What a name match does not guarantee

A successful name comparison does not by itself make a connection secure. RFC 9525 is explicit about its limits:

  • It does not supersede the issuance and validation rules of PKIX (RFC 5280). Certificate syntax, extensions such as name constraints or extended key usage, and certification path handling remain PKIX matters (§1.2).
  • It covers only names in the leaf (end entity) server certificate. It neither builds nor checks the validity of the chain, and applications need to verify the entire certification path for proper authentication (§1.2).
  • Checks such as expiration and revocation are also needed, but they are not service identity verification, so how to do them is out of scope (§6).
  • It assumes that a client trusting a CA trusts all certificates that CA issues. Extra checks for rogue servers or buggy applications are the job of the application protocol or client (§7.7).
  • If the inputs themselves are bad, for example a user clicked a phishing link, name verification can succeed and the client still ends up talking to an unexpected service (§6.1.1).
  • The RFC notes that the wildcard-related attack it cites relies on hijacking an initial cleartext HTTP connection (§7.1). Making that first connection use HTTPS is a separate problem from name matching; see HSTS.

References

The following official sources were checked on 2026-10-18.

Back to the blog