X.509 and mTLS for Service Identity

In backend distributed systems, identifying who is speaking is as critical as securing what is being spoken. While Transport Layer Security (TLS) is standard for encrypting data in transit, it traditionally protects only the server's identity. Mutual TLS (mTLS) extends this by requiring both the client and the server to present X.509 certificates, creating a bidirectional trust relationship. This guide details the mechanism of X.509 certificates in mTLS, focusing on how platform engineers should structure identities using Subject Alternative Names (SANs) and manage them through a Private Certificate Authority (PCA).

The Mechanism of Mutual Trust

Standard TLS involves a client verifying the server’s certificate against a trusted root. mTLS adds a second verification step: the server must also verify the client’s certificate. This is not merely an authentication layer; it is a cryptographic binding of identity to the connection session.

The mechanism works during the TLS handshake. When a client connects to a service, the server sends its certificate chain. The client validates this chain against its trust store. Then, the server requests the client’s certificate. The client presents its certificate, and the server validates it against its own trust store. Only if both validations succeed does the encrypted channel open.

This mutual verification prevents unauthorized services from connecting, even if they know the network path. It shifts security from perimeter-based (firewalls) to identity-based (cryptographic credentials). A valid X.509 certificate serves as the primary credential in this process, ensuring that the entity presenting it is who it claims to be.

Identifying the Service: SANs Over CNs

An X.509 certificate contains metadata that binds a public key to an identity. Historically, the Common Name (CN) field was used for this purpose. However, RFC 6125 deprecated CN for server authentication, mandating the use of Subject Alternative Names (SANs) instead.

In a backend service context, the SAN field is the primary identifier. It can contain DNS names, IP addresses, or Uniform Resource Identifiers (URIs). For example, a service named payment-service in a Kubernetes cluster might have a certificate with the SAN dns:payment-service.default.svc.cluster.local.

When the mTLS handshake occurs, the server does not just check if the certificate is valid; it checks if the SAN matches the expected identity. If a rogue service presents a valid certificate but with a mismatched SAN (e.g., dns:rogue-service), the connection is rejected. This granular identification ensures that even if a certificate is compromised, the attacker cannot impersonate other services unless they also possess the corresponding private key.

The Private Certificate Authority (PCA)

Public Certificate Authorities (CAs) like Let’s Encrypt are designed for internet-facing domains. Internal services require a Private CA. A PCA is an internal infrastructure component that issues, signs, and manages certificates for internal workloads.

The PCA acts as the root of trust. All services are configured to trust the PCA’s root certificate. When a service needs a certificate, it requests a Certificate Signing Request (CSR) from the PCA. The PCA verifies the requester’s identity (often via an API token or workload identity) and signs the certificate with its private key.

A critical aspect of using a PCA is short-lived certificates. Unlike public CAs that issue certificates valid for 90 days, internal services should use certificates valid for minutes or hours. Short lifetimes limit the window of opportunity for an attacker who compromises a private key. Automated rotation is essential; manual certificate management is prone to error and expiration, leading to outages.

Revocation and Validation

Not all valid certificates should be trusted. If a private key is compromised, the certificate must be revoked. X.509 defines two primary mechanisms for this: Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP).

CRLs are periodically published lists of revoked certificate serial numbers. Clients download the list and check if their certificate’s serial number is present. OCSP is a real-time protocol where a client queries an OCSP responder to ask if a specific certificate is valid.

In practice, many internal service meshes disable revocation checking due to latency and complexity concerns. They rely on short certificate lifetimes and network segmentation instead. However, this is a trade-off. Without revocation, a compromised certificate remains valid until it expires. Platform engineers must decide whether the operational simplicity of skipping revocation outweighs the security risk of delayed key compromise detection.

Conclusion

Implementing mTLS with X.509 certificates is not just about generating keys. It requires a structured approach to identity management. Use SANs for precise service identification, employ a private CA for secure issuance, and enforce short lifetimes for automated rotation. Additionally, consider the implications of revocation policies when designing your security model. By treating service identity as a first-class citizen in your backend architecture, you create a strong defense against unauthorized access and lateral movement.