기술을 사용하는 것도 중요하지만, 기술의 원리를 이해하는 것도 정말 중요하다고 생각합니다. 시간적 여유가 있으니 적용전에 이론을 다지고 가볼까 합니다.
웹사이트에 HTTPS를 사용 가능하게 하기 위해서는, 인증 기관(CA, Certificate Authority)로 부터 발급받은 인증서(certificate)가 필요합니다. Let’s encrypt는 CA입니다(신뢰도 상승!). Let’s encrypt로부터 웹사이트 도메인에 대한 인증서를 발급 받기 위해서는 도메인의 소유권을 증명해야 합니다.
시중에서 가장 저렴하고 손쉽게 웹사이트에 적용할 수 있는 인증서 방식 또한 도메인 인증 방식의 인증서 입니다(DV, Domain Validation 방식이라고 부릅니다).
Let’s encrypt도 이러한 DV 방식을 사용하여 인증서를 발급해줍니다. ACME protocol을 사용하는 software를 통해서 이 절차를 진행하게 됩니다.
ACME protocol은 IETF(국제 인터넷 표준화 기구)에서 개발한 프로토콜로, 웹서버가 자동으로 인증서를 발급받고, 설치하고 갱신 할 수 있게 도와줍니다. 도메인 소유권을 검증하여 자동으로 인증서를 발급하며, 보안을 강화하고 관리를 간소화 하게 해줍니다.
Shell access가 가능한 경우와 가능하지 않은 경우에의 방법으로 나뉘어져있지만, 우리는 EC2 instance에 ssh 접속이 가능하기 때문에 가능한 경우의 옵션으로 진행하겠습니다.
Shell access가 가능한 경우에는 대부분이 Certbot ACME client를 사용합니다. 인증서 발급과 설치가 자동화가 되어 있습니다.
이 기술이 어떻게 동작하는지 이해하기 위해, https://example.com 을 Let’s Encrypt를 지원하는 certificate management agent로 설정하는 프로세스를 설명해보겠습니다.
- Agent가 CA에게 도메인 소유권을 증명합니다.
- 소유권을 증명했다면, agent는 해당 도메인에 대한 인증서를 요청, 갱신, 취소 할 수 있습니다.
Domain Validation
Let’s Encrypt는 server 관리자를 public key로 구분합니다. 처음 agent software가 Let’s Encrypt와 소통을 하면, 새로운 key pair를 생성하고 Let’s Encrypt CA에 서버가 하나 혹은 그 이상의 도메인을 관리하고 있다는 것을 증명합니다. 이것은 계정을 생성하고 그 계정에 도메인을 추가하는 전통적인 CA process를 닮았습니다.
Process를 시작하기 위해서, agent는 Let’s Encrypt CA에게 어떻게 하면 example.com을 제어하고 있다는 것을(소유권을) 증명할 수 있는지 물어봅니다. Let’s Encrypt CA는 요청을 받은 도메인을 살펴보고, 하나 혹은 그 이상의 challenge를 발행합니다. 이것은 agent가 도메인에 대한 제어를 증명하는 여러가지 방법입니다. 에를 들어 CA는 다음의 선택지를 줄 수 있습니다:
- example.com 아래에 DNS record를 생성하게 하는 것
- http://example.com 의 well-known URI 아래에 HTTP resource를 생성하게 하는 것
Challenge와 함께, Let’s Encrypt CA는 agent가 반드시 private key pair로 sign 하여 key pair에 대한 제어를 할 수 있다는 것을 증명할 수 있는 nonce를 제공해줍니다.
Agent software는 반드시 제공된 challenge들 중 하나를 만족시켜야 합니다. Second task를 수행해야 한다고 가정해 봅니다: http://example.com 사이트의 특정한 path에 파일을 생성하는 것입니다. Agent는 또한 제공받은 nonce를 private key로 서명합니다. Agent가 이러한 단계들을 마치면, CA에게 validation을 받을 준비가 끝났다고 알려줍니다.
그러면, CA는 challenge가 만족되었는지 확인합니다. CA는 서명된 nonce의 값을 검증하고, 웹서버로부터 파일 다운로드를 시도하여 예상된 컨텐츠를 가지고 있는지 확인합니다.
Nonce위의 서명이 제대로 되었고, challenge가 확인되었다면, public key로 식별되는 agent는 example.com에 대한 certificate management(인증서 관리)를 할 수 있는 권한을 가지게 됩니다. Agent가 사용하는 key pair를 example.com의 “authorized key pair” 라고 부릅니다.
Certificate Issuance and Revocation
Agent가 authorized key pair를 가지게 되면, 인증서에 대한 요청, 갱신, 취소는 쉬워집니다 — 그저 certificate management message를 전송하고 authorized key pair로 그들을 서명하면 됩니다.
도메인에 대한 인증서를 얻기 위해서 agent는 Let’s Encrypt에게 요청하여 example.com에 특정한 public key에 대한 인증서를 발급받도록 하게 할 PCKS#10 Certificate Signing Request(CSR)을 생성합니다. 평소처럼 CSR은 CSR의 public key와 연관된 private key에 의한 signature(서명)를 포함해야 합니다. Agent는 또한 CSR 전체를 example.com의 authorized key로 서명하여 Let’s Encrypt CA가 이것이 권한을 가졌다는 것을 알려줍니다.
글을 읽다보니 CSR에 들어가는 서명과 CSR 자체를 서명할 때 사용하는 private key가 같은 것 처럼 읽힙니다. 처음에 읽었을 때는 이해가 되지 않았습니다. 왜 하나의 private key로 굳이 2번을 서명하는 것인지. Chat GPT 에게 물어본 결과 키 관리를 단순화 하기 위해서는 이렇게도 사용한다고 하는데 진위 여부는 모르겠습니다.. 하지만 전체 프로세스를 이해하는데 방해가 되지 않기 때문에 그냥 넘어가려고 합니다 🐥
Let’s Encrypt CA가 request를 받으면, 두 signature를 다 검증합니다(여기서 두 signature란, CSR 자체와 CSR에 들어가는 signature를 의미합니다). 모든것이 이상이 없이 좋아보인다면, CA는 CSR에 포함된 public key에 대응하는 example.com 에 대한 인증서를 발급하고 이것을 agent에 반환합니다.
Revocation(취소) 역시 비슷한 방식으로 진행됩니다. Agent는 example.com의 authorized key pair에 대한 취소 요청(revocation request)를 서명하고 Let’s Encrypt는 이 요청이 권한을 가지고 있는지를 검증합니다. 만약 그렇다면, revocation information을 normal revocation channel(i.e. OCSP)에 publish 하고 브라우저 등은 이 인증서를 더이상 사용 할 수 없음을 알게 됩니다.
