Handshake Papers
Handshake Papers
@HandshakePapers

How do you stand up mutual TLS so the server actually enforces client certificates per route?

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.
Этот пост опубликован в Telegram-канале Handshake Papers. Подписаться можно по ссылке: @HandshakePapers.
tech

Свежие посты в категории «Tech Infrastructure»

Все каналы категории →

start

Готовы запустить рекламу через сеть public.tg?

Новый оффер, продукт, GEO, кейс, событие или партнёрский запуск — соберём маршрут под задачу и отдадим медиаплан.

Telegram для медиаплана: @AFFtop_connect. Быстрый тест: $20 за канал, $1000 за пакет по сети.