Hostname Verification

Hostname verification checks that the hostname a client connects to matches an identity listed in the server's TLS certificate. This helps prevent an attacker from presenting a valid certificate issued for a different host.

During a TLS connection, a server presents a certificate containing one or more identities, normally in the Subject Alternative Name (SAN) extension. The client compares the hostname it intended to contact with those identities.

For example, if a Java application connects to `api.example.com`, a certificate valid for `api.example.com` can satisfy hostname verification. A certificate issued for `other.example.com` should not satisfy that check merely because it is signed by a trusted certificate authority.

Hostname verification is separate from certificate-chain validation. Chain validation establishes that the certificate is trusted and valid according to PKI rules, while hostname verification establishes that the certificate identifies the particular endpoint being contacted. A secure TLS client generally needs both checks.

Wildcards can match hostnames according to the client's hostname-matching rules; for example, `*.example.com` can generally cover `api.example.com`, but it is not equivalent to an unrestricted match for every possible domain. Java HTTPS clients normally perform endpoint identification when appropriately configured, while custom TLS code can accidentally omit it.

Key points

• Compare the requested hostname with certificate identities, primarily from SAN.
• A trusted CA does not make a certificate valid for every hostname.
• Hostname verification complements certificate-chain validation.
• Wildcard matching follows hostname rules and is not an unrestricted domain match.
• Java HTTPS clients should retain endpoint identification rather than disabling it.

Interview questions

What security problem can occur when hostname verification is disabled?

Disabling hostname verification can allow a client to accept a certificate that is trusted but identifies a different hostname. An attacker who can successfully obtain or otherwise present such a trusted certificate may then be able to impersonate the intended endpoint. This undermines an important part of TLS server authentication. Certificate-chain validation alone does not restore the missing hostname check.

What is hostname verification in TLS?

Hostname verification checks whether the hostname requested by the client is represented by the server's certificate. The identity is normally taken from the certificate's Subject Alternative Name entries. This prevents a certificate that is valid for one domain from being accepted simply because it was issued by a trusted CA. It is an important part of authenticating the intended TLS endpoint.

Why is hostname verification needed if the certificate is signed by a trusted CA?

A trusted CA establishes that the certificate chains to a trust anchor and passes relevant certificate checks, but it does not mean the certificate belongs to every server. A CA can issue certificates for many different domains. Hostname verification narrows the authentication result to the specific hostname the client intended to contact. Without it, a trusted certificate for another domain could potentially be accepted.

What is the difference between the Common Name and Subject Alternative Name for hostname verification?

The Subject Alternative Name extension is the modern location for DNS identities in X.509 certificates. The Common Name is a legacy certificate field and should not generally be treated as the primary source for modern hostname matching. A certificate can contain multiple SAN entries, allowing it to identify several DNS names. Implementations should follow the applicable TLS and certificate hostname-matching rules rather than inventing their own fallback behavior.

How should a Java backend engineer approach hostname-verification failures?

First determine the exact hostname the application is using and inspect the certificate presented by the endpoint. Check its SAN DNS names, certificate chain, validity period, and the trust configuration used by the Java process. If the certificate identifies a different hostname, fix the endpoint or certificate configuration rather than disabling verification. If the application uses custom TLS code, verify that endpoint identification is explicitly configured where required.