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.

Связанная концепция

Первичные источники

1. https://www.rfc-editor.org/rfc/rfc5280.html
2. https://www.rfc-editor.org/rfc/rfc9525.html
3. https://www.rfc-editor.org/rfc/rfc6960.html
4. https://www.rfc-editor.org/rfc/rfc6066.html
5. https://www.rfc-editor.org/rfc/rfc9162.html
6. https://www.rfc-editor.org/rfc/rfc8446.html