Let’s Encrypt에서 인증서를 발급받을 때, 서버에서는 ACME 표준에 정의된 “챌린지(검증 방식)“를 사용하여 해당 인증서의 도메인 이름을 제어하고 있는지 검증합니다. 이 검증 과정은 대개 ACME 클라이언트에서 자동으로 처리하지만, 복잡한 설정이 필요한 경우에는 챌린지에 대해 더 자세히 알아두는 것이 좋습니다. 잘 모르겠다면 클라이언트의 기본값이나 HTTP-01을 선택하세요.
오늘날 가장 널리 쓰이는 챌린지 유형입니다. Let’s Encrypt는 ACME 클라이언트에 토큰을 주고 ACME 클라이언트는 http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN>의 웹서버에 파일을 저장합니다. 해당 파일에는 토큰과 함께 계정 키의 지문이 포함됩니다. ACME 클라이언트가 Let’s Encrypt에 파일이 준비되었음을 알리면 Let’s Encrypt는 여러 유리한 지점에서 어쩌면 여러 번 해당 파일을 찾기 위해 노력합니다. 검증 과정에서 웹 서버로부터 올바른 응답을 받으면, 검증에 성공한 것으로 간주되어 인증서를 발급받을 수 있습니다. 만약 검증에 실패하면, 새로운 인증서로 다시 시도해야 합니다.
우리의 HTTP-01 챌린지의 구현은 최대 10개의 리다이렉션까지 리다이렉션을 따릅니다. “http:” 또는 “https:“로의 리다이렉션만 허용하고 80번 포트나 443번 포트로만 리다이렉션합니다. HTTPS URL로 리다이렉트될 때는 인증서를 검증하지 않습니다. [이 챌린지 자체가 유효한 인증서를 부트스트랩(발급)하기 위한 과정이므로 도중에 자체 서명되었거나 만료된 인증서를 마주할 수 있기 때문입니다.]
HTTP-01 챌린지는 80번 포트에서만 수행할 수 있습니다. 클라이언트가 임의의 포트를 지정할 수 있도록 허용하면 챌린지의 보안성이 떨어지므로, ACME 표준에서는 이를 허용하지 않습니다.
장점:
단점:
이 챌린지는 해당 도메인 이름 아래 TXT 레코드에 특정 값을 넣어 도메인 이름의 DNS를 제어 함을 증명하도록 요청합니다. HTTP-01보다 구성하기가 어렵지만 HTTP-01이 할 수없는 시나리오에서는 작동 할 수 있습니다. 또한 당신이 와일드 카드 인증서를 발행할 수 있도록 해줍니다. Let’s Encrypt가 ACME 클라이언트에 토큰을 제공하면 클라이언트는 해당 토큰과 계정 키에서 파생된 TXT 레코드를 생성하고 해당 레코드를_acme-challenge. <YOUR_DOMAIN>에 넣습니다. 그러면 Let’s Encrypt가 해당 레코드에 대한 DNS 시스템을 쿼리합니다. 일치하는 것이 있으면 인증서 발급을 진행할 수 있습니다!
발급 및 갱신 자동화는 매우 중요하므로 DNS 공급자에 업데이트 자동화에 사용할 수있는 API가있는 경우 DNS-01 문제를 사용하는 것이 좋습니다. 우리 커뮤니티는 DNS 제공 업체 목록을 시작했습니다. DNS 제공 업체는 등록 기관(도메인 이름을 구입한 회사)과 같거나 다를 수 있습니다. DNS 공급자를 변경하려면 등록 기관에서 약간만 변경하면됩니다. 도메인이 만료 될 때까지 기다릴 필요가 없습니다.
웹 서버에 전체 DNS API 자격 증명을 저장하면 해당 웹 서버가 해킹당했을 때 피해 규모가 크게 커질 수 있으므로 주의해야 합니다. 가장 좋은 사례는 좀 더 좁은 범위의 API 자격 증명을 사용하거나 별도의 서버에서 DNS 유효성 검사를 수행하고 인증서를 웹 서버에 자동으로 복사하는 것입니다.
Let’s Encrypt는 DNS-01 유효성 검사를 위해 TXT 레코드를 찾을 때 DNS 표준을 따르므로 CNAME 레코드 또는 NS 레코드를 사용하여 도전에 대한 답변을 다른 DNS 영역에 위임할 수 있습니다. 이것은 유효성 검사별 서버 또는 영역에 _acme-challenge 하위 도메인을 위임하는 데 사용될 수 있습니다. 이것은 DNS 제공 업체의 업데이트 속도가 느려서 빠른 업데이트 서버에 위임하려는 경우에도 사용할 수 있습니다.
대부분의 DNS 제공자는 DNS 레코드를 업데이트하는 시간부터 모든 서버에서 사용할 수 있을 때까지 걸리는 시간을 결정하는 “지연 시간"을 가지고 있습니다. 또한 anycast를 자주 사용하기 때문에 이 문제를 측정하기가 어려울 수 있습니다. 즉, 여러 서버가 동일한 IP 주소를 가질 수 있으며, 사용자가 어디에 있는지 여부에 따라 Let’s Encrypt가 하는 것과 다른 서버와 통신하여 다른 대답을 얻을 수도 있습니다. 우수한 DNS API는 업데이트가 완전히 전파되었는지 자동으로 확인할 수 있는 방법을 제공합니다. 사용하는 DNS 서비스에 해당 기능이 없는 경우, 검증을 요청하기 전에 업데이트가 확실히 전파될 수 있도록 클라이언트가 충분한 시간 동안 (최대 1시간까지) 대기하도록 설정해야 합니다.
동일한 이름의 TXT 레코드를 여러 개 배치할 수 있습니다. 예를 들어 와일드카드와 비와일드카드 인증서에 대한 과제를 동시에 검증하는 경우 이 기능을 사용할 수 있습니다. 그러나 응답 크기가 너무 커지면 Let’s Encrypt에서 거부하기 시작하므로 이전 TXT 레코드를 정리해야 합니다.
장점:
단점:
이 챌린지는 TLS-SNI-01이 폐기된 이후 개발되었으며, 현재는 RFC 8737 표준입니다. TLS-SNI-01과 마찬가지로 443번 포트에서 TLS를 통해 수행됩니다. 그러나 사용자 지정 ALPN 프로토콜을 사용하여 이 문제 유형을 알고 있는 서버만 유효성 검사 요청에 응답하도록 합니다. 또한 이 챌린지 유형에 대한 유효성 검사 요청이 유효성 검사 중인 도메인 이름과 일치하는 SNI 필드를 사용하므로 보안이 향상됩니다.
이 문제는 대부분의 사람들에게 적합하지 않습니다. 이는 HTTP-01과 같은 호스트 기반 유효성 검사를 수행하려는 TLS 종료 역방향 프록시의 작성자에게 가장 적합하지만 문제를 분리하기 위해 TLS 계층에서 완전히 수행하기를 원합니다. 현재로서는 주로 대규모 호스팅 제공업체를 의미합니다.
장점:
단점:
이 챌린지는 ACME 초안 버전에서 정의되었습니다. 포트 443에서 TLS 핸드셰이크를 수행하고, 특정 SNI 헤더를 전송하여 토큰이 포함된 인증서를 찾는 방식으로 동작했습니다. 보안성이 충분하지 않다는 이유로 2019년 3월에 제거되었습니다.