TLS can encrypt traffic using keys negotiated with almost any peer. The client still needs to know whether that peer is the service it intended to reach.

An X.509 certificate helps answer that question by binding an identity to a public key. A certification authority signs that binding, and the client evaluates it under a local trust policy.

The word validation hides several independent decisions:

A certificate can pass four checks and fail the fifth. This is why “the certificate is signed” and “the certificate is valid for this connection” are very different claims.

This chapter develops a practical mental model of the complete validation process and the failures backend engineers encounter in production.

An X.509 certificate is not a secret. Servers send certificates to clients, and anyone can inspect them.

A typical version 3 certificate contains:

The subject public key information contains a public key and identifies its algorithm. The matching private key stays with the certificate holder and is not part of the certificate.

The issuer's signature covers the certificate's to-be-signed portion. It lets a verifier detect changes and confirm that the issuer's private key signed those fields. If an attacker changes the public key, identity, validity period, or a protected extension, the original signature no longer verifies.

The serial number identifies a certificate within an issuer's namespace. Two different certification authorities can use the same serial number, so a serial number alone is not a globally unique certificate identifier.

Important Extensions

Most of the rules that make a certificate safe for a particular use live in extensions.

Subject Alternative Name (SAN) carries identities such as DNS names and IP addresses.

Basic Constraints says whether a certificate represents a certification authority and can limit the number of intermediate CAs beneath it.

Key Usage restricts the public key to operations such as digital signatures or certificate signing.

Extended Key Usage (EKU) restricts the certificate to purposes such as TLS server authentication or TLS client authentication.

Authority Key Identifier and Subject Key Identifier help a path builder identify issuer and subject keys.

Authority Information Access (AIA) can provide locations for issuer certificates and OCSP services.

CRL Distribution Points can identify locations from which a verifier obtains certificate revocation lists.

Name Constraints can restrict the namespaces that a CA below a point in the path may certify.

Each extension is marked critical or non-critical. A verifier that does not understand a critical extension must reject the certificate. Ignoring an unknown critical restriction could authorize a use that the issuer explicitly intended to prevent.

Most public TLS deployments use a hierarchy rather than having one root key sign every server certificate.

The certificates play different roles.

The leaf certificate, also called an end-entity certificate, identifies the server and contains its public key. Its private key is used by the server during TLS authentication.

An intermediate CA certificate permits its holder to issue other certificates within its constraints. Public CAs generally keep root keys offline and use intermediates for routine issuance. If one intermediate needs to be retired, the root can remain trusted.

A root CA is accepted because its public key was placed in a client's trust configuration through a separate, trusted process. Roots are commonly distributed by an operating-system, browser, runtime, device administrator, or application.

A root certificate is often self-signed, but self-signing does not create trust. Anyone can generate a self-signed certificate. The critical fact is that the client already treats a particular root public key as a trust anchor.

What the Server Sends

During a typical TLS handshake, the server sends:

The server normally omits the root. The client must already possess an acceptable trust anchor; receiving another copy from an untrusted network would not make that root trusted.

The server's list is input to validation, not proof of a valid path. A misconfigured server can send a missing, unrelated, expired, or incorrectly ordered intermediate. A robust client may reorder certificates or find another candidate locally, but a server should provide the leaf first and all required intermediates.

The terms are often used together, but they describe separate jobs.

Path building searches for a sequence from the leaf certificate to a locally trusted anchor.

Path validation checks whether one candidate sequence satisfies the cryptographic and policy rules.

Consider a server that sends only this:

The leaf's issuer field says Example Issuing CA 7, but the corresponding intermediate is not in the message. One client may have cached that intermediate or download it from an AIA location and succeed. Another client may not perform issuer fetching and fail with “unable to get local issuer certificate.”

The certificate did not change. The clients had different path-building inputs and behavior.

Path building can also find more than one candidate:

Cross-signing can place the same CA key into certificates issued under different roots. A client chooses a path compatible with its trust store and policy. This explains how the same server chain can validate on newer devices but fail on older ones, or the reverse.

The path supplied by a diagnostic tool is therefore worth inspecting carefully. The certificates transmitted by the server, the path built by the client, and the trust anchor selected by the client are related but not necessarily identical lists.

A useful operational model is a pipeline. Failure at any required stage rejects the certificate for the connection.

