Mutual Transport Layer Security (mTLS) is an extension to Transport Layer Security (TLS) that, in addition to verifying the server's, also verifies the connecting client's identity.

It's an extra layer of security that can be applied at the networking layer of the OSI model (layer 4) and is used extensively within architectures such as financial systems and service meshes.

This post will work through defining what mTLS is, work through some key components such as Certificate Authorities (CAs), Certificate Signing Requests (CSRs) and x.509 certificates, work through building an example application with your own chain of trust that includes a root CA, intermediary CA, client and server and round off with some real-world case studies.

To understand how mTLS extends TLS, let's recap how TLS 1.3 works at a high level.

The verification process of TLS 1.3 introduces a more streamlined handshake compared to earlier versions.

It reduces the number of round trips and encrypts more of the handshake itself while maintaining strong security guarantees.

In standard (one-way) TLS, only the server is authenticated.

A high-level summary of the one-way TLS 1.3 handshake:

In this process, the server proves its identity via the certificate, but the client remains anonymous.

In mutual TLS (mTLS), the handshake includes an optional client authentication step, allowing both parties to verify each other's identities.

A high-level summary of the mutual TLS 1.3 handshake:

TLS 1.3's enhancements make the handshake more efficient while preserving the flexibility to support mTLS when mutual identity verification is required.

In order to understand more on verification with a trusted root Certificate Authority, we need to better understand how certificates work in general and their relation to this process.

Let's start by defining some of the key terms:

Most of these terms require some form of memorization. To help ease that process, here is an analogy with airport security that can help you better visualize how each of these concepts play a role in mTLS.

For the sake of clarification in the analogy, the airport represents the server while you are the client. Where you need to get your create juices out a bit is understanding how the certificates (passports) are shown.

To best solidify these elements and the roles that they play in mTLS, we can build out our own local representation of these.

Based on our key terms, we know there are a few things that we would like to emulate locally:

We can make use of the openssl tool in order to create these certificates.

First, we need to create the private key that represents our Root CA's private key, then use that key to generate a x.509 certificate. Our Root CA in our case will be self-signed.

# Root private key
openssl genrsa -out certs/rootCA.key 4096

# Root self-signed certificate
openssl req -x509 -new -nodes -key certs/rootCA.key -sha256 -days 3650 \
  -subj "/CN=MyRootCA" -out certs/rootCA.crt
copy

We can the use it to create our Intermediary Certificate Authority. This process requires us to create a Certificate Signing Request (CSR) file.

The CSR file that create is then used alongside our root CA certificate and private key in order to create a our intermediate CA certificate.

To create the Intermediary CA private key, CSR and finally x.509 certificate, we can do the following:

# Intermediate CA config
cat > intermediate-ext.cnf <<EOF
[ext]
basicConstraints = critical, CA:TRUE, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
EOF

# Intermediate CA private key
openssl genrsa -out certs/intermediateCA.key 4096

# Intermediate CSR
openssl req -new -key certs/intermediateCA.key -out certs/intermediateCA.csr \
  -subj "/CN=MyIntermediateCA"

# Use Root CA to sign the intermediate's CSR
openssl x509 -req -in certs/intermediateCA.csr -CA certs/rootCA.crt -CAkey certs/rootCA.key \
  -CAcreateserial -out certs/intermediateCA.crt -days 1825 -sha256 \
  -extfile intermediate-ext.cnf
copy

We first setup a configuration file that is used during the signing process, then create the intermediary private key and certificate signing request before doing the signing to generate the certificate.

You might also be wondering at this point: Why use an intermediary certificate authority?

Here's the key idea:

So in practice:

In our case, we obviously have the representation of our root CA's certificate stored on our local system, but in practice this would be stored away securely.

Understanding why we don't need the root certificate private key should become clearer as we sign the client and server certificates and show them in use.

As a next step, we can follow a similar process for signing and creating the server certificate:

# Server config
cat > server-ext.cnf <<EOF
[ext]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:localhost
EOF

# Server private key
openssl genrsa -out certs/server.key 2048

# Server CSR
openssl req -new -key certs/server.key -out certs/server.csr \
  -subj "/CN=localhost"

# Sign with intermediate CA
openssl x509 -req -in certs/server.csr -CA certs/intermediateCA.crt -CAkey certs/intermediateCA.key \
  -CAcreateserial -out certs/server.crt -days 825 -sha256 \
  -extfile server-ext.cnf -extensions ext
copy

Note that we use the Intermediate Certificate Authority's certificate and private key for signing this certificate.

Now, let's do the same for the client:

