Mutual TLS (mTLS)
TLS where both ends prove who they are. Ordinary TLS authenticates the server to the client; under mTLS the client also presents an X.509 certificate, and the server accepts the connection only if that certificate chains to a CA it trusts. The credential is bound to the transport, so a request that arrives without a valid client certificate is refused before any application-level login runs.
That makes it the concrete form of the thing zero-trust argues for. Zero trust says the network is not a boundary and every request must carry its own proof; mTLS is one way to actually carry it, and the proof is a file with an issuer, a validity window and a revocation status vaultls.
What it costs
The security property is cheap and the bookkeeping is not — which is why the tool this spoke holds exists to manage certificates rather than to implement the protocol. Three costs recur in vaultls‘s design:
- Every client needs a certificate, issued by someone, delivered somehow. VaulTLS distributes client certificates as password-protected PKCS#12 bundles, and only admins can issue.
- Certificates expire, so a working system stops working on a date nobody wrote down. Expiry notification is the feature the author says he built the tool for.
- Distribution formats disagree. A PKCS#12 bundle has to be split into separate certificate and key files before a reverse proxy will read it. Nothing about that is cryptographic; it is the tax on moving a credential between two programs that both support mTLS.
Where it sits among this spoke’s layers
system-hardening removes what an attacker can use, the SOC shortens how long they go unnoticed, and access architecture governs what a credential is worth once someone holds it. An mTLS client certificate is a bearer credential with a built-in end date: whoever has the key file is the client, and the only ways to take that back are to wait for expiry or to publish a revocation (certificate-lifecycle-management). Compared with a session token it is longer-lived and harder to steal in bulk; compared with the per-action authorization Beyond Zero proposes, it is coarse — it decides whether you may connect, not what you may then do. The two compose: mTLS establishes the identity that a finer policy engine spends its time reasoning about.
Nothing in this corpus measures mTLS deployment or its effect on an incident. The one source is a tool for running it, not a study of using it.
Related
vaultls · certificate-lifecycle-management · zero-trust · defensive-security · system-hardening · synthesis