mTLS
securityFull Name: Mutual TLS
Definition
Mutual TLS (mTLS), also known as two-way TLS or client certificate authentication, is an extension of the standard TLS protocol where both the client and the server authenticate each other using X.509 certificates during the TLS handshake. While standard TLS only requires the server to present a certificate (proving the website is who it claims to be), mTLS requires the client to also present a certificate, enabling the server to verify the client's identity. In the EUDI Wallet ecosystem, mTLS is a fundamental security mechanism used to protect inter-service communication within backend infrastructure, authenticate wallet instances during credential issuance, and secure communications between trust framework components.
How mTLS Works: The Handshake Process
The mTLS handshake extends the standard TLS handshake with additional certificate exchange steps. First, the client connects to the server, and the server presents its certificate. The client verifies the server's certificate against its trusted certificate authority (CA) list, as in standard TLS. Then, the server requests the client's certificate. The client presents its certificate, and the server verifies it against its own trusted CA list. Only if both verifications succeed does the encrypted connection proceed.
This two-way verification provides several security guarantees beyond standard TLS. The server knows with cryptographic certainty which client is connecting, not just that some client is connecting. The client knows it is communicating with the legitimate server. Both parties can be confident that no man-in-the-middle attacker has intercepted the connection, because such an attacker would not possess the private key for either certificate.
For EUDI Wallet infrastructure, certificate management is typically automated through certificate authorities operated as part of the trust framework. Each microservice receives its own certificate identifying its role and authorized access level. These certificates are short-lived (hours to days) and automatically rotated to minimize the impact of any certificate compromise.
The key rotation of mTLS certificates is automated in modern deployments through tools like cert-manager in Kubernetes or built-in certificate management in service meshes. This ensures that even if a certificate is compromised, its useful lifetime is extremely limited.
mTLS in EUDI Wallet Backend Infrastructure
Within EUDI Wallet backend deployments, mTLS serves as the primary mechanism for zero-trust networking. In a zero-trust architecture, no service is trusted by default based on network location -- every service must prove its identity for every connection. mTLS provides this proof through certificate-based mutual authentication.
Service mesh technologies like Istio, Linkerd, or Consul Connect implement mTLS transparently for all service-to-service communication within a Kubernetes cluster. Sidecar proxy containers are injected alongside each application container, automatically handling certificate management, TLS termination, and peer verification. The application code itself does not need any modification to benefit from mTLS protection.
This transparent mTLS approach is particularly valuable for EUDI Wallet infrastructure because it ensures that sensitive identity data flowing between services (credential attributes, signing key references, revocation status) is always encrypted and authenticated, regardless of whether individual service developers remembered to implement security measures in their code.
Network policies combined with mTLS provide defense in depth. Even if an attacker compromises one service and obtains its mTLS certificate, Kubernetes network policies prevent that service from communicating with services it is not authorized to access. The compromised credential issuance service cannot reach the audit logging system because network policies block the connection, regardless of the certificate it presents.
mTLS for OAuth 2.0 Client Authentication
RFC 8705 defines how mTLS can be used for OAuth 2.0 client authentication, replacing traditional client secrets with certificate-based authentication. In the EUDI Wallet ecosystem, this is used when wallet instances authenticate to authorization servers during the OpenID4VCI credential issuance flow.
When a wallet app requests a credential, it establishes an mTLS connection to the issuer's authorization server. The wallet presents a client certificate that proves its identity as a legitimate, attested wallet instance. The authorization server verifies this certificate against the trusted wallet provider CAs in the EUDI trust framework. This is more secure than client secret authentication because the private key never leaves the device (and ideally is stored in hardware-backed secure storage).
Certificate-bound access tokens (RFC 8705 Section 3) further strengthen this by binding the issued access token to the client's TLS certificate. Even if the access token is intercepted, it cannot be used from a different TLS connection because the server will verify that the presenting client's certificate matches the certificate hash embedded in the token. This prevents token theft and relay attacks.