Real implementations can combine or reorder some work, try several paths, and apply additional platform policies. The outcome still depends on all of these questions.

1. Establish the Reference Identity

Before examining a certificate, the application determines what identity it expects.

For:

the normal DNS reference identity is:

It does not become the connected IP address after DNS resolution. It also does not become a DNS canonical name merely because resolution followed a CNAME. The client authenticates the service name it intended to contact.

An HTTP redirect to another hostname creates a new reference identity for a new connection. The first server's certificate cannot authorize the redirected hostname unless that hostname is separately present and valid for the connection that uses it.

2. Parse Certificates and Critical Extensions

The client decodes each certificate and validates its structural requirements. Malformed lengths, invalid encodings, inconsistent algorithm identifiers, or unsupported critical extensions can make a certificate unusable before higher-level checks begin.

Non-critical does not mean irrelevant. It means an implementation may ignore the extension if it does not recognize it. If the implementation does recognize it and it affects validation, it processes the extension normally.

3. Build a Path to a Trust Anchor

The client looks for issuer certificates that connect the leaf to one of its configured anchors.

At a simplified level:

Names alone are not sufficient. The path builder also uses signatures, key identifiers, locally cached certificates, and sometimes AIA issuer locations to distinguish candidates.

If no candidate reaches a trusted anchor, validation fails even when every available certificate is correctly signed. A chain ending in an unknown private root is still untrusted to a client that was never configured with that root.

4. Verify Every Certificate Signature

The issuer public key verifies the child certificate's signature:

A successful signature says the signed bytes came from the holder of the corresponding issuer private key and were not modified. It does not yet say that the issuer was allowed to issue that certificate, that the name matches, or that the certificate is currently valid.

The trust anchor is an input to the validation algorithm. When represented as a self-signed root certificate, it is not an ordinary member of the prospective path under the base X.509 model. Platforms can apply additional rules to anchors, but the root's self-signature is not what establishes trust.

5. Check Validity Periods

Every certificate processed as part of the prospective path—the leaf and intermediates—must satisfy:

The endpoints are inclusive. A leaf can be invalid because it has expired or because its notBefore time is still in the future. Intermediates also have validity periods; replacing only the leaf cannot repair an expired intermediate. The trust anchor is separately configured input under the base X.509 model, although a platform can impose additional lifecycle rules on its anchors.

The verifier uses its own notion of the current time. A server clock is relevant to certificate automation, but it does not decide whether a client's validation succeeds. Incorrect client or container clocks can make a healthy certificate appear expired or not yet valid.

6. Enforce CA and Path Constraints

A valid signature from an intermediate is insufficient unless that intermediate is authorized to act as a CA.

For an issuing CA certificate, validation normally requires:

If Basic Constraints says CA = FALSE, the public key cannot be used to validate child certificate signatures.

The optional pathLenConstraint limits how many non-self-issued intermediate CA certificates may follow that CA in a valid path. A value of zero permits the CA to issue leaf certificates but not another ordinary intermediate below it.

Name constraints can restrict what an intermediate is allowed to certify. An enterprise CA might be constrained to identities under:

A correctly signed leaf for public.example would still fail through that constrained path.

Certificate policies and platform-specific restrictions can narrow acceptable paths further. Validation asks not only “Who signed this?” but also “Was every issuer authorized to make this statement under this path?”

7. Enforce Key Usage and Extended Key Usage

The leaf public key must be permitted for the operation performed during TLS.

For a typical TLS 1.3 server certificate, relevant values include:

serverAuth and clientAuth are different extended purposes. A certificate restricted to client authentication should not be accepted as a server certificate merely because it has a valid CA signature.

If both Key Usage and Extended Key Usage appear, the intended operation must be compatible with both. One extension does not override a conflicting restriction in the other.

Certificate signature algorithms, TLS handshake signature algorithms, key-exchange groups, and TLS 1.3 cipher suites are separate choices. For example, the CA might sign a certificate with one algorithm while the server uses the leaf private key with another permitted signature scheme during CertificateVerify.

8. Match the Service Identity

After obtaining a valid leaf public key, the client must establish that the certificate represents the intended service. Path validation without identity matching answers only that a trusted CA certified some identity.

Modern TLS service identity is carried in subjectAltName. For a DNS service, the client compares its reference DNS name with dNSName entries. The subject's Common Name, or CN, is not a valid substitute for a missing SAN under current service-identity rules.

