mTLS & Pinning
curl https://api.example.com succeeds, but curl against an internal service stalls: the server sends a certificate required alert. It finished checking you, then asked the other way: prove who you are, or you are not coming in.
- ▸The trust check runs one way; now the server turns it around, and an empty-handed caller is dropped.
- ▸A certificate that passes every validity check can still be refused when its key is not one you hard-coded.
- ▸Hard-code the wrong safety and you lock out your users; the fix is a new release, not a config.
The handshake you traced proved one thing: the server holds the key inside the certificate it sent. The client checked it, walked the chain to a root in its store, and trusted it. The server, meanwhile, never asked who was calling. Anyone who completes the handshake is in.
Point curl at an internal service and that changes. Partway through the handshake the server turns the question around and asks the caller for a certificate of its own. A browser hitting a public site would have nothing to send, and that is the point: this is not for anonymous visitors. But a service you provisioned holds a certificate too. It presents that certificate and signs a value to prove it owns the matching private key, the same proof the server just gave the client.
Now the server does what the client already did. It walks the caller's certificate up its own chain, to a root in the server's trust store. A caller with no certificate, or one that chains to a root the server does not hold, is dropped before a single byte of the request is read.
You hold the caller's side. Decide what to present, or present nothing, and watch the server's walk decide.