# Client config
cat > client-ext.cnf <<EOF
[ext]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
EOF

# Client private key
openssl genrsa -out certs/client.key 2048

# Client CSR
openssl req -new -key certs/client.key -out certs/client.csr \
  -subj "/CN=client"

# Sign with intermediate CA
openssl x509 -req -in certs/client.csr -CA certs/intermediateCA.crt -CAkey certs/intermediateCA.key \
  -CAcreateserial -out certs/client.crt -days 825 -sha256 \
  -extfile client-ext.cnf -extensions ext
copy

Crucially, the server and client certs were signed by the intermediate, but clients (and the server) only trust the root.

We need to send the full chain when we present a cert. In order to do so, we need to combine our output certificate files:

# Concatenation of certificates
cat certs/server.crt certs/intermediateCA.crt > certs/server-chain.crt
cat certs/client.crt certs/intermediateCA.crt > certs/client-chain.crt
copy

Doing this will create two new certificate files that are inclusive of our intermediary certificate. This way, when the certificate requestor receives the cert, it can verify:

The concatenated files will be used as our certificates, while the public rootCA.crt file will be used as our CA cert in our mTLS configuration that you will soon see, however it's worth pointing out that you could also concatenate the intermediate and root CA certificats to be used as the CA certificate and then just use the server certificate. The verification process will have the same result.

# Create a full CA chain file for verification as an alternative
cat certs/rootCA.crt certs/intermediateCA.crt > certs/ca-chain.crt
copy

To see how all of this ties in together, let's see it at work with a simple Node.js application that can show when and how our certificates are used.

In our demonstration, we will have both a server receiving requests and a client making the requests over a mTLS.

For our tiny server, we'll run the following:

// server.ts
import https from "node:https";
import fs from "node:fs";
import type { TLSSocket } from "node:tls";

try {
  // Read the files
  const serverKey = fs.readFileSync("certs/server.key");
  const serverCert = fs.readFileSync("certs/server-chain.crt"); // Using individual cert
  const caCert = fs.readFileSync("certs/rootCA.crt"); // Using full CA chain

  function isTlsSocket(socket: unknown): socket is TLSSocket {
    return !!socket && typeof socket === "object" && "authorized" in socket;
  }

  const server = https.createServer(
    {
      key: serverKey,
      cert: serverCert,
      ca: caCert,
      requestCert: true,
      rejectUnauthorized: true,
    },
    (req, res) => {
      const tlsSocket = req.socket;

      if (!isTlsSocket(tlsSocket)) {
        console.error("Invalid socket properties");
        res.writeHead(500);
        res.end("Server error");
        return;
      }

      console.log("TLS Connection Details:");
      console.log(`- Authorized: ${tlsSocket.authorized}`);
      console.log(`- Protocol: ${tlsSocket.getProtocol()}`);
      console.log(`- Cipher: ${tlsSocket.getCipher().name}`);

      if (tlsSocket.getPeerCertificate) {
        const cert = tlsSocket.getPeerCertificate(true);
        console.log(`- Client Subject: ${cert.subject?.CN || "Unknown"}`);
        console.log(`- Client Issuer: ${cert.issuer?.CN || "Unknown"}`);
      }

      if (!tlsSocket.authorized) {
        console.error(`Auth Error: ${tlsSocket.authorizationError}`);
        res.writeHead(401);
        res.end(
          `Client certificate not authorized: ${tlsSocket.authorizationError}`
        );
        return;
      }

      res.writeHead(200);
      res.end("Hello, secure world with intermediate CA!");
    }
  );

  server.on("tlsClientError", (err) => {
    console.error("TLS Client Error:", err);
  });

  server.listen(3000, () => {
    console.log("✅ HTTPS server running at https://localhost:3000");
  });
} catch (err) {
  console.error("Failed to start server:", err);
}
copy

Within the http.createServer options, can configure our mTLS options. As you can probably infer from the naming, we make use of the public root certificate rootCA.crt alongside the server private key and our server-chain.crt.

We can demonstrate our client connecting over mTLS with the following script:

// client.ts
import https from "node:https";
import fs from "node:fs";
import axios from "axios";

