Certificates, SANs and trust chains

Encryption and correct peer identity require separate checks.

UnderstandStudy an examplePractise

Understand the concept

Certificates bind names to keys through a trust chain. Clients check trust, validity and hostname identity through SANs. Domain validation does not establish organisational honesty.

Missing intermediates can work for some clients and fail for others. Wildcards generally cover one label, not arbitrary nested subdomains. Renewing a certificate and loading it into a proxy are separate steps. Incorrect clocks can also cause validation failures.

Protect private keys and never commit them. Automate renewals and monitor expiry. Pinning can complicate rotation and is not a generic improvement. Disabling client verification hides the root problem instead of fixing it.

WHEN TO USE IT

Diagnose client-dependent TLS failures.

COMMON PITFALL

Treating curl -k as a certificate repair.

01 / PRACTICE

One topic. Three levels of depth.

HTTP / illustrative example

Host: api.example.test
Certificate SAN: api.example.test

The hostname identity must match.

This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.

02 / YOUR TURN

Try it yourself first.

Should you disable client validation for an expired certificate?

Show the solution and explanation

Worked solution

Renew → deploy → verify → monitor

No; renew, deploy correctly and verify with real clients.

RasimAtaberkŞahin

Understand the concept

One topic. Three levels of depth.

Try it yourself first.