HTTPS, SSL & Security
What is mTLS?
mTLS, mutual TLS, is an extension of the standard TLS protocol in which both the client and the server authenticate each other using SSL certificates: rather than the standard TLS model where only the server presents a certificate to the client. In standard TLS the client verifies the server’s identity through its certificate but the server accepts connections from any client without verifying the client’s identity. In mTLS both parties present certificates, the server proves its identity to the client and the client proves its identity to the server, before the encrypted connection is established.
The mutual in mTLS captures exactly this distinction, authentication is mutual rather than one-directional. Standard TLS provides one-way authentication, the server is verified, the client is anonymous. mTLS provides two-way authentication, both parties are verified by exchanging and validating certificates before any application data flows.
mTLS is primarily used in infrastructure and service-to-service communication contexts rather than in browser-to-website communication. When a payment processor needs to verify that incoming API requests come only from authorised clients, not just anyone who knows the API endpoint, mTLS provides that verification. When microservices communicate within an internal network and need to verify each other’s identity, not just encrypt the connection, mTLS provides that mutual assurance. When a zero-trust security model requires that every connection in the infrastructure be authenticated regardless of network position, mTLS provides the authentication layer.
How mTLS works
mTLS extends the standard TLS handshake by adding a client certificate exchange step, the server requests a certificate from the client and verifies it before the connection is established.
Standard TLS handshake review: in standard TLS the server presents its certificate during the handshake. The client verifies the certificate against its trust store, checking that it was issued by a trusted certificate authority, covers the domain being connected to, and has not expired. After successful server certificate verification the encrypted session is established. The server does not verify the client’s identity, it accepts connections from any client.
mTLS handshake additions: the mTLS handshake follows the same sequence as standard TLS with two additional steps.
After the server presents its certificate the server sends a CertificateRequest message, explicitly asking the client to present a certificate. The CertificateRequest message specifies what types of certificates the server will accept, which certificate authorities it trusts for client certificates.
The client responds with its own certificate, a client certificate issued for the client’s identity. The client also sends a CertificateVerify message, a cryptographic proof that the client possesses the private key corresponding to the public key in its certificate. This proof prevents a client from presenting a certificate it does not own.
The server verifies the client’s certificate, checking that it was issued by a trusted CA, that it is valid, and that the CertificateVerify proof is correct. If verification passes the mTLS handshake completes and the encrypted, mutually authenticated session is established. If the client does not present a certificate or presents an invalid one the server rejects the connection.
Certificate authorities for client certificates: for the server to trust client certificates the client certificates must be issued by CAs that the server trusts. In standard web PKI the same public CAs, DigiCert, Let’s Encrypt, and others, trusted by browsers are used. In mTLS deployments organisations typically run their own internal CA, a private CA not in public browser trust stores, specifically for issuing client certificates to their services and users. The server is configured to trust only this internal CA for client certificate validation, ensuring only entities that received certificates from the organisation’s internal CA can connect.
mTLS use cases
mTLS is used across a range of infrastructure and security contexts where mutual authentication between communicating parties is required.
API authentication: traditional API authentication uses API keys or OAuth tokens, the client includes a secret in the request that the server verifies. mTLS provides a fundamentally different authentication model, the client’s identity is proven cryptographically through its certificate during the TLS handshake rather than through an application-layer secret in the request. An API protected by mTLS only accepts connections from clients with valid client certificates, requests from clients without certificates are rejected before reaching the application.
mTLS API authentication is more robust than API key authentication in several ways. Client certificates cannot be accidentally leaked in logs, they are not included in request headers or URLs. Certificate revocation provides immediate access removal, when a client certificate is revoked the client can no longer connect regardless of what credentials it has. Certificate expiry provides automatic access rotation, clients must periodically obtain new certificates, preventing indefinitely valid credentials.
Microservices communication: in microservices architectures dozens or hundreds of services communicate with each other over internal networks. Traditional network security models trusted all traffic within the internal network, if a request arrived from inside the network perimeter it was assumed to be legitimate. This perimeter trust model is increasingly recognised as inadequate, once an attacker breaches the perimeter they can move laterally without resistance.
mTLS between microservices implements zero-trust security within the internal network, every service-to-service connection is authenticated regardless of network position. Service mesh technologies, Istio, Linkerd, Consul Connect, implement mTLS between all services automatically, provisioning certificates for each service, handling certificate rotation, and enforcing mTLS for all inter-service communication without requiring changes to application code.
Zero-trust network access: zero-trust security models treat every connection as potentially hostile regardless of source. Access to internal resources requires continuous authentication rather than relying on network position. mTLS is a core component of zero-trust implementations, every connection to internal services requires a valid client certificate proving the connecting entity’s identity. VPN replacements like Cloudflare Access and ZScaler implement mTLS-based access control as part of zero-trust architectures.
Webhooks and callbacks: when a service sends webhook notifications to customer endpoints mTLS allows the receiving endpoint to verify that the notification genuinely came from the sending service rather than from an attacker who discovered the webhook URL. The webhook sender presents a client certificate, the receiver verifies it against the sender’s known certificate before processing the notification. This prevents fake webhook injection attacks.
IoT device authentication: Internet of Things devices communicating with backend services use mTLS to authenticate the device before accepting its data or commands. A sensor that reports temperature data uses mTLS so the backend can verify the data comes from a genuine authorised sensor rather than from an attacker injecting fake readings. Each device receives a unique client certificate during provisioning, the backend trusts only certificates from its device provisioning CA.
mTLS and redirect management
mTLS has specific applications in redirect management infrastructure, primarily in securing the internal communication between components of redirect infrastructure and in protecting redirect management APIs.
Redirect management API protection: redirect management platforms provide APIs for configuring redirect rules, adding domains, creating redirects, updating destinations. These APIs must be secured against unauthorised access, an attacker who can modify redirect rules can redirect legitimate traffic to malicious destinations. mTLS protects management APIs by requiring client certificates from any system that calls the API, only systems provisioned with valid client certificates can configure redirect rules.
Internal infrastructure security: large-scale redirect management infrastructure involves multiple components, edge nodes that receive requests, rule evaluation engines, certificate management systems, configuration databases. Communication between these components benefits from mTLS, each component authenticates the others before accepting requests. Compromise of one component does not automatically allow it to communicate with other components without valid certificates.
CDN origin verification: when a CDN forwards requests to an origin server mTLS can verify that the origin server receives only requests that genuinely came through the CDN, not direct requests that bypass the CDN’s security rules and redirect enforcement. The CDN presents a client certificate when connecting to the origin. The origin verifies the certificate and accepts only connections from CDN infrastructure. Direct connections without the CDN’s certificate are rejected.
Cloudflare supports this as Authenticated Origin Pulls, the Cloudflare edge presents a client certificate when connecting to customer origin servers. Origins configured to require the Cloudflare certificate reject any connection that does not present it, ensuring all traffic reaches the origin through Cloudflare’s security layer including its redirect rules and DDoS protection.
Setting up mTLS
Implementing mTLS requires creating a certificate authority for client certificates, issuing client certificates to authorised clients, and configuring servers to request and verify client certificates.
Creating a private CA for client certificates: the first step in mTLS deployment is creating a certificate authority specifically for issuing client certificates. This is typically an internal CA not in public browser trust stores, its certificates are trusted only by servers explicitly configured to trust it. OpenSSL, cfssl, and small-step CA are common tools for creating internal CAs. Commercial PKI solutions and cloud PKI services, AWS Private CA, Google Cloud Certificate Authority Service, provide managed internal CA infrastructure.
Issuing client certificates: each client that needs to connect receives a certificate from the internal CA. The certificate is issued for the client’s identity, a service name, a device identifier, or a user identity depending on the context. The certificate contains the client’s public key and identity information and is signed by the internal CA’s private key. The client stores the certificate and corresponding private key securely, the private key must never leave the client.
Server configuration for client certificate verification: the server is configured to request client certificates during TLS handshakes and to verify them against the trusted CA. In Nginx:
nginx
ssl_client_certificate specifies the CA certificate that the server uses to verify client certificates. ssl_verify_client on requires all clients to present valid certificates, connections without certificates are rejected. ssl_verify_client optional requests certificates but does not reject connections without them, useful for mixed environments where some clients use mTLS and others do not.
Client configuration: clients are configured to present their certificate during TLS connections. In curl:
In HTTP client libraries the certificate and key are specified in the client configuration, the library handles including them in TLS handshakes automatically.
Certificate rotation and revocation: mTLS deployments require certificate lifecycle management, rotating certificates before expiry and revoking certificates when clients are decommissioned or compromised. Certificate rotation should be automated, manual rotation at scale is error-prone and operationally burdensome. Certificate revocation requires maintaining a Certificate Revocation List or OCSP responder that servers check when verifying client certificates.
mTLS vs other authentication methods
mTLS is one of several authentication mechanisms available for securing API and service communication, each with different trade-offs.
mTLS vs API keys: API keys are simple to implement and widely understood. A secret string is included in the request, in a header or query parameter. API key authentication is entirely in the application layer, no TLS configuration required beyond standard HTTPS. The limitation is that API keys are secrets that can be extracted from logs, configuration files, or intercepted if accidentally sent over HTTP. mTLS authenticates at the TLS layer, the client certificate is not included in the request and cannot be extracted from logs. Revocation is more immediate, revoking a certificate stops the client from connecting at the network layer.
mTLS vs OAuth tokens: OAuth tokens provide flexible, fine-grained authorisation, tokens can carry scopes limiting what operations a client can perform. Tokens are typically short-lived, reducing the window if they are compromised. mTLS provides strong authentication but less built-in authorisation flexibility, the server knows who is connecting but determining what that client is permitted to do requires additional application logic. Some deployments use mTLS for connection authentication alongside OAuth for fine-grained authorisation, combining the strengths of both.
mTLS vs IP allowlisting: allowing only specific IP addresses to reach an API endpoint is a simple access control approach. IP allowlisting is less robust than mTLS, IP addresses can be spoofed, NAT and CGNAT mean multiple clients share IP addresses, and clients with dynamic IP addresses cannot be reliably allowlisted. mTLS provides cryptographic identity verification that IP allowlisting cannot, the certificate proves identity in a way that IP addresses do not.
Checking mTLS configuration
Verifying that mTLS is correctly configured requires testing both client certificate presentation and server certificate verification.
Testing client certificate rejection: verify that connections without client certificates are rejected:
Without a client certificate this request should fail, the server should reject the connection. An mTLS-protected endpoint that accepts connections without client certificates is misconfigured.
Testing client certificate acceptance:
With a valid client certificate this request should succeed, the server accepts the connection and returns a response.
Testing invalid certificate rejection:
A certificate from an untrusted CA or an expired certificate should be rejected, the server should not accept connections with invalid client certificates.
OpenSSL detailed handshake inspection:
Shows the full TLS handshake details including certificate exchange, useful for diagnosing mTLS configuration issues at the protocol level.