For example:

If the client connects by IP address and uses that IP address as the reference identity, the certificate needs a matching iPAddress SAN:

A dNSName containing the text 192.0.2.25 is not the same identity type.

9. Apply Certificate Status Policy

The client may use locally available status data, a certificate revocation list, an OCSP response, a server-stapled response, or a platform-specific mechanism to determine whether a certificate was revoked.

The exact behavior is not universal. Some clients fail when current status cannot be obtained, while others continue unless they receive a definitive revoked result. Browser and operating-system vendors can supplement standards-based mechanisms with their own distribution and policy.

Known revocation is not the same as temporary inability to reach a status service. A sound diagnosis records which status mechanism was attempted and whether the result was revoked, unknown, stale, absent, or unreachable.

10. Verify Possession in the TLS Handshake

Certificate validation establishes that the public key is acceptable for the intended service. The TLS handshake must additionally prove that the current peer possesses the matching private key.

In TLS 1.3, the server's CertificateVerify signature binds that proof to the handshake transcript. A valid certificate copied from a public server is useless to an impostor that does not possess the corresponding private key.

Only after certificate validation and the TLS transcript checks succeed should the client treat the channel as authenticated.

DNS identity matching compares labels using case-insensitive ASCII rules. Internationalized names are converted to their ASCII A-label form before comparison.

With exact SAN entries:

If an application supports wildcard certificates, the wildcard must be the complete left-most label and can match exactly one label:

Values such as these are not valid wildcard identities under current rules:

A wildcard certificate does not follow DNS wildcard resolution semantics. It is a constrained certificate-name matching rule.

The port is not part of a DNS-ID. A certificate for api.example.com can identify that DNS service name when contacted on different ports, subject to the application protocol's own rules. The URL path and query are also not certificate identities.

SNI Is Selection, Not Validation

Server Name Indication and hostname verification solve different problems.

The client sends SNI so a multi-tenant server can choose a certificate:

The client then independently checks whether the returned certificate is valid for its reference identity:

Sending correct SNI does not force the server to return a correct certificate. Conversely, omitting SNI can cause a server to return its default certificate, which then fails hostname verification.

A certificate can need invalidation before notAfter. Its private key might be compromised, the identity might no longer be controlled by the subject, or the CA might have issued it incorrectly.

Revocation mechanisms distribute that change in status.

Certificate Revocation Lists

A Certificate Revocation List (CRL) is a CA-signed, time-bounded list of revoked certificate serial numbers.

A verifier needs to:

CRLs can be cached and checked without sending a separate request for every connection. Large lists, download failures, update intervals, and distribution-point configuration can make them operationally awkward.

Absence from an old or irrelevant CRL is not proof of current good status.

Online Certificate Status Protocol

OCSP lets a client request status for a specific certificate from an authorized responder. A signed response can report:

good minimally means that the responder does not report that serial number as revoked for the relevant issuer. It does not replace checks for certificate signatures, time validity, purpose, or identity.

OCSP responses include freshness information. A response whose update time is in the future or whose next-update time has passed can be unreliable.

Direct client OCSP requests add latency and reveal to the responder which certificate a client is checking. If the responder is unreachable, the client must choose between availability and strict status enforcement.

OCSP Stapling

With OCSP stapling, the TLS server obtains a signed OCSP response and includes it in the handshake. The client validates that response without making its own request to the CA's responder.

Stapling improves client privacy and removes a client-to-responder round trip. The server must refresh the response before it becomes stale.

A certificate can contain the TLS Feature extension commonly called Must-Staple. A supporting client expects the required status feature and rejects a connection when acceptable stapled status is missing. Deploying such a certificate before the server can reliably staple fresh responses creates an outage.

Revocation behavior varies enough that engineers should test the actual clients in scope rather than infer policy from one browser or one OpenSSL invocation.

Public web PKI deployments can also require evidence that a certificate was submitted to recognized Certificate Transparency logs. A log returns a signed certificate timestamp, or SCT, and records certificates in an append-only structure designed for public auditing.

Certificate Transparency helps domain owners and ecosystem monitors discover unexpected or misissued public certificates. SCTs can be carried in the certificate, in a stapled OCSP response, or through TLS.

CT is not a replacement for path validation:

A log records what was submitted; it does not declare the certificate safe. Clients such as web browsers can add CT requirements to their broader certificate policy, while private PKIs and non-browser clients may use different policies.

