상호 TLS(mTLS)란? 클라이언트 인증서 인증

2026-05-08

mtlsmutual-tlsclient-certificateapizero-trust

일반 HTTPS에서는 서버만 인증서로 신원을 증명합니다. 클라이언트(브라우저)는 익명이며 — 서버는 누가 연결하는지 모릅니다.

**상호 TLS(mTLS)**는 두 번째 단계를 추가합니다: 클라이언트도 인증서를 제출합니다. 양쪽이 서로를 인증합니다. 서버는 클라이언트의 인증서를 신뢰할 수 있는 CA와 대조하여 검증하고, 클라이언트는 서버의 인증서를 검증합니다 — 그래서 “상호”입니다.

일반 TLS vs 상호 TLS

	일반 TLS	상호 TLS (mTLS)
서버 신원 증명	✅ 인증서 + CA 서명	✅ 동일
클라이언트 신원 증명	❌ 익명	✅ 클라이언트 인증서
인증	단방향 (서버만)	양방향 (양쪽 모두)
사용 사례	공개 웹사이트	내부 API, 제로 트러스트
클라이언트 요구사항	브라우저만 있으면 됨	인증서 + 개인키
설정 복잡도	표준	높음 — 클라이언트 인증서 관리 필요

mTLS를 사용해야 하는 경우

서비스 간 통신

네트워크를 통해 서로 통신하는 마이크로서비스. mTLS는 URL을 아는 것만으로는 부족하고, 인가된 서비스만 연결할 수 있도록 보장합니다.

서비스 A ←──mTLS──→ 서비스 B
양쪽 모두 검증: "당신이 주장하는 사람이 맞는가?"

제로 트러스트 아키텍처

제로 트러스트에서는 기업 네트워크 내부에서도 어떤 네트워크 연결도 기본적으로 신뢰하지 않습니다. mTLS는 네트워크 수준 신뢰(방화벽, VPN)를 신원 수준 신뢰(인증서)로 대체합니다.

API 보안

API 키를 넘어서 민감한 API를 보호합니다. 도난된 API 키는 누구나 사용할 수 있습니다. 클라이언트 인증서는 특정 개인키에 바인딩되어 있어 도용과 사용이 더 어렵습니다.

IoT 기기 인증

제조 시 프로비저닝된 클라이언트 인증서로 기기가 백엔드에 연결합니다. 서버는 위조된 기기가 아닌 정품 기기와 통신하고 있음을 알 수 있습니다.

mTLS 작동 원리

클라이언트가 연결하고 TLS 핸드셰이크를 시작합니다 (일반 TLS와 동일)
서버가 인증서를 전송 — 클라이언트가 검증합니다 (일반 TLS와 동일)
서버가 클라이언트 인증서를 요청 — CertificateRequest 메시지를 전송
클라이언트가 인증서를 전송 — 서버가 신뢰할 수 있는 CA와 대조하여 검증
양쪽이 세션 키를 계산하고 암호화된 통신이 시작됩니다

3-4단계가 “상호”를 만드는 부분입니다.

Nginx mTLS 설정

server {
    listen 443 ssl;
    server_name api.example.com;

    # 서버 인증서 (일반 HTTPS와 동일)
    ssl_certificate     /etc/ssl/server-fullchain.pem;
    ssl_certificate_key /etc/ssl/server-privkey.pem;

    # 클라이언트 인증서 검증
    ssl_client_certificate /etc/ssl/client-ca.pem;  # 클라이언트 인증서에 서명한 CA
    ssl_verify_client on;                            # 클라이언트 인증서 필수

    # 선택: 클라이언트 인증서 정보를 앱에 전달
    proxy_set_header X-Client-DN $ssl_client_s_dn;
    proxy_set_header X-Client-Verify $ssl_client_verify;
}

mTLS vs 다른 인증 방법

방법	보안 수준	복잡도	추천 용도
API 키	낮음 (공유 가능)	낮음	공개 API, 속도 제한
OAuth/JWT	중간	중간	사용자 대면 API
mTLS	높음 (암호학적 바인딩)	높음	서비스 간 통신, 제로 트러스트
mTLS + JWT	최고	높음	전송 + 애플리케이션 수준 인증

mTLS와 GetHTTPS

GetHTTPS는 서버 인증서를 발급합니다 — 웹 서버가 신원을 증명하는 데 사용하는 인증서. 모든 HTTPS 웹사이트에서 사용하는 표준 SSL 인증서입니다.

mTLS를 위한 클라이언트 인증서는 일반적으로 사설 CA(조직의 내부 인증 기관)에서 발급됩니다. Let’s Encrypt 같은 공개 인증 기관이 아닙니다. Let’s Encrypt는 클라이언트 인증서를 발급하지 않습니다 — 공개 도메인용 서버 인증서만 발급합니다.

자주 묻는 질문

mTLS에 Let’s Encrypt를 사용할 수 있나요?

서버 인증서에는: 네. 클라이언트 인증서에는: 아닙니다. 클라이언트 인증서는 관리하는 사설 CA에서 발급해야 합니다 — 어떤 클라이언트가 인가되었는지 결정하기 위해서입니다. openssl, cfssl 또는 step-ca 같은 도구가 사설 CA 역할을 할 수 있습니다.

mTLS가 “클라이언트 인증서 인증”과 같은 건가요?

네. “상호 TLS”, “mTLS”, “양방향 TLS”, “클라이언트 인증서 인증”은 모두 같은 것을 가리킵니다 — TLS 핸드셰이크 중 양쪽이 인증서를 제출하는 것입니다.

mTLS가 API 키를 대체하나요?

대체할 수 있지만, 서로 다른 목적을 가집니다. mTLS는 전송 수준 신원(어떤 서비스가 연결하는지)을 증명합니다. API 키/JWT는 애플리케이션 수준 신원(어떤 사용자/권한인지)을 증명합니다. 많은 시스템이 심층 방어를 위해 둘 다 함께 사용합니다.

mTLS는 어디에서 주로 사용되나요?

Kubernetes(Istio/Linkerd를 사용한 서비스 메시), Cloudflare Access, AWS API Gateway(상호 TLS), Google Cloud의 BeyondCorp, 대부분의 엔터프라이즈 제로 트러스트 구현에서 사용됩니다.