Certificate Deep Dive Series 3: Zero Trust and mTLS

mTLS (Mutual TLS) is a bidirectional authentication method in which the server and client both verify each other's certificates. While ordinary TLS only proves the server's identity, mTLS also verifies the requesting party in service-to-service communication, redrawing the trust boundary of internal connections.

Zero Trust is a security philosophy that does not trust network location and requires authentication, authorization, and encryption for every connection. This is why mTLS serves as a core technology in environments with heavy internal communication, such as microservices, API security, IoT device authentication, admin access, and B2B integration.

The handshake is explained based on TLS 1.2, and it becomes more streamlined under TLS 1.3. The server sends a Certificate Request along with its certificate to demand a client certificate, and the client proves possession of its private key with its certificate and a Certificate Verify signature; the server then checks CA trust, validity period, revocation status, and signature validity before allowing communication.

The biggest challenge in practice is certificate lifecycle management.

• Manual management is simple but clearly hits its limits as scale grows.
• Configuration Management (such as Ansible) and Certificate Manager (such as Vault) automate deployment.
• Service Mesh (Istio, Linkerd) offloads certificate issuance and renewal to sidecar proxies, applying mTLS without any code changes.

The article also presents an example of manually building a Root CA -> server certificate -> client certificate chain with OpenSSL, but notes that as the number of services grows, the burden of managing renewal, deployment, and revocation increases sharply. To reduce this burden, NHN Cloud Private CA simplifies operations by combining issuance, ACME automatic renewal, CRL/OCSP, centralized management, and integration with Service Mesh's External CA.