--- title: What Is mTLS? Mutual TLS Authentication Explained description: What is mTLS? Learn how mutual TLS authentication uses two-way certificate verification to secure client-server communication. image: https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-02-2026-04-15-39-7476-PM.jpeg --- [![BlazingCDN](https://blog.blazingcdn.com/hubfs/Logo/blog-logo-w.png)](https://blog.blazingcdn.com?hsLang=en-us) [๐Ÿ“˜Learn โ–พ](https://blog.blazingcdn.com/cdn-learn?hsLang=en-us) [CDN Fundamentals](https://blog.blazingcdn.com/cdn-fundamentals?hsLang=en-us) [By Content Type](https://blog.blazingcdn.com/by-content-type?hsLang=en-us) [Advanced Concepts](https://blog.blazingcdn.com/advanced-concepts?hsLang=en-us) [Glossary](https://blog.blazingcdn.com/glossary?hsLang=en-us) [โšก Web Performance](https://blog.blazingcdn.com/web-performance?hsLang=en-us) [๐ŸŽฌVideo & Streaming โ–พ](https://blog.blazingcdn.com/video-streaming-cdn?hsLang=en-us) [๐Ÿ”ด Live Streaming](https://blog.blazingcdn.com/live-streaming?hsLang=en-us) [๐Ÿ“บ VOD & OTT](https://blog.blazingcdn.com/vod-ott?hsLang=en-us) [๐Ÿ’ฐ Bandwidth & Costs](https://blog.blazingcdn.com/bandwidth-costs?hsLang=en-us) [๐Ÿญ Other Industries โ–พ](https://blog.blazingcdn.com/cdn-industry-insights?hsLang=en-us) [๐Ÿ“บ Media & Broadcasting](https://blog.blazingcdn.com/media-broadcasting?hsLang=en-us) [๐Ÿ’พ Software & SaaS](https://blog.blazingcdn.com/software-saas?hsLang=en-us) [๐Ÿ—๏ธ DevOps & Cloud Infra](https://blog.blazingcdn.com/devops-cloud-infra?hsLang=en-us) [๐Ÿ“š AdTech & Advertising](https://blog.blazingcdn.com/adtech-advertising?hsLang=en-us) [๐ŸŽฎ Gaming & Esports](https://blog.blazingcdn.com/gaming-esports?hsLang=en-us) [๐Ÿ“ฑ Mobile Apps & Developers](https://blog.blazingcdn.com/mobile-apps-developers?hsLang=en-us) [๐Ÿค– AI & Machine Learning](https://blog.blazingcdn.com/ai-machine-learning?hsLang=en-us) [๐Ÿ›๏ธ Enterprise & Corporate](https://blog.blazingcdn.com/enterprise-corporate?hsLang=en-us) [๐Ÿ“š E-Learning & EdTech](https://blog.blazingcdn.com/e-learning-edtech?hsLang=en-us) [๐ŸŸ๏ธ Sports & Live Events](https://blog.blazingcdn.com/sports-live-events?hsLang=en-us) [๐Ÿ’ฐ Pricing & Costs โ–พ](https://blog.blazingcdn.com/cdn-pricing-and-cdn-costs?hsLang=en-us) [Provider Pricing](https://blog.blazingcdn.com/provider-pricing?hsLang=en-us) [Cost Optimization](https://blog.blazingcdn.com/cost-optimization?hsLang=en-us) [Decision Support](https://blog.blazingcdn.com/decision-support?hsLang=en-us) [โšกCompare โ–พ](https://blog.blazingcdn.com/cdn-comparison?hsLang=en-us) [Provider Comparisons](https://blog.blazingcdn.com/provider-comparisons?hsLang=en-us) [Strategy Comparisons](https://blog.blazingcdn.com/strategy-comparisons?hsLang=en-us) [Ratings & Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [๐Ÿ“Š Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [๐Ÿ”’ Security โ–พ](https://blog.blazingcdn.com/cdn-security?hsLang=en-us) [Attack Protection](https://blog.blazingcdn.com/attack-protection?hsLang=en-us) [Encryption & Access](https://blog.blazingcdn.com/encryption-access?hsLang=en-us) [Video & DRM Security](https://blog.blazingcdn.com/video-drm-security?hsLang=en-us) [๐Ÿ“ Case Studies](https://blog.blazingcdn.com/case-studies?hsLang=en-us) [๐Ÿ”Œ Integrations](https://blog.blazingcdn.com/integrations?hsLang=en-us) [๐Ÿ› ๏ธ Tools](https://blog.blazingcdn.com/cdn-tools?hsLang=en-us) [Get Started](https://blazingcdn.com/sign-up-contact-form/) [Learn](https://blog.blazingcdn.com/en-us/tag/learn) [Security](https://blog.blazingcdn.com/en-us/tag/security) [Security - Encryption & Access](https://blog.blazingcdn.com/en-us/tag/security-encryption-access) # What Is mTLS? Mutual TLS Authentication Explained Vadym Borovskyi Nov 2, 2026, 5:17:21โ€ฏPM ![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-02-2026-04-15-39-7476-PM.jpeg) **mTLS (mutual TLS)** is a TLS mode in which both endpoints prove their identity with X.509 certificates: the server presents its certificate as usual, then requests one from the client and verifies it against a trusted certificate authority before any application data flows. In TLS 1.3, mTLS authentication fits inside the normal one-round-trip handshake, so it adds no extra network round trip. Under TLS 1.3 (RFC 8446, published 2018), mutual TLS works through three handshake messages: the server sends CertificateRequest, and the client answers with Certificate and CertificateVerify, a signature over the handshake transcript. A client that cannot produce a valid certificate fails the handshake before a single HTTP byte is exchanged. This makes mTLS a transport-layer identity check that leaked bearer tokens cannot bypass. ## **How mTLS authentication works in the TLS 1.3 handshake** mTLS authentication extends the standard handshake with a server-initiated certificate request and a client-side proof of private key possession. Both sides validate a chain, check validity windows, and then map the authenticated identity to authorization rules. The full exchange still completes in one round trip on TLS 1.3, with the client's certificate encrypted. 1. **ClientHello.** The client offers key shares and cipher suites exactly as in one-way TLS. 2. **Server flight.** The server sends ServerHello, EncryptedExtensions, a CertificateRequest message (carrying acceptable signature algorithms and, optionally, the certificate\_authorities extension listing CA names it trusts), then its own Certificate, CertificateVerify and Finished. 3. **Client flight.** The client sends its Certificate chain, a CertificateVerify signed with its private key over the transcript hash, and Finished. 4. **Validation.** The server builds the chain to a private trust anchor (not the public web PKI), checks expiry, key usage and, if configured, revocation through a CRL or OCSP. 5. **Authorization.** The application maps an identity field, usually a Subject Alternative Name such as a DNS name or a SPIFFE URI, to what the caller may do. Two timing details matter at scale. On TLS 1.2 the client certificate travels in cleartext, exposing client identity to passive observers; TLS 1.3 encrypts it. Session resumption through pre-shared keys carries the authenticated identity forward, so a resumed connection skips the client signature entirely. TLS 1.3 also defines post-handshake authentication, but HTTP/2 forbids it (RFC 8740), so per-path client certificate prompts do not work over HTTP/2. ## **Where mutual TLS sits in the stack** Mutual TLS authenticates whatever terminates the TLS session, not the application behind it. If a load balancer terminates TLS, the backend only learns the client identity from a forwarded header, so the proxy must strip any inbound copy of that header and set its own; Envoy's x-forwarded-client-cert header is the common pattern. Typical deployments fall into four groups: service meshes such as Istio and Linkerd, where workload certificates rotate automatically with lifetimes commonly between 1 and 24 hours; business-to-business APIs in finance and payments; device fleets and IoT gateways; and CDN-to-origin connections. ### mTLS on origin connections On the origin leg, the edge acts as the TLS client and presents a certificate the origin requires. This closes the classic bypass where an attacker who discovers the origin address skips the edge and its controls. IP allowlisting cannot close it reliably, because shared edge IP ranges serve every customer of that provider. The detail most glossaries miss: a client certificate shared by the whole provider only proves "this request came from that CDN", not "this request came from my zone". Any other tenant on the same provider can point a zone at your origin and present the same certificate. Insist on a certificate you issue, or one unique per zone, and pin authorization to its subject. ## **mTLS vs. commonly confused alternatives** **mTLS vs. one-way TLS:** one-way TLS authenticates only the server; the client stays anonymous at the transport layer and identifies itself later, if at all, with credentials inside HTTP. Mutual TLS moves client identity into the handshake, so unauthenticated clients never reach the application. **mTLS vs. API keys and bearer tokens:** a token is a replayable secret; anyone holding it is the caller. An mTLS identity requires a signature from a private key that never leaves the client, ideally a hardware module. Many APIs combine both: mTLS for workload identity, OAuth tokens bound to the certificate (RFC 8705) for user-level scope. **mTLS vs. IP allowlisting:** allowlists authorize a network location, which breaks under NAT, shared egress ranges and cloud address churn. Certificates authorize a cryptographic identity that survives address changes and can be revoked individually. ## **Example: requiring client certificates on an nginx origin** On an nginx origin, four directives in the TLS server block cover the core configuration: - **ssl\_client\_certificate** points to the PEM bundle of the private CA that signs your edge or client certificates. Only this bundle is trusted for clients. - **ssl\_verify\_client** set to *optional* during rollout, then to *on* to enforce. - **ssl\_verify\_depth** set to 2 for a root plus one intermediate, which stops longer, unexpected chains. - **ssl\_crl** pointing to a current revocation list, refreshed on a schedule. For nginx acting as the client toward an upstream, the matching directives are proxy\_ssl\_certificate and proxy\_ssl\_certificate\_key, with proxy\_ssl\_verify enabled so the upstream is authenticated too. To test, open a connection with the OpenSSL s\_client tool once with the client certificate and key and once without; on TLS 1.3 the second attempt should end with the certificate\_required alert (alert code 116). ## **How to roll out mTLS without breaking production** Rolling out mTLS safely means observing before enforcing: deploy verification in optional mode, log which clients present valid certificates, migrate the stragglers, then enforce. The phased matrix below gives each stage an exit criterion so the cutover is a measured decision rather than a guess. | Phase | Server setting | What to watch | Exit criterion | | --- | --- | --- | --- | | 1. PKI | Offline root, online issuing intermediate | Issuance automation, certificate lifetime | Every client can obtain and renew a certificate unattended | | 2. Observe | Verification optional | Share of requests with a verified client certificate | Verified share holds at 100 for 7 days | | 3. Enforce | Verification on | Handshake failures by alert type | No unexplained failures for one full rotation cycle | | 4. Rotate | Trust bundle holds old and new CA | Days to expiry of the soonest certificate | Old CA removed only after its last leaf expires | The phase that prevents outages is the overlapping trust bundle, because most mTLS incidents are expired or rotated certificates, not attacks. Two operational rules follow. Alert on days to expiry for every certificate, with a threshold at one third of its lifetime. And keep certificate lifetimes short enough that renewal runs weekly or more often; automation that runs once a year is automation nobody trusts. ## **Common misconceptions about mutual TLS** - **"mTLS replaces authorization."** It proves who the caller is. Deciding what that caller may do still needs a policy keyed on the certificate identity. - **"Any trusted CA will do."** Trusting the public web PKI for client auth admits anyone who can buy a certificate. Public CAs have also been removing the client authentication key usage from web server certificates through 2025 and 2026 under browser root program rules. Use a private CA. - **"mTLS is expensive."** The added cost per full handshake is one client signature and one server verification; with ECDSA P-256 keys that is well under a millisecond of CPU on modern hardware, and resumed sessions skip it. - **"Revocation is handled."** Many stacks never check CRLs by default. Short-lived certificates are the more dependable revocation strategy. ## **FAQ: mTLS and mutual TLS authentication** ### What is mTLS in simple terms? mTLS is TLS where both sides show a certificate. In normal HTTPS only the server proves its identity; with mutual TLS the server also asks the client for a certificate signed by a CA it trusts, and refuses the connection if the client cannot prove it holds the matching private key. It is widely used for service-to-service and origin traffic. ### Does mTLS add latency to the TLS handshake? mTLS adds no extra round trip on TLS 1.3, because the certificate request and response travel inside the existing handshake flights. The added cost is a few kilobytes of certificate chain and one signature plus one verification. Resumed sessions using pre-shared keys skip the client signature, so steady-state latency impact is usually negligible. ### Is mTLS better than API keys for securing APIs? mTLS is stronger than API keys for workload identity, because a key can be copied and replayed while an mTLS identity requires a private key that never leaves the client. API keys are simpler for third-party developers. Many production APIs use both: mutual TLS for the connection, plus certificate-bound tokens for per-user scope. ### How does mTLS protect a CDN origin server? mTLS protects an origin by rejecting any TLS connection that does not present a client certificate the origin trusts, so attackers who find the origin address cannot bypass the edge. The protection is only meaningful if the certificate is unique to your account or zone; a certificate shared across all tenants of a provider proves very little. ## **Test your origin's mTLS posture this week** Run one check against every origin this week: open a TLS session without a client certificate from a host outside your edge provider and record whether the origin serves content. Then list which identity your origin actually authorizes (a zone-specific subject or merely a provider-wide one), how many days remain until the soonest client certificate expires, and whether your proxy strips inbound client certificate headers. Those four answers tell you whether your mTLS deployment blocks bypass or only looks like it does. For the cache layer in front of that origin, the [**BlazingCDN features for origin protection and delivery**](https://blazingcdn.com/features/) page lists what every plan includes, from origin shield and request coalescing to signed URLs, tokens and IP lists, along with the 14-day testing period on real production traffic. Share: [f](https://www.facebook.com/sharer/sharer.php?u=https://blog.blazingcdn.com/en-us/what-is-mtls-mutual-tls-authentication-explained) [in](https://www.linkedin.com/sharing/share-offsite/?url=https://blog.blazingcdn.com/en-us/what-is-mtls-mutual-tls-authentication-explained) [๐•](https://twitter.com/intent/tweet?url=https://blog.blazingcdn.com/en-us/what-is-mtls-mutual-tls-authentication-explained&text=) [โœ‰](mailto:?subject=%3Cspan%20id="hs_cos_wrapper_name"%20class="hs_cos_wrapper%20hs_cos_wrapper_meta_field%20hs_cos_wrapper_type_text"%20style=""%20data-hs-cos-general-type="meta_field"%20data-hs-cos-type="text"%20%3EWhat%20Is%20mTLS?%20Mutual%20TLS%20Authentication%20Explained%3C/span%3E&body=https://blog.blazingcdn.com/en-us/what-is-mtls-mutual-tls-authentication-explained) ![BlazingCDN](https://blog.blazingcdn.com/hs-fs/hubfs/Logo/blog-logo-w.png?height=24&name=blog-logo-w.png) *Heavy traffic.* Light bill. The CDN for video and large traffic Their monthly bill vs ours - 20 TBFastly $2,087**$92.50** - 50 TBCDN77 $990**$215** - 200 TBCloudFront $11,965**$765** Published list prices, Aug 2026 [Calculate your cost](https://blazingcdn.com/cdn-cost-calculator/?utm_source=blog&utm_medium=sidebar&utm_campaign=blog_sidebar&utm_content=compare_calc) ## Related posts [![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-02-2026-02-10-37-3194-PM.jpeg)](https://blog.blazingcdn.com/en-us/what-is-sni-server-name-indication-explained?hsLang=en-us) Learn ### [What Is SNI? Server Name Indication Explained](https://blog.blazingcdn.com/en-us/what-is-sni-server-name-indication-explained?hsLang=en-us) Server name indication (SNI) is a TLS extension in which the client writes the hostname it wants, such as ... Nov 2, 2026, 3:12:25โ€ฏPM [Read more](https://blog.blazingcdn.com/en-us/what-is-sni-server-name-indication-explained?hsLang=en-us) [![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-02-2026-10-01-57-8244-AM.jpeg)](https://blog.blazingcdn.com/en-us/503-service-unavailable-what-it-means-and-how-to-fix-it?hsLang=en-us) Learn ### [503 Service Unavailable: What It Means and How to Fix It](https://blog.blazingcdn.com/en-us/503-service-unavailable-what-it-means-and-how-to-fix-it?hsLang=en-us) HTTP 503 Service Unavailable means the server, or a proxy in front of it, is temporarily refusing requests because it ... Nov 2, 2026, 11:03:58โ€ฏAM [Read more](https://blog.blazingcdn.com/en-us/503-service-unavailable-what-it-means-and-how-to-fix-it?hsLang=en-us) [![BlazingCDN](https://blog.blazingcdn.com/hubfs/Logo/blog-logo-w.png)](https://blog.blazingcdn.com?hsLang=en-us) [๐Ÿ“˜ Learn](https://blog.blazingcdn.com/cdn-learn?hsLang=en-us) [๐Ÿ“Š Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [๐ŸŽฌ Video & Streaming](https://blog.blazingcdn.com/video-streaming-cdn?hsLang=en-us) [๐Ÿญ Industries](https://blog.blazingcdn.com/cdn-industry-insights?hsLang=en-us) [๐Ÿ’ฐ Pricing & Costs](https://blog.blazingcdn.com/cdn-pricing-and-cdn-costs?hsLang=en-us) [โšก Compare](https://blog.blazingcdn.com/cdn-comparison?hsLang=en-us) [๐Ÿ”’ Security](https://blog.blazingcdn.com/cdn-security?hsLang=en-us) [๐Ÿ› ๏ธ Tools](https://blog.blazingcdn.com/cdn-tools?hsLang=en-us) [โœ๏ธ Publish with us](https://blog.blazingcdn.com/publish-with-us?hsLang=en-us) in f ๐• โœ‰ Copyright ยฉ BlazingCDN |. All rights reserved. ```json { "@context" : "https://schema.org", "@id" : "https://blazingcdn.com/#organization", "@type" : "Organization", "description" : "High-volume CDN for video, live streaming, OTT/IPTV, software, games, SaaS and large-file delivery.", "logo" : { "@id" : "https://blazingcdn.com/#logo", "@type" : "ImageObject", "height" : 560, "url" : "https://blazingcdn.com/wp-content/uploads/2024/08/logo-560-560.png", "width" : 560 }, "name" : "BlazingCDN", "sameAs" : [ "https://www.linkedin.com/company/blazingcdn", "https://x.com/BlazingCdn", "https://www.reddit.com/r/BlazingCDN/", "https://www.wikidata.org/wiki/Q141711074" ], "url" : "https://blazingcdn.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/#website", "@type" : "WebSite", "inLanguage" : "en-US", "name" : "BlazingCDN Blog", "publisher" : { "@id" : "https://blazingcdn.com/#organization" }, "url" : "https://blog.blazingcdn.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/what-is-mtls-mutual-tls-authentication-explained#article", "@type" : "BlogPosting", "author" : { "@id" : "https://blog.blazingcdn.com/en-us/author/blazingcdn#person", "@type" : "Person", "description" : "Vadym Borovskyi is Chief Product and Marketing Officer at BlazingCDN, where he has led product strategy and growth since 2021. He has more than 11 years of experience in IT product management and B2B marketing. On this blog he writes about CDN pricing and egress costs, video and software delivery, cache configuration, and how teams evaluate and switch CDN providers. He is based in Warsaw, Poland.", "image" : "https://143144902.fs1.hubspotusercontent-eu1.net/hubfs/143144902/vadym-borovskyi.jpg", "jobTitle" : "Chief Product and Marketing Officer", "knowsAbout" : [ "Content Delivery Networks (CDN)", "CDN pricing", "Video streaming delivery", "Software and game distribution", "Cache optimization", "Product Management", "B2B Marketing", "Digital Marketing", "Pay Per Click Marketing (PPC)", "Google Ads", "Search Engine Marketing (SEM)", "Marketing Strategy", "Artificial Intelligence (AI)", "Cloud Management", "SaaS Development", "IT Consulting", "Computer Networking", "Project Management", "Startups" ], "name" : "Vadym Borovskyi", "sameAs" : [ "https://www.linkedin.com/in/axelt/" ], "url" : "https://blog.blazingcdn.com/en-us/author/blazingcdn", "worksFor" : { "@id" : "https://blazingcdn.com/#organization" } }, "dateModified" : "2026-11-02T16:17:22Z", "datePublished" : "2026-11-02T16:17:21Z", "description" : "What is mTLS? Learn how mutual TLS authentication uses two-way certificate verification to secure client-server communication.", "headline" : "What Is mTLS? Mutual TLS Authentication Explained", "image" : "https://143144902.fs1.hubspotusercontent-eu1.net/hubfs/143144902/Gemini-Blog/image-Nov-02-2026-04-15-39-7476-PM.jpeg", "inLanguage" : "en-us", "isPartOf" : { "@id" : "https://blog.blazingcdn.com/#website" }, "mainEntityOfPage" : { "@id" : "https://blog.blazingcdn.com/en-us/what-is-mtls-mutual-tls-authentication-explained", "@type" : "WebPage" }, "publisher" : { "@id" : "https://blazingcdn.com/#organization" }, "wordCount" : 1661 } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/what-is-mtls-mutual-tls-authentication-explained#breadcrumb", "@type" : "BreadcrumbList", "itemListElement" : [ { "@type" : "ListItem", "item" : "https://blog.blazingcdn.com/en-us", "name" : "Blog", "position" : 1 }, { "@type" : "ListItem", "item" : "https://blog.blazingcdn.com/en-us/what-is-mtls-mutual-tls-authentication-explained", "name" : "What Is mTLS? Mutual TLS Authentication Explained", "position" : 2 } ] } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/what-is-mtls-mutual-tls-authentication-explained#faq", "@type" : "FAQPage", "mainEntity" : [ { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "mTLS is TLS where both sides show a certificate. In normal HTTPS only the server proves its identity; with mutual TLS the server also asks the client for a certificate signed by a CA it trusts, and refuses the connection if the client cannot prove it holds the matching private key. It is widely used for service-to-service and origin traffic." }, "name" : "What is mTLS in simple terms?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "mTLS adds no extra round trip on TLS 1.3, because the certificate request and response travel inside the existing handshake flights. The added cost is a few kilobytes of certificate chain and one signature plus one verification. Resumed sessions using pre-shared keys skip the client signature, so steady-state latency impact is usually negligible." }, "name" : "Does mTLS add latency to the TLS handshake?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "mTLS is stronger than API keys for workload identity, because a key can be copied and replayed while an mTLS identity requires a private key that never leaves the client. API keys are simpler for third-party developers. Many production APIs use both: mutual TLS for the connection, plus certificate-bound tokens for per-user scope." }, "name" : "Is mTLS better than API keys for securing APIs?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "mTLS protects an origin by rejecting any TLS connection that does not present a client certificate the origin trusts, so attackers who find the origin address cannot bypass the edge. The protection is only meaningful if the certificate is unique to your account or zone; a certificate shared across all tenants of a provider proves very little." }, "name" : "How does mTLS protect a CDN origin server?" } ] } ```