mTLS

mTLS

mTLS extends TLS so both sides of the connection present certificates. That means you get encryption in transit and strong machine identity at the same time, which is especially useful for service-to-service traffic inside a zero-trust network. It is powerful, but only if certificate issuance, rotation, and authorization are treated as operating concerns instead of one-time setup.

Minimal Example

tls:
  certificates:
    - cert: /etc/tls/client.crt
      key: /etc/tls/client.key
  validation:
    ca: /etc/tls/ca.crt
    require_client_certificate: true

What It Solves

• Gives every connection a verifiable service identity instead of trusting network location alone.
• Reduces the blast radius of credential theft compared with shared static secrets.
• Creates a solid base for service mesh or east-west security policy.

Failure Modes

1. Deploying certificates manually with no rotation path and then dreading expiry day.
2. Treating certificate possession as full authorization with no workload-level policy on top.
3. Skipping observability around handshake failures, SAN mismatches, and trust-chain drift.

Production Checklist

• Automate issuance, rotation, and revocation before rollout expands.
• Separate authentication from authorization; a valid cert only proves identity.
• Log handshake failures with enough detail to debug trust and hostname problems quickly.

Closing

mTLS is strongest when identity is automated and short-lived. If certificate operations are manual, the security model will decay under real-world pressure.

---