Let's Encrypt 작동 원리
Let's Encrypt 작동 원리 (How It Works)
HTTPS 서버를 세우고 브라우저가 신뢰하는 인증서를 사람 개입 없이 자동으로 받으려면 어떻게 해야 할까요? Let's Encrypt와 ACME 프로토콜이 정확히 그 목표를 위해 설계됐어요. 웹 서버에서 ACME 클라이언트를 실행하면 그 과정이 자동으로 이뤄져요.
과정은 두 단계로 나뉘어요. 첫째, ACME 클라이언트가 인증 기관(CA)에게 "이 웹 서버가 그 도메인을 통제한다"는 걸 증명하고, 그 다음부터 그 도메인의 인증서를 요청·갱신·폐기할 수 있어요.
**도메인 검증(Domain Validation)**부터 볼게요. Let's Encrypt는 공개 키로 ACME 클라이언트 소프트웨어를 식별해요. 클라이언트가 처음 접촉하면 새 계정 키 쌍을 만들고, 운영자가 도메인을 통제한다는 걸 증명해요. CA는 요청된 도메인을 보고 여러 가지 챌린지(도전 과제) 세트를 부여하는데, 예를 들면 다음과 같아요.
example.com아래 DNS 레코드를 프로비저닝하거나http://example.com/의 well-known URI에 HTTP 리소스를 두는 방식
클라이언트가 챌린지를 완료하면 CA가 여러 네트워크 관점에서 챌린지가 충족됐는지 확인해요. 이 과정은 HTTPS를 못 쓰는 특성이 있어 공격에 취약한데, 병렬로 여러 관점에서 검증하므로 공격자가 검증 과정을 무너뜨리기 훨씬 어려워져요. 검증이 성공하면 그 공개 키로 식별된 클라이언트가 example.com의 인증서 관리를 할 권한을 얻어요.
발급과 폐기 단계예요. 인증되면 발급·갱신·폐기는 간단해요 — 인증된 계정 키 쌍으로 서명한 인증서 관리 메시지를 보내면 돼요. 발급 시 클라이언트는 인증서 서명 요청(CSR)을 만들어 보내고, CA는 서명 두 개(CSR의 키와 도메인 인증 키)를 모두 확인한 뒤 인증서를 발급하고 여러 공개 인증 투명성(CT) 로그에 제출해요. 갱신은 "도메인 검증을 다시 하고 새 인증서를 요청하는" 발급 과정의 반복이에요. 폐기하면 CA가 폐지 정보를 CRL(Certificate Revocation List)로 게시해서 브라우저 같은 신뢰 당사자가 폐기된 인증서를 받아들이지 않게 해요.
더 알아보기
- 검증 방식의 종류와 장단점: Challenge Types
- ACME 프로토콜 명세: RFC 8555