HTTPS(TLS)는 어떻게 암호화될까? — 공개키, 인증서, 대칭키를 쉽게 이해하기

1. HTTPS는 왜 필요할까?

HTTP는 평문 통신이다.
즉, 네트워크 중간에서 패킷을 가로채면 요청/응답 내용이 그대로 보인다.

이를 해결하기 위해 등장한 것이:

HTTPS = HTTP + TLS(암호화)

HTTPS의 목표는 단순하다.

• 🔐 통신 내용을 암호화하고
• 🧾 접속한 서버가 진짜인지 확인하는 것

---

2. HTTPS에서 쓰이는 암호화 방식은 두 가지

HTTPS(TLS)는 암호화 방식을 하나만 쓰지 않는다.

구분용도

공개키 암호(비대칭)	서버 신원 확인, 대칭키를 안전하게 합의
대칭키 암호	실제 데이터(HTTP 요청/응답) 암호화

👉 핵심 포인트

“공개키는 보조, 대칭키가 주력”

---

3. 서버 인증서(Certificate)는 왜 필요할까?

서버는 TLS 연결 초기에 인증서(Certificate) 를 브라우저에 보낸다.

인증서 안에는 다음 정보가 들어 있다.

• 서버 도메인 정보 (example.com)
• 서버의 공개키
• CA(인증기관)의 서명

---

4. 브라우저는 왜 이 공개키를 믿을까?

브라우저는 서버를 직접 믿지 않는다.
대신 CA(Certificate Authority) 를 믿는다.

🔑 CA 신뢰 구조

• 브라우저/OS에는 이미 신뢰된 CA들의 공개키 목록이 내장돼 있다
• 서버 인증서는 CA가 서명한 문서
• 브라우저는 CA의 공개키로 서명을 검증

검증이 성공하면 브라우저는 이렇게 판단한다.

“CA가 이 도메인(example.com)의 공개키라고 보증했으니,
이 공개키는 믿을 수 있다.”

👉 즉,

서버 공개키를 믿는 이유 = CA의 서명을 믿기 때문

---

5. 공개키로 뭘 암호화할까?

많은 사람들이 이렇게 생각한다.

“HTTPS는 공개키로 데이터를 암호화해서 보내는 거 아닌가?”

❌ 아니다.

공개키 암호는 느리다.
그래서 HTTPS에서는 공개키로 딱 한 가지만 한다.

✅ 공개키의 진짜 역할

“앞으로 사용할 대칭키를 안전하게 만들거나 합의하는 것”

---

6. 실제 암호화 흐름 (아주 쉽게)

① 서버 → 공개키 전달

• 서버가 인증서를 보냄
• 브라우저는 CA 서명을 검증

② 대칭키 합의

• 브라우저와 서버는 세션용 대칭키(AES 등) 를 안전하게 만든다
• 이 과정에서 공개키 암호가 사용된다

방식은 두 가지가 있다.

• (예전) RSA: 비밀값을 서버 공개키로 암호화해서 전달
• (요즘) Diffie-Hellman(ECDHE): 서로 계산해서 같은 대칭키 생성

③ 실제 데이터 통신

• HTTP 요청/응답 전부 대칭키로 암호화
• 빠르고 안전함

---

7. 요즘 HTTPS는 전부 같은 방식일까?

큰 구조는 모두 동일하지만,
대칭키를 만드는 방법은 세대별로 다르다.

❌ 예전 방식 (거의 사용 안 함)

• RSA로 비밀값을 암호화해서 서버에 전달
• 단점: 서버 개인키가 털리면 과거 통신 복호화 가능

✅ 현재 표준

• TLS 1.2 (ECDHE)
• TLS 1.3
• Forward Secrecy 제공
• 대칭키를 “보내지 않고” 계산으로 생성

---

8. 핵심 요약

• HTTPS는 공개키로 데이터를 암호화하지 않는다
• 공개키는:
  • 서버 신원 확인
  • 대칭키 합의
• 실제 데이터 암호화는:
  • 대칭키(AES, ChaCha20) 가 담당

한 문장으로 정리하면

