Skip to content
BytePath
BytePath v0.0.35

TLS Certificates and Trust Chains

Before you start

Who is this for?

For IT learners who want to understand HTTPS and diagnose certificate validation errors.

Prerequisites

  • Networking fundamentals
  • Basic public/private key concepts

What you'll be able to do

  • Explain TLS and HTTPS
  • Read a certificate chain
  • Recognize name, time, and trust failures
  • Inspect endpoints safely

Practical outcome

Identify the validation check behind a common certificate error.

TLS protects data exchanged over a network. It helps a client verify the server’s identity, negotiates keys for encryption, and detects changes to protected traffic. HTTPS is HTTP carried over TLS. A lock icon means the connection passed checks made by that browser; it does not prove a site is honest or that its content is safe.

Learning objectives

Section titled “Learning objectives”
  • Explain what TLS provides and how it relates to HTTPS.
  • Read the main parts of a certificate and a trust chain.
  • Recognize hostname, date, and trust failures.
  • Inspect a TLS endpoint with a browser, curl, and OpenSSL.

Keys, certificates, and trust

Section titled “Keys, certificates, and trust”

Symmetric cryptography uses a shared secret to protect traffic efficiently. Public-key cryptography uses a related public and private key for tasks such as signatures and key agreement. The private key must remain controlled by its owner. A certificate binds a public key to identity information and is signed by a Certificate Authority (CA).

A typical public-web chain has a server (leaf) certificate, one or more intermediate CA certificates, and a root CA trust anchor. The server normally sends its leaf and needed intermediates; clients already have root trust anchors in their trust store. A valid signature chain alone is insufficient: the client also checks that the certificate is currently valid, intended for server authentication, and matches the hostname it requested. Modern service-identity rules use names in the Subject Alternative Name (SAN); do not rely on the old Common Name fallback.

Browser trust store (root CA)
          ↑ signed by
Intermediate CA
          ↑ signed by
Server certificate for www.example.test
          │ public key corresponds to
Server-held private key

TLS 1.3 authenticates the handshake and negotiates shared traffic keys. The certificate does not generally encrypt all application traffic or directly carry the session key. Once established, symmetric keys protect application data. TLS also provides integrity against undetected modification. See TLS 1.3 (RFC 8446), PKIX certificate and CRL profile (RFC 5280), and current service identity rules (RFC 9525).

What validation failures mean

Section titled “What validation failures mean”
  • Name mismatch: the requested host is not covered by a SAN entry. A certificate for example.test does not automatically cover api.example.test.
  • Expired or not yet valid: check certificate dates and the client’s clock, then renew or correct time as appropriate.
  • Untrusted chain: a CA is missing, untrusted, or incorrectly configured. Servers should provide required intermediate certificates; clients should not bypass trust checks as a fix.
  • Revocation: a CA may publish Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) responses. Client checking and failure behavior vary by application and policy, so revocation checks are not identical everywhere.

Certificate validity is time-bounded. Monitor renewal well before expiry and deploy the full intended chain. Never share a server private key to solve a certificate warning.

Inspect a site

Section titled “Inspect a site”

In a browser, open the site information panel and inspect the certificate’s subject/SAN, issuer, validity dates, and chain. Browser labels differ, but the same core checks apply.

Terminal window
curl -Iv https://www.example.com/

Verbose output shows connection and certificate verification details. A successful HTTP status is separate from certificate validation; do not add -k/--insecure outside a controlled diagnostic because it disables certificate verification.

With OpenSSL 3.x, request SNI and ask for chain and hostname verification:

Terminal window
openssl s_client -connect www.example.com:443 \
  -servername www.example.com \
  -verify_return_error -verify_hostname www.example.com \
  -showcerts </dev/null

Look for a successful verification result. -showcerts displays certificates sent by the peer; it does not itself prove the chain is trusted. Options and output can vary with OpenSSL builds. For a quick HTTP client check, curl -v uses curl’s configured TLS backend and trust store.

Troubleshooting workflow

Section titled “Troubleshooting workflow”
  1. Confirm the exact hostname, port, and system clock.
  2. Reproduce from the affected client and compare with a known-good client.
  3. Inspect SAN names, dates, issuer, and chain order.
  4. Check whether a proxy, load balancer, or CDN terminates TLS and presents a different certificate than the origin.
  5. Fix certificate deployment or trust configuration, then retest without disabling verification.

A common mistake is to install a self-signed leaf certificate as a broad trust anchor. For managed internal services, use an approved internal CA and distribute its trust anchor through a controlled process.

Practice

Section titled “Practice”

Inspect a service you administer. Record the hostname, issuer, expiry date, and whether the chain verifies. Then test a deliberately incorrect hostname in a lab and explain which validation check should fail. Never test against a service you do not have permission to assess.

TLS Certificates and Trust ChainsAvailable

Identify the validation check behind a common certificate error.

Difficulty
Beginner
Time
55 min
Practice
Inspect certificate identity, expiry, issuer, and chain verification
Assessment
Knowledge check

Related: Security Fundamentals, Networking Fundamentals.