Trust is local input. Two clients can receive the same bytes from the same server and reach different results.

Common trust sources include:

A browser on a developer laptop might trust a recently added corporate root while a Java service, minimal container, or command-line client does not. Updating the host trust store may not update a long-running process that loaded certificates only at startup.

The reverse can also happen: an application can trust a private CA file that the operating system does not know. “Works in my browser” is therefore evidence about one verifier, not proof that the server configuration works for every client.

Public and Private PKI

A public service normally uses a chain anchored in widely distributed public trust stores.

An internal service can use a private CA, but every intended client must receive the private trust anchor securely. Adding the leaf certificate itself as a broadly trusted anchor is usually the wrong model; it mixes an individual workload identity with trust-anchor configuration and complicates rotation.

Private PKI does not weaken the validation algorithm. The same signature, validity, constraint, purpose, and identity checks apply. What changes is how trust anchors and certificates are issued and distributed.

In mutual TLS, the server validates a client certificate using the same basic path machinery but with different application inputs.

The server needs:

Client certificates do not normally identify clients through HTTPS DNS hostname matching. Their relevant identity might be a subject distinguished name, SAN URI, SAN email address, device identifier, or another form defined by the system's certificate profile.

A chain can be valid for server authentication and invalid for client authentication because EKU and local trust policies differ. Some systems deliberately use separate issuing intermediates for client and server certificates so each role can be constrained independently.

Successful mTLS validation establishes a certificate identity. It does not decide what requests that identity may perform.

The following command connects with SNI, asks OpenSSL to verify the server chain and hostname, and prints the certificates sent by the server:

On success, the end of the output includes:

On failure, inspect the reported depth and reason. OpenSSL commonly numbers the leaf as depth 0, its issuer as depth 1, and so on.

-showcerts prints the certificate list transmitted by the server. It does not guarantee that the list is a complete or successfully validated chain, and it does not necessarily show every locally selected certificate in the final path.

To test a private service, provide the intended root explicitly:

Using -CAfile for a diagnostic is different from disabling verification. It states which anchor should be trusted for the test.

Inspecting a Certificate File

For a PEM-encoded leaf certificate:

This reveals identity, issuer, validity, fingerprint, and the most relevant usage constraints. -text prints the full decoded certificate when deeper inspection is needed.

Check whether a certificate expires within the next seven days:

The exit status is non-zero if the certificate will expire within that interval.

Verifying a Saved Chain

Suppose the files contain:

Verify the server purpose and hostname:

-untrusted does not mean “known malicious.” It means those certificates are candidates for path construction but are not trust anchors. Only root.pem is trusted by this command.

Avoid adding -no_check_time, -ignore_critical, or similarly permissive flags when trying to reproduce real validation. Such flags change the question being tested.

Expired or Not Yet Valid

The leaf or an intermediate falls outside its validity period.

Check every certificate in the built path and the verifier's clock. In clustered systems, confirm what each load balancer and server instance actually presents; a partial rollout can make failures appear intermittent.

Hostname Mismatch

The reference identity does not match an appropriate SAN entry.

Typical causes include deploying a certificate for www.example.com on api.example.com, assuming *.example.com covers v1.api.example.com, connecting by IP to a DNS-only certificate, or relying on the Common Name.

Unknown Issuer

No candidate path reaches a locally trusted anchor.

The service might use a private CA that the client lacks, the client's trust store might be outdated, or the application might load a different CA bundle than expected.

Missing Intermediate

The server sends the leaf but omits an intermediate required by clients.

Browsers can appear unaffected because they cached or fetched the issuer. Fresh containers, command-line tools, and backend runtimes often expose the problem. Configure the server with the full leaf-plus-intermediate chain rather than depending on client recovery.

Wrong or Expired Intermediate

The server sends an intermediate that does not produce a valid path for the target clients.

This can occur during CA chain changes or cross-sign transitions. The leaf may be perfectly valid while the delivered chain steers some path builders toward an expired or untrusted anchor.

Wrong Certificate Selected

The client receives a valid certificate for a different virtual host.

Missing or incorrect SNI, a load-balancer listener mistake, or an incomplete certificate map can cause this. Always test using the exact hostname and SNI behavior of the real client.

Certificate and Private Key Do Not Match

