Let's Encrypt

Let’s Encrypt는 자동화되고 공개된 무료 인증 기관(Certificate Authority)이며, Internet Security Research Group (ISRG)에서 운영되고 있다. [1]

소개[편집 | 원본 편집]

Let's Encrypt가 다른 CA와 다른 점은 바로 자동화되고 무료라는 점이다. S모 CA처럼 폐기 수수료를 받지도 않으며 인증서를 받기 위해 세월야 네월야 기다릴 필요도 없고 발급되거나 폐기된 모든 인증서들이 기록되고 공개된다.

또한 Let's Encrypt는 ACME 프로토콜(DV(도메인 인증된) 인증서 관리를 자동화하기 위한 프로토콜)를 사용하는 데, 이 프로토콜은 스펙이 공개되어 있기에, Let's Encrypt측에서 제공하는 클라이언트 외에도 다른 서드파티 클라이언트(예시)이 존재한다.

작동 원리[편집 | 원본 편집]

Let's Encrypt가 인증서를 발급하는 과정은 크게 두 가지로 나뉜다.

  1. CA가 도메인 소유여부를 검증한다.
  2. 발급자가 검증된 도메인에 대해 인증서 요청/갱신/폐기를 요청한다.

도메인 소유 검증[편집 | 원본 편집]

이 문단에서 편의를 위해 발급자가 소유를 검증하고자 하는 도메인을 libressl.com라 가정한다.

모든 CA가 거치는 과정이자 가장 중요한 과정이다. 이 과정은 keybase의 도메인 검증을 방불케하는데, Let's Encrypt 소프트웨어(이하 소프트웨어)에 의해 자동으로 처리된다는 점에 차이가 있다.

먼저, 소프트웨어가 새로운 키쌍(이하 키쌍 A)을 생성하고, Let's Encrypt에 도메인 검증에 필요한 것들을 질의한다. 이에 대해 Let's Encrypt CA에서 요청된 도메인 이름을 확인하고 하나 이상의 첼린지(일종의 도전과제 같은 거)를 제공한다. 예시로는 다음과 같으며, 둘 중 하나를 선택하게 할 수도 있다.

  • libressl.com에 DNS 레코드를 생성하는 첼린지
  • https://libressl.com/의 well-known URI에서 HTTP 리소스를 제공하는 첼린지

이런 첼린지와 함께, 반드시 서명해야 하는 데이터도 제공되는데 이는 키 소유를 검증하기 위함이다.

이러한 첼린지가 주어지면 소프트웨어는 이를 해결하고 서명까지 완료한 후에 CA가 "검증을 마칠 준비가 됐다고" 알린다. 그러면 CA에서 진짜로 이 첼린지들이 해결됐는지 확인한다. CA측에서 서명을 확인하기도 하며 웹서버에서 파일을 다운로드하여 올바른 내용인지도 확인한다.

만약 모든 첼린지들이 확인되고 유효하며 서명도 유효하다면 발급자는 키쌍 A(혹은 권한이 부여된 키쌍)에 의해, libressl.com 인증서를 관리할 권한을 부여받는다.

인증서 요청과 폐기[편집 | 원본 편집]

이제 발급자가 권한이 부여된 키쌍을 얻었다면, 요청, 갱신, 폐기는 간단하다. 그냥 인증서 관리 메세지를 권한이 부여된 키쌍으로 서명하고 보내면 된다.

DV 인증서를 얻으려면, Let's Encrypt CA에게 libressl.com에 대한 인증서 발급을 요청하는 PCKS#10 Certificate Signing Request를 작성하고, 그 안에 CSR내에 키쌍 B의 공개키와 비밀키로 서명된 서명을 포함한다. 그리고 나서 Let's Encrypt CA가 권한이 부여됨을 알 수 있도록 그 CSR를 통째로 키쌍 A로 서명한 후, Let's Encrypt CA에 전송한다.

Let's Encrypt CA에서 요청을 수신하면, 서명을 확인하고, 아무 문제가 없다면 CSR내에 있는 공개키로 libressl.com에 대한 인증서를 발급한다.

폐기도 비슷한 절차로 작동한다. 소프트웨어가 폐기 요청을 권한이 부여된 키쌍으로 서명하고 전송한 뒤에 Let's Encrypt CA에서 요청과 서명과 권한 소유 여부를 검증한다. 아무 문제도 없다면, 폐기 정보가 CRLs, OCSP와 같은 폐기 채널에 들어가 브라우저에서 폐기된 인증서를 받지 않도록 한다.

이외의 특징[편집 | 원본 편집]

통상 인증서는 유효기간이 1년 이상이나, Let's Encrypt는 유효기간이 90일이다. 그냥 이유없이 90일은 아니고 이유가 있어서 그런건데 그 이유는 다음과 같다.

  • 실수나 사고, 도용된 인증서들로 인한 피해를 줄일 수 있고 잘못된 발행된 인증서들은 90일 이후에는 자연 소멸하기 때문.
  • 짧은 유효기간은 편리성을 위해서라면 무조건 필수적인 자동화를 해야 하기 때문이다. 만약 우리가 모든 웹의 HTTPS로의 전환을 위해 행동한다면, 모든 시스템 관리자들이 수동적으로 인증서를 갱신하리라 기대하기 어렵다. 발급과 갱신이 자동화되는 때, 짧은 만료일은 만료인이 긴것과 편리성에서 아무런 차이도 없어진다.

설치 방법[편집 | 원본 편집]

각주