mTLS, or mutual TLS, lets a client and server verify each other while establishing an encrypted connection. Both present certificates and prove possession of the matching private keys. For your API, that means a caller must pass certificate validation as well as any application-level access rules. You can encrypt an API connection and still have no reliable idea which machine opened it. mTLS adds that identity check, giving you a way to reject unknown clients before they reach application code, while keeping permissions a separate decision.
Key Takeaways
- mTLS provides mutual authentication. Private keys stay with their holders, not in network messages.
- A valid certificate identifies a client; it does not grant every API permission.
- Client-to-edge and edge-to-origin mTLS protect separate connections with different identities.
- Backup providers need the same authentication policy and certificate rotation tests as your primary CDN.
What Is mTLS?
Mutual Transport Layer Security adds client certificate authentication to the server authentication normally used by HTTPS. A certificate connects an identity to a public key. The matching private key produces a signature that proves the client possesses it.
A certificate authority, or CA, signs certificates. Your server accepts selected CAs through a trust store, a collection of trusted issuer certificates. That trust must stay narrow: a certificate from an accepted CA still needs an identity that your policy permits.
Authentication is not authorization. A partner allowed to retrieve invoices should not automatically gain permission to delete them.
{{cool-component}}
How mTLS Differs From Standard One-Way TLS
Standard one-way TLS typically authenticates the server. mTLS adds a certificate-based identity check for the client; both still encrypt traffic. Neither automatically determines API permissions.
For API authentication, API keys can remain useful alongside mTLS for application identity or permission rules. Managed service clients and partner APIs are sensible mTLS candidates because you can arrange certificate provisioning. Ordinary public browser audiences face a harder usability tradeoff: visitors need client certificates installed and available.
How the mTLS Handshake Works Step by Step
This is a conceptual walkthrough of a full TLS 1.3 handshake, not a packet-level sequence for every TLS version.
- The client sends ClientHello. It offers supported TLS settings and key-exchange information so both sides can agree on connection security.
- The server responds and requests client authentication with CertificateRequest. It sends its certificate and CertificateVerify signature, proving possession of its private key, followed by its Finished message.
- The client validates the server. It checks the certificate chain against trusted issuers, its validity dates and intended use. The server hostname must match the certificate, preventing acceptance of the wrong server. It also verifies the server's signature and Finished message.
- The client supplies its certificate and CertificateVerify signature. The server checks the client's chain and validity dates, confirms client-authentication use, and verifies the signature. It maps the verified identity to your policy. Neither side sends its private key.
- The client sends Finished. Finished verification protects the handshake against tampering. Once authentication succeeds, the connection can carry protected application requests; access policy still decides which requests are allowed.
Where mTLS Is Used in CDN and Edge Architectures
Cloudflare and Fastly support client mTLS at the CDN edge. This lets you authenticate managed API clients before forwarding their requests. Configure enforcement, not just certificate collection: requests without an acceptable certificate must be blocked. Product plans and certificate-store limits differ, so verify support for your intended setup.
Keep Client and CDN Identities Separate
A reverse-proxy CDN uses separate client-to-edge and edge-to-origin TLS connections. Terminating mTLS at the edge does not automatically give the origin end-to-end client authentication.
Edge-to-origin mTLS authenticates the CDN, not necessarily the end user. Prefer certificates scoped to your account or hostname. A shared provider certificate may prove only that traffic came from that provider, potentially including other customers.
When forwarding a verified client identity in a header, strip incoming copies before setting the trusted value. Secure the proxy-to-origin connection, and make the origin reject identity headers from untrusted paths. Exposed origins and inconsistent trust policies remain CDN security risks even when edge mTLS works.
{{cool-component}}
How to Manage mTLS at Scale Across Multiple CDN Providers
Use one authentication policy with a separately configured trust store at each provider. Share approved CA certificates and identity rules, not client private keys. Each provider must independently validate the clients you intend to admit. Use separate keys for each provider's origin-facing identity. Trust stores need CA certificates, not CA private keys.
- Automate certificate inventory and expiration monitoring, recording owners so renewal failures reach someone responsible. Track certificate serial numbers and issuing CAs to locate deployments affected by a compromise.
- Automate client issuance and renewal, including certificate reloads, because an issued replacement does nothing until clients use it.
- Verify revocation behavior at every provider. Recording a revocation is not enough unless request enforcement rejects it.
- Test accepted and rejected identities through both providers. Include missing and expired certificates to catch permissive backup configurations. I'd also test a valid certificate whose identity lacks permission for the requested action.
When traffic steering routes requests to a backup provider, that provider must enforce the same authentication policy. Treat failover authentication tests as seriously as primary CDN tests.
Install New Trust Before Rotating Certificates
For a CA change, install the new CA trust on every provider first. Keep old and new trust active together, then deploy renewed client certificates gradually. This overlap prevents clients from presenting certificates that a backup provider cannot yet recognize.
Verify fresh connections on primary and backup providers before removing old trust. Existing connections may survive renewal, so continued traffic alone does not prove the replacement works.
Emergency revocation is different: depending on the product, you may need to terminate active connections and invalidate resumption state. Plan for interruption rather than promising zero disconnects.
Conclusion
Deploy mTLS with explicit identity permissions on each connection. Keep provider trust stores aligned, protect the origin, and verify certificate changes through fresh connections on both delivery paths.
FAQs
When should mTLS be used instead of API keys?
Choose mTLS when you control certificate provisioning and need clients to prove possession of a private key, rather than merely present a reusable secret. Managed service clients and partner APIs fit this model. API keys can still complement mTLS when your application needs separate identity or authorization rules.
Can mTLS be terminated at the CDN edge?
Yes. Supported CDN services can validate client certificates and terminate TLS at the edge. The origin then receives a separate connection from the CDN. To preserve the verified client identity, forward it through a protected, trusted path and prevent callers from supplying spoofed copies of the identity header.
How does mTLS support zero trust network architecture?
mTLS supplies a verified client identity instead of treating network location as proof of trust. That identity can feed rules granting only the access a service needs. It supports zero trust, but does not complete it: authorization and ongoing access decisions still need enforcement beyond the TLS handshake.
Does mTLS add measurable latency to connection performance?
It can. Certificate verification and extra handshake bytes add work, but mTLS does not require a full extra network round trip compared with ordinary TLS 1.3. Connection reuse and session resumption change the cost. Measure fresh and reused connections separately; there is no universal millisecond overhead.
How do you rotate client certificates without dropping connections?
Renew certificates before expiry and let clients reload replacements gracefully. When changing CAs, distribute new trust first and overlap it with old trust. Test fresh connections before retiring old certificates or issuers. Existing connections may continue, but implementation behavior varies, so no rotation plan can guarantee zero disconnects.
