TLS 핸드셰이크가 성공해도 의도한 서버를 신뢰한다고 말하려면 어떤 인증서 검증과 API 인가가 필요한가요?

일반적인 HTTPS처럼 인증서 기반 서버 인증을 사용하는 TLS 연결을 전제로 하면, 핸드셰이크가 암호화 키를 만들었다는 사실만으로 의도한 서버를 신뢰할 수는 없습니다. 클라이언트는 신뢰할 수 있는 루트까지 인증서 체인이 이어지는지, 접속한 호스트 이름이 SAN 등의 대상 이름과 맞는지, 유효 기간·키 용도·서명 알고리즘을 검증해야 합니다. TLS는 전송의 기밀성과 무결성, 인증서 검증은 상대 서버의 신원, API 인증·인가는 사용자와 작업 권한을 담당합니다.

인증서 검증은 접속 이름을 기준으로 합니다

브라우저나 HTTP client가 shop.example에 접속했다면 인증서의 subject 이름을 대충 보고 신뢰하는 것이 아니라 hostname 검증 규칙에 따라 SAN과 비교합니다. 체인이 신뢰 store의 루트까지 이어지고 중간 CA가 유효하며, 현재 시각이 유효 기간 안에 있고 서버 인증 용도의 키인지 확인합니다. 만료·이름 불일치·중간 인증서 누락·신뢰 루트 부재를 보고 검증을 끄는 방식으로 해결하면 공격자와도 암호화된 연결을 만들 수 있습니다. 사설 CA라면 허용할 루트의 배포·교체를 별도 운영 계약으로 둡니다.

TLS 1.3에도 인증서 대신 사전 공유키로 상대를 인증하는 PSK 모드가 있으므로 모든 TLS가 Certificate 메시지를 보낸다고 일반화하지 않겠습니다. 중요한 것은 ‘어떤 인증 자격을 어떤 신뢰 앵커로 검증했는가’입니다. mTLS에서는 클라이언트 인증서가 서비스 신원을 증명할 수 있지만, 그 서비스가 최종 사용자를 대신해 특정 API 작업을 할 권한까지 자동으로 주지는 않습니다.

TLS 뒤의 API 권한을 따로 집행합니다

인증서가 우리 API 서버의 것이라고 확인해도 요청의 사용자 인증·tenant 범위·작업별 인가는 계속 검사합니다. 반대로 API bearer token이 유효해도 TLS hostname 검증을 끄면 token을 공격자 서버로 보낼 수 있습니다. 고정(pin)은 특정 인증서나 공개키만 허용해 일부 신뢰 루트 오남용을 줄일 수 있지만 정상 교체·복구 비용과 pin 목록 배포 문제를 추가하므로 서비스의 교체 능력과 함께 선택합니다.

인증서 교체는 만료 전에 새 인증서를 모든 load balancer와 진입 경로에 배포하고, 일부 인스턴스가 옛 인증서를 내는 중첩 기간을 확인합니다. 기존 TCP 연결이나 TLS 1.3 세션 재개가 새 인증서를 다시 제시하지 않을 수 있으므로, 인증서 교체만으로 이미 열린 연결과 ticket이 즉시 무효화됐다고 말하지 않겠습니다. 유출 대응이면 연결 종료·세션 ticket 수명·재인증을 별도로 적용합니다.

검증은 정상 체인뿐 아니라 hostname 불일치, 만료, 중간 CA 누락, 잘못된 key usage, 신뢰 루트 교체, mTLS client 인증서, PSK 모드, 기존 연결·재개를 포함합니다. 실패 로그에는 서버가 보낸 체인·접속 이름·trust store 버전 같은 진단 정보만 남기고 비밀 키는 남기지 않습니다.

결론적으로 TLS 성공은 안전한 통신 채널의 성립이지 모든 신뢰와 권한의 완성이 아닙니다. 인증서 검증, 전송 중 API 인증, 자원별 인가를 서로 다른 검사로 설명할 수 있어야 합니다.

인증서 검증 실패를 조사할 때 서버가 보낸 인증서만 보면 안 되고 클라이언트가 실제로 어떤 trust store와 SNI/접속 이름을 사용했는지 확인하겠습니다. 같은 IP에 여러 호스트가 있으면 SNI가 달라 서로 다른 인증서가 반환될 수 있고, 프록시가 TLS를 종료하면 브라우저가 검증한 상대와 애플리케이션이 생각하는 원 서버를 구분해야 합니다. 사설 CA를 운영한다면 모든 클라이언트에 루트를 넓게 설치하기보다 필요한 서비스에만 배포하고, 루트 교체 때 구·신뢰 루트의 중첩 기간과 제거 시점을 정합니다. 인증서 만료를 감지하는 모니터링은 만료 예정 알림만으로 끝내지 않고 실제 사용자 경로의 handshake와 hostname 검증을 주기적으로 수행해야 합니다.