본문으로 건너뛰기

인증 로직 — TLS 핸드셰이크

인증서가 "어떻게 쓰이는가"의 핵심 무대가 TLS 핸드셰이크입니다. HTTPS 접속 시 암호화 전에 일어나는 일을 봅니다.

I. 핸드셰이크가 하는 두 가지​

① 인증(Authentication) : 서버가 진짜 그 도메인의 주인인지 인증서로 확인
② 키 교환(Key Exchange) : 이후 통신에 쓸 대칭 세션키를 안전하게 합의

II. TLS 1.3 핸드셰이크 흐름(요약)​

Client                                   Server
  │  ClientHello (지원 암호군, 키쉐어 ECDHE 공개값)
  │ ─────────────────────────────────────▶
  │                 ServerHello (선택 암호군, 서버 키쉐어)
  │                 {Certificate}            ← 서버 인증서(+중간CA)
  │                 {CertificateVerify}      ← 서버 개인키로 서명
  │                 {Finished}
  │ ◀─────────────────────────────────────
  │  (인증서 검증 + 키 유도)
  │  {Finished}
  │ ─────────────────────────────────────▶
  │  ===== 이후 애플리케이션 데이터는 대칭키로 암호화 =====

TLS 1.3은 1-RTT로 끝나고, 핸드셰이크 메시지 상당 부분이 암호화됩니다({}). TLS 1.2는 더 많은 왕복과 RSA 키 교환 옵션이 있었으나, 1.3은 ECDHE(순방향 비밀성) 중심으로 단순·강화됐습니다.

III. 클라이언트의 인증서 검증 (핵심 로직)​

서버가 보낸 인증서를 받아 아래를 모두 통과해야 신뢰합니다.

1) 체인 구성·서명 검증
   Leaf 서명 ← Intermediate 공개키로 검증
   Intermediate 서명 ← Root 공개키로 검증
2) 신뢰 앵커 확인
   최상위 Root가 트러스트 스토어에 있는가
3) 유효기간
   현재 시각이 Not Before ~ Not After 안인가
4) 도메인 일치
   접속한 호스트명이 인증서 SAN에 있는가
5) 용도
   EKU에 serverAuth 가 있는가
6) 폐기 확인
   CRL/OCSP 상 폐기되지 않았는가  ([05 참조](./05-lifecycle-renewal.md))

하나라도 실패하면 브라우저는 경고(NET::ERR_CERT_…)를 띄웁니다.

IV. "서버가 개인키를 진짜 가졌는지" 증명​

인증서는 공개키를 담을 뿐입니다. 서버가 그 공개키에 대응하는 개인키를 실제로 소유함을 증명해야 사칭을 막습니다.

  • TLS 1.3: 서버가 핸드셰이크 기록(transcript)에 자신의 개인키로 서명(CertificateVerify)합니다. 클라이언트는 인증서의 공개키로 이 서명을 검증 → 개인키 소유 증명.
  • 동시에 ECDHE 키 교환으로 세션키를 합의합니다. ECDHE는 매 세션 임시 키를 써 순방향 비밀성(PFS) — 나중에 개인키가 유출돼도 과거 트래픽은 복호화 불가.
인증서(공개키) + CertificateVerify(개인키 서명) 
  → "이 공개키의 주인이 맞고, 지금 그 개인키를 쥐고 있다"

V. 서명·검증의 수식 관점​

서버 인증(개념):

서버:  sig = Sign(서버개인키, 핸드셰이크_해시)
클라: Verify(인증서_공개키, sig, 핸드셰이크_해시) == true ?
      AND 인증서 자체가 CA 체인으로 검증됨

→ 두 조건이 함께 충족돼야 "진짜 그 서버"로 인정. (01. 디지털 서명 복습)

VI. 상호 인증 (mTLS)​

보통 TLS는 서버만 인증합니다(클라이언트는 비밀번호 등으로 로그인). mTLS는 클라이언트도 인증서를 제시해 양쪽이 서로 인증합니다.

구분서버 인증(일반)mTLS
서버→클라서버 인증서 제시동일
클라→서버없음클라이언트 인증서 제시
용도일반 웹내부 서비스 간, 제로트러스트, API 보안
  • 서비스 메시(Istio 등)·제로트러스트에서 서비스 간 통신 인증에 널리 쓰임 → 제로트러스트

VII. 결론​

TLS 핸드셰이크에서 인증서는 ① 체인·유효성·도메인 검증 → ② 개인키 소유 증명(CertificateVerify) → ③ ECDHE 세션키 합의의 로직으로 "진짜 상대"를 인증합니다. mTLS는 이를 양방향으로 확장한 것입니다.