mTLS Certificate Chain Builder

Standard TLS (HTTPS) uses one-way authentication: the server presents a certificate to prove its identity to the client. mTLS (mutual TLS) adds client authentication: the client also presents a certificate, and the server verifies it. This creates a bidirectional trust — both parties cryptographically prove their identity. mTLS is used in zero-trust architectures, service mesh (Istio, Linkerd), and B2B APIs where you need to restrict access to known, pre-registered clients.

mTLS is best for service-to-service communication where clients are known machines (microservices, IoT devices), especially in zero-trust networks where network location cannot be trusted. API keys are simpler but lack the cryptographic guarantees of mTLS — keys can be stolen and reused from any machine. OAuth2 Client Credentials is better for human-managed systems where rotation and revocation are important. Use mTLS when you need the strongest authentication with no shared secrets.

Three steps: (1) Generate Root CA: openssl genrsa -out ca.key 4096 && openssl req -new -x509 -days 3650 -key ca.key -out ca.crt. (2) Generate server cert: create key + CSR, then sign with CA. (3) Generate client cert: same process but set extendedKeyUsage=clientAuth. Never use the CA key to directly serve traffic — it should only sign other certificates. Store ca.key offline or in a hardware security module (HSM) in production.

Set ssl_client_certificate to your CA cert and ssl_verify_client to 'on'. nginx will reject any client that doesn't present a certificate signed by your CA. Use ssl_verify_depth for certificate chains (usually 2 for intermediate CAs). The client's DN is available as $ssl_client_s_dn and can be passed to your backend via proxy_set_header. Use ssl_verify_client optional; to make client certs optional and check $ssl_client_verify in location blocks.

Certificate revocation in mTLS is handled via CRL (Certificate Revocation List) or OCSP. Generate a CRL with openssl ca -revoke client.crt && openssl ca -gencrl -out crl.pem. Configure nginx with ssl_crl /path/to/crl.pem. Alternatively, use short-lived certificates (24h-7d) so compromised certs expire quickly without needing revocation infrastructure. Service meshes like Istio handle rotation automatically. For high-security systems, use OCSP stapling for real-time revocation checks.

Use openssl s_client: openssl s_client -connect server.example.com:443 -cert client.crt -key client.key -CAfile ca.crt -debug. Common failures: (1) 'certificate verify failed' — wrong CA cert on server or client; (2) 'no certificate returned' — client not sending cert, check cert path; (3) 'unknown CA' — server doesn't trust the CA that signed the client cert; (4) 'handshake failure' — TLS version mismatch or cipher suite incompatibility. Run with -debug for detailed handshake output.