Archivetls
Mutual TLS Without the Operational Surprise
Client certificates are a strong authentication mechanism and a lifecycle problem. Treat them like credentials, not config.
- Published
- Reading time
- 1 min read
mTLS authenticates both ends of a connection. The server verifies a client certificate; the client verifies the server. It is the default for service mesh traffic and a good fit for machine-to-machine APIs where token distribution is awkward.
What you actually sign up for
- Issuance: every workload needs a certificate and a private key, rotated automatically.
- Identity mapping: the certificate subject or SAN must map to a service identity, not just "valid cert".
- Revocation: short lifetimes plus rotation beat CRL/OCSP for internal PKI.
- Trust bundle distribution: every verifier needs the roots, updated before they expire.
Common failure modes
- Accepting any certificate signed by the internal CA, without checking identity — authentication without authorization.
- Copying long-lived certs into images.
- Forgetting that TLS termination at a proxy hides the client cert unless forwarded and re-verified.
Takeaway: mTLS is identity infrastructure. Budget for rotation, identity mapping, and trust-bundle rollout before enabling it.