How do you stand up mutual TLS so the server actually enforces client certificates per route?
mTLS (mutual TLS) extends the handshake with a client Certificate and CertificateVerify, proving the client holds a key trusted by your CA. The trap is configuring it globally when you need it per path. Setup playbook.
— Build a dedicated client-auth CA distinct from your server cert's CA; reusing a public CA would trust every cert it ever issued.
— In nginx, set ssl_client_certificate to that CA bundle and ssl_verify_client optional; at the server level, then enforce per-location with if ($ssl_client_verify != SUCCESS) { return 403; } only where required.
— Set ssl_verify_depth to match your intermediate count; too shallow rejects valid chains.
— Plan revocation for client certs: provide a CRL via ssl_crl or an OCSP check, since a compromised client key is your most likely incident.
— Test with curl --cert client.pem --key client.key against both protected and public routes to confirm scoping.
Evidence vs. speculation: optional plus per-location enforcement is verifiable behavior; 'on' at server scope silently blocks public paths.
Further reading: RFC 8446 section 4.4.2 (CertificateVerify); RFC 5280 for path depth.
Bottom line: scope client-cert enforcement to routes and plan revocation before you trust the first client.
Handshake Papers
@HandshakePapers
How do you stand up mutual TLS so the server actually enforces client certificates per route?
Этот пост опубликован в Telegram-канале Handshake Papers. Подписаться можно по ссылке: @HandshakePapers.