일반적인 서버 인증 HTTPS에서는 클라이언트가 서버 인증서를 검증해 접속한 서버의 이름과 신뢰 경로를 확인합니다. 상호 TLS 인증(mTLS)은 여기에 클라이언트 인증서를 서버가 요청·검증하는 반대 방향의 인증을 더합니다.
클라이언트 인증서가 유효하더라도 이는 TLS 단계의 인증 근거이지, API의 모든 자원 권한을 자동으로 부여하지 않습니다. 운영 구현은 서버·프록시 설정과 인증서 검증·애플리케이션 계정 매핑을 따로 확인해야 합니다. 사례는 직접 만든 교육용 예시입니다.
HTTPS라는 접속이 항상 양쪽 인증을 뜻하지 않습니다
브라우저가 https://api.example에 연결하면 보통 서버가 인증서를 제시하고, 클라이언트가 이름·유효기간·인증 경로를 확인합니다. 이렇게 서버 신원을 확인하고 암호화된 통신을 만든 연결은 서버 인증 TLS로 볼 수 있습니다. 서버가 클라이언트 인증서를 요구하지 않았다면, TLS 연결만으로 클라이언트 장치나 사용자 신원이 인증됐다고 말할 수 없습니다. 사용자가 앱에 별도로 로그인했더라도 그것은 TLS client certificate 인증과 다른 인증 계층입니다.
mTLS에서는 서버도 클라이언트의 인증서를 요청하거나 설정에 따라 반드시 요구합니다. 클라이언트는 서버 인증서를 확인하고, 서버는 클라이언트가 제출한 인증서의 신뢰 경로·용도·유효기간 및 조직 정책을 검증합니다. Microsoft Learn의 ASP.NET Core 자료는 client certificate가 TLS 수준에서 다뤄지고 서버가 이를 요구할 수 있다고 설명합니다. 실제 인증서는 사용자나 서비스 계정으로 매핑될 수 있지만 그 매핑 규칙은 구현에 따라 다릅니다.
| 상황 | TLS 연결 결과 | 애플리케이션 판단 | 답안에 쓸 근거 |
|---|---|---|---|
| API 서버 인증서는 신뢰되고, client certificate를 요청하지 않음 | 서버 신원은 확인 가능 | 사용자·서비스 주체는 다른 로그인 절차에서 판단 | 이 연결만으로 클라이언트 인증서 기반 identity는 확인되지 않음 |
| mTLS를 요구했으나 클라이언트 인증서가 없거나 신뢰 경로가 맞지 않음 | 필수 인증 실패로 요청을 진행하지 못함 | API 처리 전 실패 | client certificate 요구·경로 검증 결과 확인 |
| 클라이언트 인증서는 검증되고 ‘batch-agent’로 매핑됨 | 양측 TLS 인증이 성립할 수 있음 | invoice:read 권한이 없으면 API는 거부 가능 | TLS 인증과 endpoint authorization은 별도 결정 |
인증서가 있어도 허용된 API 동작은 따로 봅니다
가상 주문 API가 외부 사용자의 서버 인증 연결을 받는다고 합시다. 일반 HTTPS 연결에서는 클라이언트가 api.example 서버 인증서를 확인합니다. 서버는 암호화된 채널을 제공하지만, 이 설정만으로 접속한 고객 이름을 인증서에서 읽어내지는 않습니다. 별도의 세션 쿠키나 OAuth 토큰 등으로 사용자를 인증할 수 있습니다. 이 두 방식을 혼용하지 마세요. ‘HTTPS로 접속했다’는 사실은 보통 클라이언트가 서버를 검증했다는 근거이지 서버가 그 클라이언트의 인증서를 검증했다는 증거는 아닙니다.
이제 내부 배치 작업이 같은 API에 mTLS로 연결한다고 바꿔 보겠습니다. 서버는 특정 신뢰 CA에서 발급한 client certificate와 적절한 Client Authentication 용도를 요구합니다. 인증서의 notBefore/notAfter, 서명 경로, 폐기 상태와 정책이 통과하고, 그 주체를 batch-agent 계정으로 매핑할 수 있습니다. 하지만 이 계정은 주문 조회만 허용될 수 있습니다. 새 송장을 삭제하려는 요청이 거부돼도 TLS 인증 실패라고 단정하면 안 됩니다. TLS가 주체를 확인한 후 애플리케이션 권한이 요청을 거절한 상황일 수 있습니다.
접속 로그를 다섯 단계로 분해합니다
- 서버가 client certificate를 요청했는지, 필수인지, 설정이 적용된 endpoint가 어디인지 확인합니다.
- 서버 인증서 검증 결과와 클라이언트 인증서 검증 결과를 각각 기록합니다.
- 클라이언트 인증서가 어떤 주체·계정으로 매핑됐는지 확인합니다.
- 요청한 API 자원·동작이 해당 주체의 인가 정책을 통과했는지 별도 확인합니다.
- TLS 종료 프록시가 있으면 어느 장비가 인증했고 앱에 신뢰할 수 있는 identity를 전달했는지 확인합니다.
인증서의 notBefore와 notAfter는 RFC 5280의 시간 범위일 뿐, 인증서의 실제 소유자에게 특정 행동 권한을 부여하는 값이 아닙니다. CA 경로를 확인했다고 조직의 모든 서비스가 이 인증서를 신뢰하는 것도 아닙니다. 인증서 정책, Extended Key Usage, 계정 매핑, 허용 endpoint와 요청 권한을 순서대로 살펴야 합니다. 또 앞단 로드밸런서에서 TLS를 종료하면 원본 client certificate가 뒤의 애플리케이션에 자동 전달되지 않을 수 있으므로, 배포 구조와 전달된 사용자 정보의 신뢰 경계를 별도로 기록합니다.
클라이언트 인증서 제시를 곧바로 사용자 로그인 성공으로 쓰지 않습니다
첫 번째 오해는 HTTPS가 mTLS와 동의어라고 보는 것입니다. 서버 인증서는 일반적인 HTTPS에서도 필요하지만 클라이언트 인증서는 별도로 요청·검증하도록 구성해야 합니다. 두 번째는 mTLS 인증에 성공하면 모든 API 요청이 허용된다고 여기는 것입니다. 인증서는 TLS peer를 식별하는 자료일 뿐, 애플리케이션이 어떤 계정으로 매핑하고 어떤 권한을 줄지는 별도 정책입니다. 반대로 API가 403을 반환했다고 인증서가 잘못됐다고 단정하지 말고, TLS 핸드셰이크와 이후 authorization 로그를 분리해 보세요.
서버·클라이언트·API 권한의 주체를 짚어 봅니다
회상 연습: 서버 인증서 검증은 통과했지만 API가 요구한 클라이언트 인증서는 제출되지 않았습니다. 다른 경로로 계정 로그인이 완료됐다면 TLS client-certificate 인증도 성공한 것인가요? 아닙니다. 서버 쪽 확인은 성공했어도 mTLS client 인증은 별도로 요구되어 실패하거나 제공되지 않았습니다. 반대로 client certificate 검증이 성공해도 특정 API 동작 권한은 애플리케이션이 따로 판단합니다. 이 가상 사례와 문항은 직접 만들었으며 실제 기출이나 집중 180제 수록 카드가 아닙니다. 상품 구성은 /decks/security#focus-180에서 확인하세요.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
서버 인증서 검증은 통과했지만 API가 요구한 클라이언트 인증서는 제출되지 않았다. 별도 계정 로그인이 완료됐더라도 mTLS client 인증과 API authorization은 각각 어떻게 판단해야 하나?
정답과 해설 확인
클라이언트 인증서 기반 mTLS 인증은 완료되지 않았거나 해당 경로에서 확인되지 않았습니다. 계정 로그인이 별도 인증을 제공할 수 있지만 API 권한은 주체·endpoint 정책에 따라 따로 판단합니다.일반적인 서버 인증 TLS의 client-side server validation과 mTLS의 client certificate validation은 방향이 다릅니다. client certificate가 검증되어도 애플리케이션 접근 권한을 대체하지 않습니다.