The deployed leaf certificate contains a public key unrelated to the configured private key.

Some servers reject the configuration at startup. Others fail during the TLS handshake because they cannot produce a verifiable signature. This is not a path-validation failure, even though it surfaces near certificate handling.

Wrong Key Usage or EKU

The chain is signed and the hostname matches, but the certificate is not permitted for TLS server authentication.

This frequently appears when a client-authentication, code-signing, or generic internal certificate is reused for the wrong role.

Constraint or Critical-Extension Failure

An intermediate lacks CA = TRUE, lacks keyCertSign, exceeds a path-length constraint, violates name constraints, or contains a critical extension the client cannot process.

These failures are easy to miss when engineers inspect only dates and SANs.

Revoked, Stale, or Missing Status

A status source reports the certificate revoked, a stapled response is stale, or a required staple is absent.

Record whether the client received a definitive negative status or merely could not obtain current information. Client policy determines how an unavailable optional status service is handled.

Different Trust Stores

One client succeeds while another fails because their anchors, intermediate caches, algorithms, or additional policies differ.

Compare the exact runtime versions and CA locations. Testing with a browser does not reproduce a containerized backend's validation environment.

TLS-Inspecting Proxy

An enterprise proxy can terminate the original TLS connection and issue a replacement certificate signed by an enterprise root.

Managed clients that trust that root may succeed, while unmanaged applications fail with an unknown issuer. Inspect the certificate issuer and fingerprint actually observed from the failing network. The presence of a trusted replacement certificate means the proxy is a TLS endpoint for that connection, not a transparent packet forwarder.

Certificate problems are usually lifecycle problems rather than cryptographic surprises.

Automated renewal is only the first step. A production process should also distribute the new leaf and intermediates, confirm the private-key association, reload every TLS endpoint, and test what each public address actually serves.

Monitor the certificate observed over the network, not only the file produced by an issuance job. A successful renewal does not help if a reverse proxy still holds the old certificate in memory.

Alert before both leaf and intermediate expiration. Leave enough time to diagnose issuance failures, ownership changes, broken challenge routing, or stalled deployments.

During rotation, verify:

Test from a clean environment without warm intermediate caches. This approximates what a newly created container, device, or first-time client will experience.

Never “fix” a certificate incident by permanently disabling verification. That turns an availability problem into an authentication failure that may be invisible in normal monitoring.

A valid signature does not make a certificate trusted. Validation must reach a locally accepted trust anchor through an authorized path.

A self-signed root is not trusted because it signed itself. It is trusted because the verifier obtained and accepted its public key through another process.

The server should not rely on sending the root. The client must already trust an anchor.

Path building is not the same as validating a path. A client can find a sequence that later fails time, constraint, purpose, or policy checks.

The Common Name is not the modern fallback for a missing SAN. TLS service identities belong in subjectAltName.

A wildcard matches one DNS label, not an arbitrary suffix. *.example.com does not cover example.com or v1.api.example.com.

SNI does not verify identity. It helps the server select a certificate; the client still validates the returned identity.

A certificate can be unexpired and revoked. Time validity and revocation status answer different questions.

An OCSP good response does not validate the whole certificate. It does not replace path, purpose, time, or hostname checks.

Certificate Transparency does not declare a certificate trustworthy. It makes issuance visible for auditing and policy enforcement.

-showcerts does not prove that OpenSSL validated the displayed list. It shows what the server transmitted.

A browser success does not prove every backend client will succeed. Trust stores, issuer fetching, caches, algorithms, and local policies vary.

Disabling verification is not a temporary equivalent of trusting a private CA. The former removes authentication; the latter supplies an explicit trust anchor while preserving validation.

Certificate validation determines whether a public key is acceptable for the intended service and purpose. The client builds a path from the leaf to a local trust anchor, then verifies signatures, time, CA authorization, constraints, key usage, and critical extensions.

Service identity must match subjectAltName, not the Common Name or connected IP. Wildcards cover one left-most DNS label, while IP connections require an iPAddress SAN. CRLs, OCSP, and stapling provide revocation status with client-specific failure policy; Certificate Transparency adds issuance accountability without replacing validation.

Trust stores, cached intermediates, and local policy can make clients judge one server differently. Operations must monitor the complete chain served by every endpoint.

Diagnose the exact failed stage: path construction, signature, time, constraints, purpose, identity, status, or proof of private-key possession.