TLS vs mTLS | Differences, Handshake (TLS 1.3) and When to Use in APIs and Microservices

TLS is the web’s standard “padlock”: it encrypts traffic and authenticates the server. However, in a world of B2B APIs, microservices and IoT, knowing who is calling your application is as critical as protecting data in transit. The problem? Standard TLS does not authenticate the client.

This is where mTLS (Mutual TLS) comes in. It keeps TLS’s strong encryption but requires the client to also present a digital certificate and prove possession of a private key. In this guide, we explore why mTLS is the foundation of Zero Trust and how to implement it with performance at the Edge.

Key Takeaways (Practical Summary)

• Standard TLS: The client trusts the server. Ideal for public web.
• mTLS: Client and server trust each other. Essential for machine-to-machine communications.
• TLS 1.3 Handshake: Faster and more private, encrypting certificates to avoid metadata leakage.
• Edge Advantage: Terminating mTLS at the Edge avoids CPU exhaustion at your origin.

What is Standard TLS — and what are its limits

In standard TLS (or one-way TLS), the server presents an X.509 certificate and the client verifies validity, the chain of trust and the host name.

• chain of trust up to a trusted CA
• validity (notBefore / notAfter)
• host name (SAN/CN) matching the accessed domain
• revocation (when enabled, via OCSP/CRL)

With this you get:

• confidentiality (encrypted traffic)
• integrity (protection against tampering)
• server authentication (the client confirms who it is talking to)

What standard TLS does not solve on its own: client authentication.
The server knows the channel is secure, but still relies on application methods (API Keys, JWT, OAuth2) to know who the user or service on the other end is.

What is mTLS (Mutual TLS)

mTLS (Mutual TLS) is an extension of the model: both client and server present certificates and validate each other. The client does not merely “show a credential”; it must perform a cryptographic signature during the handshake to prove possession of the private key corresponding to the presented certificate. This prevents an attacker from copying a certificate and trying to reuse it elsewhere.

The mTLS model extends trust: both parties validate each other. In the mTLS flow, it is not enough for the client to “show a credential”; it must perform a cryptographic signature during the handshake to prove possession of the private key corresponding to the presented certificate.

In practice:

1. the client validates the server’s certificate (as in standard TLS);
2. the server requests a client certificate;
3. the client presents its certificate;
4. the client proves possession of the private key (the crucial point).

This proof of possession is what makes mTLS so attractive in Zero Trust environments, B2B integrations and service-to-service communication: it’s not enough to “have a credential”; you must sign the handshake.

mTLS vs TLS: Main Differences

TLS 1.3 Handshake: Step-by-Step with mTLS

TLS 1.3 brought a massive evolution in privacy. While in TLS 1.2 certificates were sent in cleartext (allowing a network observer to know which service was being accessed), in 1.3 they are encrypted right after the first contact.

The Detailed Flow

1. ClientHello: The client starts by sending versions and key-exchange parameters.
2. ServerHello: The server finalizes parameters and, from here, communication is encrypted.
3. EncryptedExtensions: Protocol extensions are sent protected.
4. CertificateRequest (mTLS trigger): The server formally requests the client’s certificate.
5. Certificate (Server): The server sends its identity (now encrypted from external observers).
6. CertificateVerify (Server): The server signs the handshake, proving ownership of the private key.
7. Certificate (Client): The client responds with its certificate.
8. CertificateVerify (Essence of mTLS): The client signs the handshake transcript. This prevents an attacker from copying the certificate and trying to reuse it elsewhere.
9. Finished: Connection established.

Pro Tip (Performance & 0-RTT): TLS 1.3 allows 0-RTT (Zero Round Trip Time) mode for ultra-fast reconnections. However, when using mTLS with 0-RTT, ensure your Edge infrastructure has protection against replay attacks, ensuring sensitive requests (like financial transactions) are not processed twice inappropriately.

mTLS vs API Keys and OAuth2

Why mTLS wins over API Keys?

API Keys are easy to implement but vulnerable: they leak in logs, screenshots and repositories. mTLS requires possession of the private key, which can be protected in hardware (HSM/TPM), making credential exfiltration much more complex.

Does mTLS replace OAuth2?

No, they complement each other. mTLS authenticates the “machine” (service identity), while OAuth2 governs “authorization” (what that service can do). Mature architectures use mTLS for the channel and OAuth2 for scopes and delegations.

mTLS changes the game because the client does not “show a secret”; it must prove possession of a private key during the handshake. When keys are hardware-protected (TPM/HSM/secure element) or non-extractable, you greatly reduce the risk of exfiltration and reuse.

Practical rule:

• API Key: prototype/low criticality (or supplemental)
• mTLS: strong identity for B2B, microservices, IoT and critical infra

Where it makes sense to use mTLS

mTLS is especially useful when you need high confidence in the caller’s identity:

• Microservices / service-to-service: ensure service A only talks to service B
• B2B APIs: partners and integrations with strong identity
• Corporate IoT: authenticate devices (sensors, gateways, cameras) by certificate
• Regulated environments: open finance, healthcare, telecom, government
• Zero Trust: reduce implicit trust in internal networks

Conversely, for the public web (browser/end user), mTLS often presents UX and certificate distribution challenges.

