Defensive labs About 2 min read
TLS certificate chain review
Inspect an offline certificate chain against its intended identity. Check trust, names and validity, and record the reason for each result.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Offline research and planning only; product or deployment acceptance belongs to separately governed environment validation.
On this page
Overview#
Lab class: Offline certificate and policy fixtures
Purpose#
Determine what endpoint identity is asserted, which trust anchor authorises it, whether the client checks the intended service name, and how renewal or failure will behave.
Procedure#
- Record the represented service name, role, protocol, product, and software/firmware context supplied with the fixture.
- Use a synthetic chain or a sanitised, owner supplied certificate export. Don't retrieve a chain from an endpoint as part of this lab, and never include private keys.
- Record subject alternative names, issuer/chain, serial, validity, public key algorithm/size, signature, key usage and extended key usage.
- Determine whether the expected DNS/IP identity is covered and whether the documented client policy requires name and chain validation.
- Identify trust anchor distribution, intermediate availability and revocation/distrust behaviour.
- Determine whether mutual TLS is used and how client authorisation maps the certificate identity.
- Record expiry monitoring, renewal owner, overlap, rollback and offline time dependency.
- Create offline fixture variants for unknown CA, wrong hostname, expired certificate, invalid usage, broken chain, and unauthorised client identity; map each to the expected policy decision.
Reject insecure conclusions#
- Encryption observed doesn't prove endpoint identity was validated.
- A self signed certificate isn't automatically wrong, but its fingerprint/key must be established and managed through a trustworthy out of band process.
- A successful browser warning bypass isn't an acceptable application trust model.
- Certificate pinning without a rotation/recovery design can create an availability failure.
Evidence checklist#
- Certificate fixture provenance, digest, represented service, and software context recorded
- Subject alternative names, chain order, trust anchor, validity, usages, algorithms, and key sizes reviewed
- Name validation and trust policy expectations distinguished from encryption alone
- Mutual TLS identity to authorisation mapping documented where applicable
- Unknown CA, wrong name, expiry, broken chain, invalid usage, and unauthorised client fixtures assessed
- Renewal, overlap, revocation/distrust, rollback, time, and monitoring dependencies recorded
- Private keys and live credentials excluded from the evidence set