// Read the files with better error handling
try {
  const clientKey = fs.readFileSync("certs/client.key");
  const clientCert = fs.readFileSync("certs/client-chain.crt"); // Using individual cert, not chain
  const caCert = fs.readFileSync("certs/rootCA.crt"); // Using full CA chain

  const agent = new https.Agent({
    key: clientKey,
    cert: clientCert,
    ca: caCert,
    rejectUnauthorized: true,
  });

  console.log("Starting mTLS client request...");

  axios
    .get("https://localhost:3000", {
      httpsAgent: agent,
      timeout: 10000, // Longer timeout for debugging
    })
    .then((res) => {
      console.log("✅ Server response status:", res.status);
      console.log("✅ Server response data:", res.data);
    })
    .catch((err) => {
      console.error("❌ Request failed:");
      if (err.response) {
        console.error(`Status: ${err.response.status}`);
        console.error(`Response: ${JSON.stringify(err.response.data)}`);
      } else if (err.request) {
        console.error("No response received from server");
      } else {
        console.error(`Error: ${err.message}`);
      }

      if (err.code) {
        console.error(`Error code: ${err.code}`);
      }

      // More detailed error info for TLS issues
      if (err.cause) {
        console.error("Error cause:", err.cause);
      }
    });
} catch (err) {
  console.error("Failed to read certificate files:", err);
}
copy

In our case, we're making use of the Axios package which accepts a httpsAgent argument, and we configure this agent using Node's https agent.

If we start our server, we can see the following:

$ npx tsx server.ts

> demo-node-mtls@1.0.0 server
> npx tsx server.ts

✅ HTTPS server running at https://localhost:3000
TLS Connection Details:
- Authorized: true
- Protocol: TLSv1.3
- Cipher: TLS_AES_256_GCM_SHA384
- Client Subject: client
- Client Issuer: MyIntermediateCA
copy

Now that the server is up and running, we can validate that our connection works:

$ npx tsx client.ts

> demo-node-mtls@1.0.0 client
> npx tsx client.ts

Starting mTLS client request...
✅ Server response status: 200
✅ Server response data: Hello, secure world with intermediate CA!
copy

You can find the example code on my GitHub.

We used the openssl binaries directly to work through our process of creating private keys, certificate signing requests and final signed certificates, but it's worth highlighting that you can do this programmatically.

Golang has a standard library package crypto/x509 that can generate certificates for you without external packages and is very nice.

I've also included an example of doing the exact same certificate chain we did but with Golang on the GitHub repository.

What makes this nice is that you can stand up your own private certificate authorities to manage the distribution of certicates.

For Node.js, packages like node-forge are available which provides support for x509 certificate generation.

Taken straight from their documentation:

It's a managed-service for your CA requirements if you wish not to manage that yourself. It offers APIs in order for you to interface with the service and can be desired if you don't wish to create a service yourself.

As an alternative to our approach, you could make use of AWS Private CA to create all of the certificates that we did ourselves, download them via AWS APIs and reenact the same demo that we did with our Node.js configurations.

Istio is a popular service mesh that extends capabilities for Kubernetes clusters.

One of its core features is to automative mTLS enforcement for inter-service and inter-node communication within microservices.

Within Istio service meshes running in sidecar mode, each Pod is deployed with a sidecar which injects an Envoy proxy.

The Istio daemon (istiod) distributes certificates between the sidecars as required and those proxies enforce mTLS between each other for secure, verified communication between Pods.

In this approach, you do not need to configure mTLS at the client-level. You make a request as you expect and the data plane will manage the mTLS verfication for you thanks to the proxies.

This transparency is what makes service meshes so powerful for implementing zero-trust security models without requiring changes to application code.

For more on its capabilities, read the Istio documentation on certificate management.

In our own walkthrough, we store all of the certificates locally.

It's worth taking a moment to highlight that well-planned and secure management of the entire certificate lifecycle is absolutely necessary.

Systems like Istio automate certificate issuance and rotation, and clients/servers are configured to trust the organization's CA.

In your own work, you'll need to ensure that you implement proper handling of keys and certificates.

Certificates have expirations and may require revocation, so ensure that if you are running your own certificate authority to cover these bases.

It's also worth clarifying that while mTLS adds extra security and authentication, it does not by itself guarantee non-repudiation of transmitted data​. You would still need to remedy this with key signatures on request data. I have an entire section on this in my blog post Roll Your Own API Keys.

Mutual TLS (mTLS) builds on the strong foundation of TLS by introducing client verification, enabling two-way trust in secure communication. Whether you're managing communications between services in a microservices architecture or securing client-server interactions in highly regulated industries, mTLS provides an effective layer of defense.

By understanding the roles of certificate authorities, certificate signing processes, and the chain of trust, you can confidently implement mTLS in your applications.

mTLS can introduce operational complexity, but in turn it offers strong identity assurance and encryption that can be foundational for zero-trust architectures and highly secure systems.

Photo credit: jrkorpa