왜 HTTPS Handshake 과정에서는 인증서를 사용하는 것 일까요?

클라이언트가 서버의 공개키를 신뢰할 수 있는지 검증하기 위해 신뢰할 수 있는 제3자(CA)가 서명한 인증서를 사용합니다.

인증서가 없다면?

클라이언트: "공개키를 주세요"
서버: "여기 공개키입니다"
클라이언트: "...이게 진짜 서버 공개키인지 어떻게 믿지?"

공격자가 중간에서 공개키를 자신의 것으로 바꿔치기 가능
→ 중간자 공격 (MITM, Man In The Middle Attack)

인증서로 해결

CA(인증 기관)가 서버의 공개키에 CA 개인키로 서명
→ 인증서 발급

클라이언트는 CA의 공개키로 서명 검증
→ "CA가 보증한 서버구나" → 신뢰 O

CA (Certificate Authority) 신뢰 체계

Root CA (최상위, 브라우저/OS에 내장)
    ↓ 서명
Intermediate CA (중간 인증기관)
    ↓ 서명
서버 인증서

브라우저/OS에 Root CA 공개키가 미리 내장되어 있어 신뢰 체계가 성립합니다.

TLS 핸드 쉐이크 흐름

1. 클라이언트 → 서버: "HTTPS 연결 요청"
2. 서버 → 클라이언트: 인증서 전달 (서버 공개키 포함)
3. 클라이언트: CA 공개키로 인증서 서명 검증
         → 유효하면 서버 신뢰 O
4. 클라이언트: 대칭키 생성 후 서버 공개키로 암호화 전송
5. 서버: 개인키로 복호화 → 대칭키 획득
6. 이후 통신: 대칭키로 암호화 통신

인증서가 보장하는 것

인증서에 담긴 정보

- 서버 도메인 (ex. www.google.com)
- 서버 공개키
- 발급한 CA 정보
- 유효 기간
- CA의 전자서명

결국 인증서는 "공개키의 신뢰 문제" 를 해결하기 위한 장치이며, 전자서명 + CA 신뢰 체계를 통해 MITM 공격을 방어합니다.