Mutual TLS: workload authentication, trust bundles, and authorization

Mutual TLS authenticates both TLS endpoints and protects the channel. Certificate path and workload identity validation happen before application authorization; proxies must preserve the verified identity across the termination boundary.

Security invariants

• MTLS-C1: TLS 1.3 certificate authentication uses Certificate and CertificateVerify to prove identity material and private-key possession within the handshake.
• MTLS-C2: Peer validation includes certificate path, validity and expected name or workload identity, not merely a certificate signed by any CA.
• MTLS-C3: SPIFFE SVIDs are short-lived workload identity documents backed by trust-domain bundles and automatic rotation.
• MTLS-C4: Mutual TLS authenticates peers and protects the channel; request authorization remains a separate policy decision.
• MTLS-C5: A TLS-terminating proxy is a trust boundary and passes verified identity only over a protected local path that applications cannot spoof.
• MTLS-C6: Trust-root and certificate rotation use bounded overlap and fail closed when required identity or trust material expires.

Trust-boundary map

Component	Responsibility
workload-alpha	Calling Workload
sidecar-alpha	Client TLS Endpoint
network	Untrusted Network
sidecar-beta	Server TLS Endpoint
workload-beta	Protected Workload
trust-bundle	Trust Bundles and Certificate Policy
identity-control	Workload Identity Control Plane
authorization-policy	Service Authorization Policy
audit-log	Handshake and Policy Audit
attacker	Untrusted Workload

Topology edges represent authenticated or otherwise explicit communication paths. Responses reuse those physical paths in reverse; no response-only or bypass edges are added.

Executable scenarios

mutual-handshake — TLS 1.3 mutual certificate handshake

Both endpoints validate the peer chain and expected identity and prove possession of the certificate private key before application data is accepted.

▶Walkthrough: mutual-handshake (not found)

untrusted-chain — Reject an untrusted certificate chain

A syntactically valid certificate is not trusted unless path validation reaches the configured trust anchor for the peer trust domain.

▶Walkthrough: untrusted-chain (not found)

identity-name-mismatch — Reject the wrong workload identity

Path validation alone is insufficient; the verifier checks the expected DNS name or SPIFFE URI SAN and intended trust domain.

▶Walkthrough: identity-name-mismatch (not found)

certificate-rotation — Rotate short-lived workload certificates

The identity control plane streams a replacement before expiry and trust bundles overlap only as needed for safe root or intermediate rotation.

▶Walkthrough: certificate-rotation (not found)

termination-boundary — Preserve identity after TLS termination

When a sidecar terminates mTLS, the application trusts peer identity only through a protected local channel and authenticated proxy metadata.

▶Walkthrough: termination-boundary (not found)

authentication-not-authorization — Certificate identity is not permission

mTLS proves which workload controls a key; a separate policy decides whether that identity may call the requested method and resource.

▶Walkthrough: authentication-not-authorization (not found)

identity-control-outage — Bound credential use during control-plane outage

A workload may continue with a cached unexpired identity according to policy, but expiry or missing trust material fails closed rather than creating an immortal credential.

▶Walkthrough: identity-control-outage (not found)

Operational and failure rules

• Every rejection path fails closed at the component that owns the decision; infrastructure failure is never converted into authentication, authorization, or integrity success.
• Retries preserve stable transaction identity, replay detection, bounded freshness, and audit context. A retry does not erase a prior success or compromise signal.
• Concurrent validation branches are independent checks. Completion requires every mandatory branch, and no check substitutes for another.
• Logs contain decision metadata and stable identifiers, not credentials, bearer tokens, cryptographic keys, or sensitive payloads.

Related concepts

[CONCEPT]zero-trust [CONCEPT]authn-models [CONCEPT]authz-models [CONCEPT]data-encryption

Authoritative sources

1. RFC 8446: The Transport Layer Security Protocol Version 1.3
2. RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
3. SPIFFE Concepts
4. SPIFFE Trust Domain and Bundle specification
5. SPIFFE Workload API specification