1. 문서 제목
- HTTPS, TLS, CA 인증서, Let's Encrypt 정리
2. 기술 개요 요약
HTTPS는 HTTP 메시지를 TLS로 보호해 전송하는 방식이다. HTTP의 요청/응답 의미가 바뀌는 것이 아니라, 네트워크 구간에서 기밀성, 무결성, 서버 인증을 제공한다. 서버 인증은 인증서와 CA(Certificate Authority), 그리고 루트 CA까지 이어지는 신뢰 체인을 통해 이루어진다.
브라우저는 서버 인증서의 도메인, 유효 기간, 서명, 신뢰 체인, 폐기 여부를 확인한다. Let's Encrypt는 ACME 프로토콜 기반 자동화를 제공하는 무료 CA이며, 표준 Domain Validation(DV) 인증서를 발급한다. 유료 인증서와의 핵심 차이는 암호화 강도 자체보다 검증 범위, 운영 지원, 관리 기능에 가깝다.
3. 핵심 기능/개념 정리
3-1. HTTPS가 제공하는 보안 성질
| 보안 성질 | 설명 | 실무 포인트 |
|---|---|---|
| 기밀성 | 중간자가 내용을 읽기 어렵게 암호화 | 로그인, 쿠키, 결제 정보 보호 |
| 무결성 | 전송 중 데이터 변조를 탐지 | 중간자 공격 방지 |
| 서버 인증 | 접속한 서버가 해당 도메인의 서버인지 확인 | CA 인증서와 신뢰 체인 필요 |
3-2. TLS와 HTTPS
| 항목 | 설명 | 실무 포인트 |
|---|---|---|
| HTTP | 애플리케이션 계층 요청/응답 프로토콜 | URI, method, status, header, body |
| TLS | 전송 데이터를 보호하는 보안 프로토콜 | 암호화, 무결성, 인증 제공 |
| HTTPS | HTTP over TLS | HTTP 메시지를 TLS 세션 안에서 전송 |
| TLS Handshake | 암호화 알고리즘, 키, 인증서를 협상 | 성능과 보안 설정에 중요 |
3-3. 인증서에 들어가는 정보
| 항목 | 설명 |
|---|---|
| Subject / SAN | 인증서가 유효한 도메인 이름 |
| Public Key | 서버 신원 검증과 키 교환/서명 검증에 사용 |
| Validity | 인증서 유효 기간 |
| Issuer | 인증서를 발급한 CA |
| Signature | 발급자 CA가 인증서 내용을 서명한 값 |
현대 브라우저 검증에서는 CN보다 SAN(Subject Alternative Name)이 중요하다. 접속 도메인이 인증서 SAN에 포함되어 있어야 한다.
3-4. CA와 신뢰 체인
| 항목 | 설명 | 실무 포인트 |
|---|---|---|
| Root CA | 브라우저/OS가 기본 신뢰하는 최상위 CA | trust store에 포함 |
| Intermediate CA | Root CA와 서버 인증서 사이의 중간 발급자 | 서버가 chain을 함께 제공해야 함 |
| Server Certificate | 실제 도메인에 발급된 인증서 | 서버가 TLS handshake 중 제시 |
| Trust Chain | 서버 인증서에서 Root CA까지 이어지는 서명 경로 | 각 단계 서명 검증 필요 |
일반적인 체인:
Server Certificate
-> Intermediate CA Certificate
-> Root CA Certificate
3-5. 인증서 검증 항목
| 검증 항목 | 설명 |
|---|---|
| 도메인 일치 | 접속한 hostname이 SAN에 포함되는지 확인 |
| 유효 기간 | 현재 시간이 Not Before, Not After 범위 안인지 확인 |
| 신뢰 체인 | 신뢰된 Root CA까지 연결되는지 확인 |
| 서명 검증 | 각 인증서가 상위 CA의 개인키로 서명되었는지 확인 |
| 폐기 여부 | OCSP/CRL 등으로 인증서 폐기 여부 확인 |
| Key Usage | 인증서가 서버 인증 용도에 맞는지 확인 |
폐기 확인은 브라우저와 클라이언트 구현, OCSP stapling 여부, 네트워크 실패 정책에 따라 동작이 달라질 수 있다. 따라서 "항상 실시간으로 폐기 여부를 완벽히 확인한다"라고 말하면 과장이다.
3-6. DV, OV, EV 인증서
| 유형 | 검증 범위 | 적합한 경우 |
|---|---|---|
| DV | 도메인 소유권 검증 | 일반 웹사이트, API, 자동화 환경 |
| OV | 도메인과 조직 정보 검증 | 조직 신원 검증이 필요한 기업 서비스 |
| EV | 더 엄격한 조직 검증 | 규정/정책상 강한 조직 검증이 필요한 경우 |
3-7. Let's Encrypt와 유료 CA 비교
| 구분 | Let's Encrypt | 유료 CA |
|---|---|---|
| 비용 | 무료 | 유료 |
| 자동화 | ACME 기반 자동화에 강함 | 상품별로 다름 |
| 검증 범위 | 표준 DV 인증서 | DV, OV, EV 선택 가능 |
| 암호화 강도 | TLS 설정에 따라 결정 | TLS 설정에 따라 결정 |
| 운영 지원 | 제한적 | 관리 콘솔, 지원, 보증 등 제공 가능 |
| 적합한 경우 | 일반 서비스, 개인/스타트업, 자동 갱신 | 조직 검증, 계약 지원, 기업 정책 필요 |
4. 사용 예시 및 코드 스니펫
4-1. HTTPS 연결에서 일어나는 일
1. Client가 https://example.com 접속
2. TCP 연결 수립
3. TLS handshake 시작
4. Server가 인증서 체인 제공
5. Client가 도메인, 유효 기간, 서명, 신뢰 체인 검증
6. 키 교환으로 세션 키 준비
7. 이후 HTTP 요청/응답은 대칭 키로 암호화되어 전송
4-2. 인증서 체인 개념
example.com server certificate
signed by Intermediate CA
signed by Root CA
trusted by browser/OS trust store
4-3. TLS 종료 지점 예시
Client
-> HTTPS
Load Balancer / CDN / Nginx (TLS termination)
-> HTTP or HTTPS
Application Server
TLS 종료는 암호화된 HTTPS 트래픽을 복호화하는 지점이다. 내부망 요구사항에 따라 TLS 종료 뒤 애플리케이션 서버까지 HTTP로 보낼 수도 있고, 내부 구간도 다시 HTTPS로 보호할 수도 있다.
4-4. Let's Encrypt 발급 흐름
1. ACME client가 인증서 발급 요청
2. Let's Encrypt가 도메인 제어권 검증 challenge 제공
3. 운영자가 HTTP/DNS 등 방식으로 challenge 응답
4. 검증 성공 시 DV 인증서 발급
5. ACME client가 인증서 설치 및 갱신 자동화
5. 실제 사용 시 주의점 / Best Practice
5-1. HTTPS는 암호화만이 아니라 서버 인증도 제공한다
HTTPS를 “암호화된 HTTP”로만 설명하면 부족하다. 클라이언트가 접속한 서버가 진짜 해당 도메인의 서버인지 확인하는 서버 인증도 핵심이다.
5-2. 자가 서명 인증서는 암호화는 가능해도 기본 신뢰는 없다
자가 서명 인증서는 제3자 CA가 신원을 검증한 것이 아니므로 브라우저/OS 기본 trust store와 연결되지 않는다. 개발/테스트 환경에서는 사용할 수 있지만 일반 사용자 서비스에서는 경고가 발생한다.
5-3. Let's Encrypt가 무료라고 암호화가 약한 것은 아니다
암호화 강도는 인증서를 무료로 받았는지 유료로 샀는지가 아니라 TLS 버전, cipher suite, key 설정, 서버 구성에 의해 좌우된다. Let's Encrypt와 유료 CA의 차이는 주로 검증 범위와 운영 지원이다.
5-4. 인증서 갱신 자동화가 중요하다
인증서는 만료되면 서비스 장애로 이어진다. Let's Encrypt는 자동 갱신을 전제로 운영하는 것이 일반적이며, 유료 인증서도 만료 모니터링과 갱신 절차가 필요하다.
5-5. TLS 종료 후 내부 구간 보안도 설계해야 한다
로드밸런서나 CDN에서 TLS를 종료하면 그 뒤 내부 통신은 별도 설계가 필요하다. 민감한 환경에서는 내부 구간도 TLS로 보호하거나 mTLS를 검토한다.
5-6. TLS 버전과 handshake 최적화를 구분한다
TLS 1.2와 TLS 1.3은 handshake 흐름과 지원하는 암호 스위트가 다르다. HTTPS의 기본 개념을 설명할 때는 "TLS handshake로 인증서 검증과 키 교환을 한다" 정도로 말하고, 성능 최적화나 0-RTT/재개(resumption)는 버전별 기능으로 분리해서 설명한다.
5-7. 면접 답변으로 압축하기
HTTPS는 HTTP 메시지를 TLS로 보호해 기밀성, 무결성, 서버 인증을 제공하는 방식입니다. 서버는 TLS handshake 중 인증서 체인을 제공하고, 클라이언트는 도메인 일치, 유효 기간, 서명, 신뢰 체인, 폐기 여부를 확인합니다. CA는 도메인이나 조직을 검증하고 인증서에 서명하는 기관이며, 브라우저와 OS는 신뢰된 Root CA 목록을 가지고 있습니다. Let's Encrypt는 ACME 기반으로 무료 DV 인증서를 자동 발급하는 CA이고, 유료 인증서와의 차이는 암호화 강도보다는 OV/EV 같은 검증 범위, 운영 지원, 관리 기능에 가깝습니다.
검증 메모
- TLS 설명은 RFC 8446과 HTTP Semantics를 기준으로 확인했다.
- Let's Encrypt는 무료 DV 인증서와 ACME 자동화가 핵심이며, 암호화 강도 차이로 설명하지 않도록 유지했다.
- 인증서 폐기 확인은 클라이언트 구현과 정책에 따라 달라질 수 있어 절대 표현을 보완했다.
6. 참고자료 / 공식 문서 출처
- RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
https://datatracker.ietf.org/doc/html/rfc8446 - RFC 9110: HTTP Semantics
https://datatracker.ietf.org/doc/html/rfc9110 - Let's Encrypt: Getting Started
https://letsencrypt.org/getting-started/ - Let's Encrypt: FAQ
https://letsencrypt.org/docs/faq/ - Let's Encrypt: How It Works
https://letsencrypt.org/how-it-works/
'CS > Network' 카테고리의 다른 글
| [Network] 네트워크 계층 구조: 캡슐화, IP, MAC, Port까지 한 번에 정리 (0) | 2026.07.11 |
|---|---|
| [Nework] TCP 3-way Handshake, 4-way Handshake, TIME_WAIT 정리 (0) | 2026.07.11 |
| (TIR+4) ③ 브라우저는 OS의 프로토콜 스택에 메시지 송신을 의뢰한다 (0) | 2020.11.18 |
| (TIR+3) ② OS에 HTTP 메시지를 송신하기 위해 웹 서버의 IP 주소를 DNS 서버에 조회한다 (0) | 2020.11.16 |
| (TIR+2) ① 브라우저는 웹 서버에 보내는 메시지를 작성하기 위해 URL을 해독한다 (0) | 2020.09.21 |
댓글