System Design Cases
SSL/TLS Deep
SSL/TLS deep dive: cipher suites breakdown (key exchange, signature, bulk cipher, MAC), PKI cert chain (root/intermediate/leaf), Certificate Transparency, OCSP/CRL revocation, mTLS for service mesh. 3 scenarios: cert chain validation walkthrough, mTLS handshake (mutual cert verification), revocation check (OCSP query vs stapling). 2 ADRs: cipher suite selection (TLS 1.3 + AEAD + ECDHE), mTLS vs OAuth2 for service-to-service auth.
TLS PKI in depth: path, identity, status, and mutual authentication
TLS with PKIX certificates has several independent checks: handshake proof of a private key, certification-path validation, service-identity matching, certificate status policy, and application authorization. mTLS runs these roles in both directions but does not collapse authentication into authorization.
Mental model
- The server usually sends its leaf and intermediate certificates. The trust anchor is local configuration and normally is not fetched from the server.
- Path validation verifies signatures, constraints, validity, purpose, policy, and a path to an accepted trust anchor.
- Service identity validation constructs acceptable reference identifiers independently and matches typed subjectAltName entries; Common Name is not the modern fallback.
- OCSP, stapling, CRLs, and Certificate Transparency solve different problems: status, delivery of status, published revocation sets, and issuance auditability.
Гарантии и границы
- A cryptographically self-signed certificate is not trusted unless policy installs it as a trust anchor.
- A trusted chain for the wrong DNS name does not authenticate the requested service.
- Certificate revocation status is time-bounded evidence and depends on client policy when status infrastructure is unavailable.
- mTLS authenticates presented identities; authorization still needs current application policy.
Сценарии диаграммы
Certification path and service identity. The server sends a leaf and intermediates; the client validates a path to a local trust anchor and separately matches the reference identity.
Different certificate failures are not interchangeable. An otherwise valid chain can authenticate the wrong name; a matching name can still have an invalid path or usage.
Certificate status and stapling. OCSP and CRLs convey status information under policy; availability and freshness choices must be explicit.
Mutual TLS authenticates both certificate identities. The server asks for a client certificate; each peer validates a different chain and identity or authorization policy.
Архитектурные решения
- Use the narrowest trust roots and service identities practical; separate public Web PKI from internal service trust.
- Automate issuance and rotation, but keep key storage, enrollment authorization, and emergency revocation independently controlled.
- Choose revocation hard-fail, soft-fail, must-staple, and outage behavior from threat and availability requirements.
Сбои и неоднозначные исходы
- Missing intermediates can break path construction even when the leaf is otherwise valid.
- A compromised CA, misissued certificate, leaked private key, or stale status response requires different detection and response.
- mTLS identity mappings can outlive employment or workload authorization unless revocation and policy refresh are designed.
Операционный checklist
- Validate path, typed SAN identity, purpose, validity, algorithm policy, and status policy.
- Protect private keys and ticket keys; audit enrollment and rotation without logging secrets.
- Test expired, not-yet-valid, wrong-name, missing-intermediate, revoked, OCSP-down, and rotated-root cases.
- For mTLS, define principal mapping, authorization, revocation latency, and trust-domain boundaries.