LEARN. PRACTICE. GROW.Concept and mechanism
The client needs to establish that presented identity matches the intended service. Under RFC 9525 guidance, DNS names are checked in subjectAltName and Common Name is not used to identify a service. A CNAME or shared address does not add identities to a certificate. For a wildcard such as *.example.test, only one leftmost label is covered: api.example.test can match, but example.test and a.api.example.test cannot. These are TLS identity rules, distinct from DNS wildcard expansion. Older implementations can behave differently; this course states the modern reference used by exercises without assuming every client implements it completely.
Guided application
SNI helps the server select a TLS context; it is not name verification itself. In OpenSSL, -servername and -verify_hostname serve those distinct functions. Also compare notBefore, notAfter, and the effective clock. A not-yet-valid error can reflect an incorrect clock or issuance whose interval has not started; establish which before correcting. The x509 -checkend 86400 option answers a limited question about expiry within the next 24 hours. It does not independently verify chain, identity, or the certificate loaded at the endpoint. In an alias-change exercise, the chain remains valid but the new name requires issuance and activation of material covering it.
A legacy.example.test certificate does not automatically cover api.example.test because a CNAME exists.
Common pitfalls
SNI as verification; CN as modern fallback; wildcard as every subdomain; checkend as a complete audit.
Related topics: Keys, certificates, and trust · Negotiation, mTLS, and the application · Renewal and served certificates
Establish the name the client expects and validity at the observed instant.
Reference: Service Identity in TLS · DR TLS/certificates 2026-09; selected TLS 1.2/1.3, RFC 9525 identity and OpenSSL 3.5 diagnostics