Practical Example: mTLS Policies on Azion

Implementing mTLS at the origin can cause latency spikes and CPU consumption. The recommended strategy is to terminate mTLS at the Edge. The Azion Firewall validates the certificate and injects metadata (like the Fingerprint or Subject DN) into secure headers so your application can make decisions.

Below, an example Function to validate specific identities:

/**
 * Azion Function: mTLS Identity Enforcement
 * The Firewall must be configured to forward certificate metadata
 * in headers (e.g., X-Azion-Client-Cert-Subject)
 */
async function handleRequest(request) {
  const clientSubject = request.headers.get('x-azion-client-cert-subject');
  const clientFingerprint = request.headers.get('x-azion-client-cert-fp');
  // 1. Block if the certificate is missing
  if (!clientSubject) {
    return new Response('Mutual TLS Authentication Required.', { status: 401 });
  }
  // 2. Identity Validation (CN - Common Name)
  // Example: Allow only Acme's payments service
  if (!clientSubject.includes('CN=payments-service,O=Acme')) {
    return new Response('Forbidden: Service identity not authorized.', { status: 403 });
  }
  // 3. Revocation Check (Instant Denylist)
  // Query a denylist cached at the Edge for high performance
  const isRevoked = await checkRevocation(clientFingerprint);
  if (isRevoked) {
    return new Response('Unauthorized: Certificate revoked.', { status: 401 });
  }
  // Identity validated! Forward to origin with a trusted header
  const headers = new Headers(request.headers);
  headers.set('X-Verified-Service', 'payments-v1');
  return fetch(request.url, new Request(request, { headers }));
}

Certificate Management: The Achilles’ Heel

mTLS is only sustainable with automation. In large-scale environments, consider:

• Short-Lived Certificates: Reduce the need to consult heavy CRLs/OCSP.
• Automated Rotation: Use tools that renew certificates without human intervention.
• Edge Denylist: Use Azion’s cache storage to keep revoked certificate lists updated globally in milliseconds.

CRL vs OCSP: practical view

• CRL (Certificate Revocation List)
  • Pros: simple, cacheable
  • Cons: can grow; there is a window between update and propagation
• OCSP (Online Certificate Status Protocol)
  • Pros: per-certificate on-demand check
  • Cons: depends on the responder; can add latency if queried frequently

Strategies that work well in production

1. Short-lived certificates
   Reduces the need for emergency revocation. If a certificate expires quickly, the risk window shrinks.
2. Automated rotation/renewal
   The goal is to make renewal as automatic as renewing a server certificate.
3. Distributed denylist (serial/fingerprint)
   For immediate blocking (e.g., incident). It’s common to expose an endpoint/service for revocation consulted by the Edge with cache/TTL.

How to mitigate revocation and reduce latency at the Edge

Terminating TLS/mTLS at the Edge helps because you can:

• concentrate chain validation and policies in a single point
• use cache for checks (CRL/OCSP/denylist)
• block invalid traffic before it reaches the origin

If your origin is suffering from handshakes, CPU spikes or distributed policy checks across multiple services, consider moving mTLS enforcement to the Edge.

Troubleshooting: common implementation errors

Below is a checklist that resolves most production issues.

1) Client does not present a certificate

Common causes

• mTLS was not required (no CertificateRequest)
• client has no certificate configured (empty store)
• incompatible policy/ciphers/versions

How to debug

• enable logs on the TLS terminator (Edge)
• test with openssl s_client using -cert and -key

2) “unknown ca” / chain failure

Common causes

• client’s CA is not in the server/Edge truststore
• incomplete chain (missing intermediates)

How to fix

• add correct root/intermediate CAs
• validate the chain with X.509 inspection tools

3) Expired / not yet valid certificate

Common causes

• rotation failed
• clock skew (NTP) in restricted environments

How to fix

• sync NTP
• automate renewal/rotate in advance

4) Revocation: client should be blocked but still accesses

Common causes

• CRL/OCSP not enabled
• cache TTL too long
• absence of an immediate denylist

How to fix

• enable revocation checking where applicable
• reduce TTL and add denylist by serial/fingerprint

FAQ (People Also Ask)

Does mTLS slow down the application?

mTLS increases handshake cost (public-key operations), but with TLS 1.3, resumption and termination at the Edge, the impact is usually small. Also, removing the cost from the origin is one of the biggest operational advantages.

Can I use mTLS in common browsers?

It is possible, but difficult for end users: certificate distribution/installation, poor UX (prompts), and varied mobile support. mTLS is better suited for B2B and service-to-service communication.

Does mTLS replace OAuth2?

Not necessarily. mTLS authenticates the client (machine/service) with high confidence; OAuth2 governs authorization and scopes. In many architectures, they complement each other.

What to do if a client certificate is compromised?

Revoke via CRL/OCSP (when applicable) and/or immediately block via denylist by serial/fingerprint. When possible, prefer short-lived certificates with automated rotation to reduce the risk window.

Conclusion

mTLS is not just “another protocol”; it is the foundation of mutual trust in distributed systems. By moving certificate validation to the Edge, you gain Zero Trust security without the performance cost of asymmetric cryptography at your origin.

Ready to implement low-latency mTLS? Explore Azion Firewall documentation or contact our specialists to architect your API security.