HTTPS는 공개키로 대칭키를 안전하게 합의하고,
그 대칭키로 모든 데이터를 암호화한다.

---

9. 여기서 드는 의문: CA는 대체 뭐고, 어디에 저장돼 있을까?

중요한 사실 하나:

❌ 내가 만든 인증서가 브라우저에 등록되는 게 아니다
✅ 브라우저는 ‘루트 CA’만 미리 알고 있다

---

10. 브라우저가 미리 들고 있는 것: 루트 인증서 저장소

브라우저/OS에는 루트 인증서 저장소(Root Certificate Store) 가 있다.

여기에는 다음과 같은 공개 루트 CA 들이 들어 있다.

• DigiCert Root CA
• GlobalSign Root CA
• ISRG Root X1 (Let’s Encrypt)
• Amazon Root CA
• 등등…

👉 이것이 흔히 말하는
**“브라우저에 내장된 CA 공개키 목록”**이다.

---

11. AWS ACM에서 인증서를 발급하면 무슨 일이 일어날까?

예를 들어 www.kg.com 인증서를 AWS ACM에서 발급했다고 하자.

이때 일어나는 일은 다음과 같다.

❌ www.kg.com 인증서가 브라우저에 저장 ❌
✅ 이미 신뢰된 루트 CA로 이어지는 체인을 가진 서버 인증서 발급

구조는 이렇다.

www.kg.com 서버 인증서 (leaf) ↓ 
Amazon Intermediate CA ↓ 
Amazon Root CA ← 이미 브라우저/OS에 내장

 

“내가 이미 신뢰하는 Amazon Root CA까지
서명이 이어지는 인증서 체인이네 → OK”

---

12. 가비아에서 발급한 인증서도 같은 원리다

가비아는 보통 CA 자체라기보다 인증서 발급 대행사다.

실제 발급 구조는 보통 다음과 같다.

 

www.kg.com 서버 인증서 ↓ 
GlobalSign / DigiCert / Sectigo (중간 CA) ↓ 
해당 CA의 루트 인증서 (브라우저에 이미 존재)

그래서 가비아 인증서도 브라우저에서 🔒 로 표시된다.

---

13. 그럼 리눅스에서 직접 만든 인증서는 왜 안 될까?

리눅스에서 흔히 이렇게 만든다.

 

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem

이렇게 만든 인증서는 보통:

www.kg.com 서버 인증서 ↓ 
자기 자신이 서명 (Self-Signed)

문제는 여기다.

• 이 인증서를 보증하는 루트 CA가
• 브라우저의 루트 인증서 저장소에 존재하지 않는다

그래서 브라우저는 이렇게 말한다.

“이 인증서를 누가 보증했는지 모르겠다”
→ ❌ 신뢰할 수 없음

---

14. 그럼 self-signed 인증서는 쓸모없을까?

아니다. 용도가 다를 뿐이다.

주로 이런 곳에서 사용한다.

• 사내 서비스
• 개발/테스트 환경
• 내부 API 통신

이 경우:

• 클라이언트/서버에 루트 인증서를 직접 설치해서
• “이 CA는 신뢰한다”고 알려줘야 한다

---

15. 전체 구조 한 장 요약

[브라우저 / OS]
 └─ 루트 CA 저장소 (신뢰의 출발점)

[서버]
 └─ 서버 인증서 (ACM / 가비아 / Let’s Encrypt)
     └─ 중간 CA
         └─ 루트 CA  ← 브라우저가 이미 신뢰

 

---

16. 최종 한 문장 결론

HTTPS에서 브라우저가 신뢰하는 것은
‘내 서버 인증서’가 아니라
그 인증서를 보증하는 ‘루트 CA’다.

---

✨ 마무리

HTTPS는 처음엔 복잡해 보이지만,
아래 세 가지만 기억하면 된다.

1. 누구랑 통신하는지 확인 (CA + 인증서)
2. 비밀 대화에 쓸 열쇠 만들기 (대칭키 합의)
3. 그 열쇠로 빠르게 대화 (대칭키 암호화)

이 구조만 이해하면
HTTPS, TLS, 인증서, CA가 한 번에 연결된다.