Client certificates (mTLS)
Verify a client's TLS certificate in your MCP server while keeping ordinary requests available.
Client certificate support is available on request for custom domains. Email [email protected] with your hostname to enable it.
For a migration, prepare your domain with TXT validation and request client certificate support before switching the CNAME. Your existing service can keep serving traffic during preparation. Wait for support to confirm enablement before moving traffic.
Once enabled, Manufact requests an optional client certificate and forwards it to your MCP server.
Clients without a certificate can connect normally. Your application decides which operations require a verified client identity.
Headers your server receives
The headers use RFC 9440 encoding:
| Header | Contents |
|---|---|
Client-Cert | The client's leaf certificate as a colon-delimited Base64 DER value: :base64-DER:. |
Client-Cert-Chain | Intermediate certificates, when supplied, as a comma-separated list of values in the same format. |
Read the headers in your request handler or middleware:
const leafHeader = request.headers.get('Client-Cert');
const chainHeader = request.headers.get('Client-Cert-Chain');Manufact replaces caller-supplied values with the certificate from the TLS connection. If no certificate is available, these headers are absent. The chain header is optional.
Validate in your application
Use an X.509 verifier to validate the certificate chain against your trusted certificate authority (CA), check certificate validity and client-authentication usage, and match the expected identity, such as an exact DNS Subject Alternative Name (SAN). Receiving a certificate alone does not authorize a request.
Trust these headers only on requests received through Manufact; direct requests to your origin can contain caller-supplied headers.
Example: verify ChatGPT
To restrict a protected tool to ChatGPT, validate the forwarded certificate using OpenAI's mTLS requirements:
- Configure your verifier with the published OpenAI Root CA and OpenAI Connectors mTLS intermediate CA.
- Verify that the certificate in
Client-Certchains to that OpenAI intermediate CA and is valid for client authentication. - Require the certificate's DNS SAN to be exactly
mtls.prod.connectors.openai.com.
Allow the protected tool only after all checks succeed. Reject missing or invalid certificates for that tool while leaving ordinary operations available. Trust the published CA chain rather than pinning a leaf certificate fingerprint, since OpenAI rotates leaf certificates.
This identifies ChatGPT as the client. Continue using OAuth to authenticate the end user and check their permissions.