# Mutual TLS and Workload Identity — API Gateway and Service Mesh

Source: https://www.geekswithgeeks.com/en/api-gateway-service-mesh/m-mtls

> Explain how mTLS authenticates both sides of a call and how a mesh automates certificates.

## 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.

![Four things: identity, encryption, policy, telemetry.](assets/figures/api-gateway-service-mesh/section-5-map.svg) — Figure 5.1 — Identity, encryption, policy and telemetry.

## 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.

```bash
# 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`.

```text
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.

**Quiz:** What does mTLS add compared with ordinary TLS?

- [ ] It makes traffic public
- [ ] It removes encryption
- [x] The client also proves its identity with a certificate
- [ ] It replaces DNS

*Answer:* The client also proves its identity with a certificate. Both ends are authenticated, enabling identity-based policy.