Architecture and operating model
A TLS client validates more than the leaf certificate. It builds a path from the leaf and server-provided intermediates to a root in the client's trust store, then evaluates signatures, validity, name matching, Basic Constraints and Key Usage. A server should not send the root but must send the required intermediates in a usable order. A site that works in a browser yet fails in a minimal API client can expose differences in cached intermediates or trust stores.
When several names share an IP address, SNI carries the requested server name in the TLS handshake. A legacy client that omits SNI can receive the default virtual host certificate. Revocation is checked with CRLs or OCSP; with OCSP stapling the server includes a signed status response in the handshake. Missing stapling is distinct from an invalid or expired stapled response.
Start diagnosis by proving DNS and the destination IP, then isolate the SNI-selected chain, name match, time, trust store and revocation channel. Disabling validation in production only hides the fault and removes the identity boundary. Repair the virtual-host mapping, complete intermediate chain, controlled trust store and measurable OCSP/CRL path instead.
- 1DNS and destination IP
- 2TLS handshake with SNI
- 3Chain and name validation
- 4Revocation status and telemetry
Design parameters
- Chain contents
- Serve the leaf and required intermediate CA certificates; keep the root in the client trust store.
- Name validation
- The SAN must cover the requested FQDN; validate wildcard scope and IDN representation separately.
- Time and renewal
- Monitor NotBefore/NotAfter, client clock and the renewal window together.
- Revocation behavior
- Fail-open and fail-closed behavior varies by client; measure stapling age and responder reachability.
Worked example
If three percent of clients report unknown issuer for api.example.com, segment them before changing the certificate. When the server sends only the leaf and the missing intermediate is 1.8 KB, serving the chain adds little handshake data while letting all clients build the same path. Compare handshake_error rate and p95 TLS time before and after the change.
For portal.example.com and api.example.com on one IP, run `openssl s_client` with and without `-servername`. A changed fingerprint proves a default-vhost versus SNI selection issue; correct listener and certificate mapping before altering DNS.
Example commands: replace lab values and confirm permissions and software versions before use.
openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts -status </dev/null
openssl x509 -in leaf.pem -noout -subject -issuer -dates -ext subjectAltName
openssl verify -purpose sslserver -untrusted intermediate.pem -CAfile roots.pem leaf.pem
curl -v --resolve api.example.com:443:192.0.2.20 https://api.example.com/healthTroubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| unable to get local issuer certificate | An intermediate may be missing or the client may use a different trust store. | Compare the `-showcerts` chain with `openssl verify -CAfile` output. |
| hostname mismatch | SNI may be wrong, SAN coverage incomplete or another virtual host may answer. | Record destination IP, `-servername` and the certificate SAN list together. |
| OCSP response expired | The stapled response may be stale or responder access unavailable. | Inspect producedAt, thisUpdate and nextUpdate plus the server refresh log. |
Acceptance checks
- List the served leaf and required intermediate certificates.
- Validate the FQDN against SAN and the SNI result.
- Confirm reliable time on client and server.
- Test with at least two independent client trust stores.
- Validate the OCSP stapling signature and time window.
- Compare TLS error rate and p95 handshake duration after remediation.
Related concepts
TLS and certificate validation
TLS protects confidentiality and integrity in transit; certificate validation helps verify the peer’s identity. Evaluate names, chains, validity periods and trusted roots together. Encryption does not prove correct application authorization. If a reverse proxy or inspection device is used, show where TLS terminates. Disabling validation is not a permanent troubleshooting solution: investigate hostname mismatch, missing intermediate certificates and incorrect device clocks separately.
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new access attempts are denied when the identity provider becomes unavailable.
Version and support lifecycle
Installability does not prove production support. Review the compatibility chain across OS, application, drivers, extensions and management tools. Update plans should record version, support end, restart needs and rollback methods. A test environment that does not reflect production can produce misleading results. Validate service health and existing workflows after a change, not just version numbers. Remember that pinning a version can also prevent future security fixes.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.