Mutual TLS and Workload Identity

Both sides show a certificate

In normal TLS only the server proves its identity. In mutual TLS (mTLS) the client also presents a certificate signed by a CA both sides trust, so each side knows who is on the other end and the traffic is encrypted. A mesh automates the hard parts: its control plane acts as a CA, issues each workload a short-lived certificate tied to its identity (for example a Kubernetes service account, in a SPIFFE-style name), rotates it automatically and the sidecars perform the handshakes, so applications keep speaking plain HTTP locally. With mTLS you can write policy such as "only the billing service may call orders" and no longer rely on network location, a building block of zero trust.

Identity, policy, telemetry

A mesh gives every service a cryptographic identity, applies traffic policy and records what happens.

A real mutual-TLS handshake with openssl

This script (OpenSSL 3.0.13) creates a private CA, a server certificate for orders.mesh.local and a client certificate for billing.mesh.local, then starts a server that requires a client certificate. Demo-only keys, valid 30 days.

# 1. a private CA, a server certificate and a client certificate (all demo-only, 30 days)
openssl req -x509 -newkey rsa:2048 -nodes -keyout ca.key -out ca.crt -days 30 -subj "/CN=demo-mesh-ca"
mk() { openssl req -newkey rsa:2048 -nodes -keyout $1.key -out $1.csr -subj "/CN=$2"
       printf "subjectAltName=DNS:$2\n" > $1.ext
       openssl x509 -req -in $1.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out $1.crt -days 30 -extfile $1.ext; }
mk server orders.mesh.local
mk client billing.mesh.local

# 2. a server that REQUIRES a client certificate signed by our CA
openssl s_server -accept 4433 -cert server.crt -key server.key -CAfile ca.crt -Verify 1 -verify_return_error -www &

# 3a. client WITH its certificate
echo "GET /" | openssl s_client -connect 127.0.0.1:4433 -servername orders.mesh.local \
   -CAfile ca.crt -cert client.crt -key client.key -verify_hostname orders.mesh.local

# 3b. client WITHOUT a certificate
echo "GET /" | openssl s_client -connect 127.0.0.1:4433 -servername orders.mesh.local -CAfile ca.crt

What the handshakes showed, run

I ran the script and filtered the key lines. With a valid client certificate the handshake succeeds over TLS 1.3 and the chain verifies against the CA (Verification: OK, Verify return code: 0). Without a client certificate, the server rejects the connection with the TLS alert certificate required.

with client cert:
  subject=CN = orders.mesh.local
  issuer=CN = demo-mesh-ca
  Verification: OK
  New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
  Verify return code: 0 (ok)

without client cert:
  ...ssl3_read_bytes:tlsv13 alert certificate required...SSL alert number 116

Short-lived certificates beat revocation

Certificates that live for hours and are renewed automatically make a stolen key useless quickly, avoiding the pain of revocation lists. Manual certificate management at scale is exactly the chore meshes remove.

Quick check: What does mTLS add compared with ordinary TLS?

• It makes traffic public
• It removes encryption
• The client also proves its identity with a certificate
• It replaces DNS