Certificate Pinning & Request Signing

Certificate pinning restricts which certificates a client will accept from the server, going beyond standard CA validation. Instead of trusting any certificate signed by any CA in the trust store, the client pins the expected server certificate (or its public key hash) and rejects connections to servers presenting a different certificate — even if that certificate is signed by a trusted CA. This defends against compromised CAs and man-in-the-middle proxies. For MCP clients connecting to known servers, pin the server's public key hash (HPKP-style) rather than the full certificate, so that certificate renewal does not require a client update.

HTTP request signing adds a cryptographic proof that the request was sent by an authorized client and was not modified in transit. The client computes a signature over the HTTP method, URL, headers, and body using its private key, and includes the signature in an Authorization or Signature header. The server verifies the signature using the client's public key. This provides integrity (the request was not tampered with), authenticity (the request came from the key holder), and non-repudiation (the client cannot deny sending the request). Request signing is stronger than bearer tokens because a stolen token can be replayed; a signing key requires the attacker to compute new signatures.

Combining mTLS, certificate pinning, and request signing creates a layered authentication stack for high-security MCP deployments. mTLS proves the client is authorized at the transport layer. Certificate pinning ensures the server is the expected server, not an impersonator. Request signing proves each individual request is authentic and unmodified. Each layer catches threats the others miss: mTLS catches unauthorized clients, pinning catches compromised CAs, signing catches request tampering by intermediaries that terminate TLS.