mTLS 상호 인증: 클라이언트도 신원을 증명하는 양방향 신뢰

mTLS는 일반 TLS와 무엇이 다른가요?

일반 TLS는 서버만 인증서로 신원을 증명하지만, mTLS는 클라이언트도 인증서를 제시해 양쪽이 서로를 검증합니다. 우리가 웹사이트에 HTTPS로 접속할 때, 서버는 TLS 인증서로 자신이 진짜임을 증명하죠. 하지만 접속하는 클라이언트는 인증서가 없습니다. 로그인과 비밀번호로 사용자를 확인하긴 하지만, 그것은 연결이 맺어진 뒤 애플리케이션 단계에서 벌어지는 일이에요.

mTLS는 연결 단계에서 클라이언트도 인증서와 개인키 쌍으로 신원을 증명하게 만듭니다. 서버와 클라이언트가 서로의 인증서를 확인한다는 뜻이죠. 한 가지 짚어 둘 점은, 'mTLS'가 업계에서 굳어진 표현일 뿐 클라이언트 인증서 인증 자체는 이미 TLS 표준(TLS 1.2·1.3)에 정의된 기능이라는 것입니다. 새 프로토콜이 아니라, 표준 TLS의 클라이언트 인증 기능을 양방향으로 활용하는 방식이에요. 서버 인증과 핸드셰이크의 기본 원리는 TLS 1.3 핸드셰이크 글에서 함께 볼 수 있습니다.

mTLS 핸드셰이크는 어떻게 진행되나요?

서버 인증서를 검증한 뒤, 서버가 클라이언트 인증서를 요청하고, 클라이언트가 인증서와 서명을 제출하면 서버가 검증해 접근을 허용합니다. 일반 TLS는 네 단계로 요약돼요. 클라이언트가 접속하고, 서버가 인증서를 제시하고, 클라이언트가 그 인증서를 검증한 뒤, 암호화된 연결로 통신하죠. mTLS는 여기에 클라이언트를 검증하는 단계가 더해집니다.

핵심은 서버가 먼저 요청한다는 점입니다. 서버는 CertificateRequest 메시지로 클라이언트에게 인증서를 요구하고, 클라이언트는 자기 인증서와 함께 CertificateVerify, 즉 개인키로 만든 서명을 보냅니다. 인증서 파일만 갖고 있는 것으로는 부족하고, 그 인증서에 대응하는 개인키를 실제로 보유하고 있음을 서명으로 증명해야 하죠. 서버가 이 서명과 인증서를 검증하면 비로소 접근을 허용합니다.

mTLS 인증서는 누가 발급하나요?

보통 조직이 자체 CA(사설 PKI)로 발급합니다. 클라이언트 신원까지 공개 CA가 보증할 필요가 없기 때문이죠. 일반 TLS의 서버 인증서는 외부의 공개 인증기관(CA)이 도메인 소유를 확인해 발급합니다. 아무 서버나 은행을 사칭하지 못하도록, 신뢰할 제3자가 보증하는 구조예요.

하지만 mTLS의 클라이언트 인증서는 사정이 다릅니다. 조직 내부의 서비스·기기·직원을 검증하는 용도라, 그 조직이 스스로 CA 역할을 맡는 경우가 많죠. 자체 서명한 루트 인증서를 만들고, 클라이언트와 서버 인증서를 그 루트에 대응시켜 신뢰 목록(트러스트 스토어)으로 관리합니다. 다만 항상 자체 CA인 것은 아니에요. 오픈뱅킹처럼 규제가 있는 영역에서는 지정된 CA가 발급한 클라이언트 인증서를 요구하기도 합니다.

mTLS는 언제 쓰고 어떤 공격을 막나요?

제로트러스트·서비스 간 인증·API 보안·IoT에 쓰이고, 중간자와 스푸핑 공격을 직접 막습니다. mTLS는 로그인 절차만으로는 부족한 곳에서 빛을 발해요. 사용자·기기·서버를 기본적으로 아무도 믿지 않는 제로트러스트 환경, 서버끼리 통신하는 서비스 간(마이크로서비스) 인증, 외부에 열린 API 보안, 그리고 로그인 화면이 없는 IoT 기기 인증이 대표적입니다.

방어 측면에서 mTLS가 직접 막는 것은 중간자(on-path)와 스푸핑입니다. 중간에 끼어든 공격자는 양쪽 어디에도 인증서로 자신을 증명하지 못하고, 서버나 사용자를 위장하려 해도 유효한 인증서가 없으면 통하지 않죠. 비밀번호를 노리는 공격도 무력화됩니다. 설령 피싱이나 유출로 비밀번호를 손에 넣어도, 클라이언트 인증서와 개인키가 없으면 그 비밀번호는 쓸모가 없기 때문이에요. 콘텐츠 접근을 애플리케이션 단계에서 제어하는 서명된 URL·토큰 인증과 함께 보면 인증의 층위가 정리됩니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)