최근 업데이트: | 모든 문서 보기
이 글은 호스팅 제공자나 큰 웹 사이트에 Let’s Encrypt를 통합시키거나 Let’s Encrypt에 대한 클라이언트 소프트웨어를 만들고 있는 귀하에게 도움이 되는 조언을 포함하고 있습니다.
변화 계획
Let’s Encrypt와 웹 PKI는 계속 성장할 것입니다. 귀하는 Let’s Encrypt를 사용하면서 모든 서비스들을 쉽게 업데이트할 능력이 있어야 합니다. Let’s Encrypt 증명서들을 신뢰하는 클라이언트에게 배포한다면, 클라이언트들이 정기적인 업데이트를 받도록 확인하십시오.
앞으로 아래 사항들이 변화할 예정입니다:
- 저희가 발급한 root와 중간 인증서
- 저희가 인증서 서명에 사용한 해시 알고리즘
- 저희가 최종 사용자 인증서를 서명하기로 한 키들의 종류와 키 강도 점검
- 그리고 ACME 프로토콜
저희는 이러한 변화에 가능한 많은 사전 통지를 제공하는 것을 목표로 할 것입니다. 그러나 일부 구성 요소에서 심각한 보안 결함이 발견되는 경우, 매우 짧은 기간 또는 즉시 변경해야 할 수 있습니다. 특히 중급 사항을 적용하는 경우, 중간 인증서를 하드코딩해서는 안되지만 중간 인증서가 변경될 가능성이 있으므로 ACME 프로토콜의 Link: rel="up" 헤더를 사용하시길 바랍니다.
마찬가지로, 업데이트 후 URL의 서비스 약관(ToS)도 변경될 수 있습니다. 하드코딩된 ToS URL을 피하고 대신 Link: rel="terms-of-service" 헤더를 사용하여 사용할 ToS URL을 결정하십시오.
새로운 공격이 암호화 스위트 또는 프로토콜 버전에서 발견될 때마다 귀하의 TLS 구성을 최신 상태로 유지하는 방법이 필요할 것입니다.
업데이트 받기
위에서 설명한 것과 같이 중요한 변동사항과 같은 소량의 업데이트를 받으려면 저희 API Announcements 그룹에 가입하세요. 클라이언트 개발자와 호스팅 제공업체 모두에게 유용합니다.
유지 보수 및 중단에 대한 대량 업데이트는 상태 페이지를 방문하고 우측 상단의 가입을 눌러주세요. 호스팅 업체에게 가장 유용합니다.
또한 ACME 계정에 유효한 이메일 주소를 사용했는지 확인하십시오. 해당 이메일로 만료 통지와 귀하의 계정과 관련된 모든 문제에 대해 알릴 예정입니다.
가입자는 누구인가
CPS와 가입자 동의서는 가입자가 인증서의 개인키를 보유하고 있는 사람임을 나타냅니다. 호스팅 제공업체의 경우, 공급자의 고객이 아니라 공급자를 나타냅니다. 사람들이 스스로 배포하는 소프트웨어를 만드는 사람은 누구든지 소프트웨어를 배포하는 사람입니다.
가입자에게 계정을 만들 때 (등록이라고도 함) 이메일이 제공됩니다. 해당 주소로 유효 기간이 만료됨을 경고하거나, 개인정보 취급방침의 변경사항을 알리기 위해 이메일을 보낼 것입니다. 귀하가 호스트 제공업체라면, 고객이 아닌 사용자에게 이러한 알림이 전달되어야 합니다. 귀하가 휴가일 때도 다양한 사람이 알림에 응답할 수 있도록 메일링 리스트나 별칭을 설정하는 것이 가장 이상적입니다.
이 방법은 결과적으로, 귀하 고객들의 이메일 주소를 저희에게 보내거나 가입자 계약에 동의하지 않아도 됩니다. 귀하가 제어하는 도메인에 대한 인증서를 발급하고 인증서를 사용하면 됩니다.
하나 또는 다수의 계정
ACME에서는 모든 권한 부여 및 발급을 위해 하나의 계정을 만들어 사용하거나 고객 당 하나의 계정을 만들 수 있습니다. 이러한 유연성은 가치가 있습니다. 예를 들어, 호스팅 제공업체에 따라 고객별로 하나의 계정을 사용하여 다른 컨텍스트에 계정 키를 저장함으로써, 계정 키가 모든 고객에게 발급되지 못하도록 할 수 있습니다.
그러나 대부분의 호스팅 업체의 경우는 단일 계정을 사용하여 해당 계정의 키를 보호하는 것을 권장합니다. 동일한 사용자에 속하는 인증서를 더 쉽게 식별하고, 연락처 정보를 최신 상태로 유지하고, 필요한 경우 요금제한 조정기능을 제공하기 쉽습니다. 만약 많은 계정을 사용한다면, 저희는 효과적으로 요금 한도를 조절할 수 없을 것입니다.
멀티 도메인 (SAN) 인증서
저희 발급 정책은 인증서당 100명까지 허용합니다. 호스트 이름마다 별도의 인증서를 사용할지, 아니면 적은 수의 인증서로 다수의 호스트 이름을 그룹화할지 귀하가 선택하면 됩니다.
호스트 이름당 인증서를 사용하는 것은 제공하고 회수되는 도메인을 논리적으로 추가 및 제거하는 데 필요한 부분이 줄어드는 것을 의미합니다. 별도의 인증서를 사용하면 인증서의 크기를 최소화 할 수 있으므로 낮은 대역폭 네트워크에서 HTTPS handshake의 속도를 높일 수 있습니다.
반면, 호스트 이름이 다수인 큰 인증서를 사용하면 전체적으로 더 적은 인증서를 관리할 수 있습니다. TLS 서버 이름 정보(SNI)를 지원하지 않는 윈도우 XP와 같은 이전 클라이언트를 지원하는 경우, 모든 인증서에 대해 고유한 IP 주소가 필요하므로 각 인증서에 더 많은 이름을 삽입하면 귀하가 필요로 하는 IP 주소가 줄어들 것입니다.
대부분의 배포에서는 두 옵션이 동일한 보안 수준을 제공합니다.
인증서와 키의 보관 및 재사용
Let’s Encrypt의 가장 큰 가치는 새로운 웹 사이트를 제공할 때 자동 발급을 허용한다는 것입니다. 그러나, 동일한 웹 사이트에 대해 새로운 프론트엔드를 반복적으로 만드는 인프라를 사용하는 경우에는 먼저 스토리지의 인증서와 개인키를 사용해야 하고, 사용 가능한 인증서가 없는 경우 새로 발급 받거나 모든 인증서가 만료되어야 합니다.
Let’s Encrypt의 경우, 이를 통해 최대한 많은 사람들에게 효율적으로 서비스를 제공할 수 있습니다. 이렇게 하면 Let’s Encrypt의 상태에 관계없이 필요할 때마다 웹 사이트를 배포할 수 있습니다.
예를 들어, 많은 사이트에서 필요에 따라 새 프론트엔드 인스턴스를 제공하는 데 Docker 컨테이너를 사용하기 시작했습니다. Docker 컨테이너가 시작될 때 발급하도록 설정하고 인증서와 키들을 지속적으로 저장하지 않는 경우 너무 많은 인스턴스를 한번에 표시하면 요금 제한을 초과할 수 있습니다. 최악의 경우, 모든 인스턴스를 한번에 삭제하고 다시 생성해야할 때 인증서를 받을 수 있는 인스턴스가 없어 사이트가 만료될 때까지 몇 일동안 손상될 수 있습니다. 하지만, 이러한 유형의 문제는 등급 제한에만 국한되지 않습니다. 귀하의 프론트엔드를 사용해야할 때 Let’s Encrypt가 어떤 이유로든 사용이 불가하다면, 같은 문제가 발생할 것입니다.
일부 배포 원칙에서는 암호 키가 생성된 물리적인 시스템을 그대로 두어서는 안된다고 말합니다. 이 모델은 Let’s Encrypt와 함께 잘 작동할 것이며, 시스템 및 데이터가 오래 지속되도록 확인하면서 속도 제한을 주의 깊게 관리해야 합니다.
챌린지 타입 고르기
http-01 ACME 챌린지를 사용하는 경우, 귀하가 챌린지를 수행할 준비를 Let’s Encrypt에 알리기 전에 귀하의 각 프론트엔드에 챌린지 응답을 제공해야 합니다. 귀하가 많은 수의 프론트엔드를 소유하고 있다면, 이것은 도전해 볼 만합니다. 이러한 경우, dns-01 챌린지가 더 쉬울 수 있습니다. 물론 지리적으로 분산되어 있는 여러 DNS 알림이 있는 경우 각 응답자에 TXT 레코드가 있는지 확인해야 합니다.
또한, dns-01 챌린지를 사용하는 경우 Let’s Encrypt의 쿼리 응답이 너무 커지지 않도록 TXT 레코드를 정리해야 합니다.
어떻게든 http-01 챌린지를 사용하고 싶다면, HTTP 리다이렉션을 활용하는 것이 좋습니다. 모든 XYZ에 대해 /.well-known/acme-validation/XYZ 에서 validation-server.example.com/XYZ 로 리다이렉션하도록 프론트엔드를 설정할 수 있습니다. 이는 유효성 검사 서버에 배포할 책임이 있으므로 해당 서버를 잘 보호해야 합니다.
중앙 유효 서버
위 두 가지와 관련하여 귀하가 많은 프론트엔드를 가지고 있다면, 발행 관리를 위해 소수의 서버로 구성하여 사용하는 것이 좋습니다. http-01 유효성 검사를 쉽게 리다이렉트할 수 있고 인증서와 키를 안전하게 저장할 수 있는 공간을 제공합니다.
OCSP를 사용하지 않도록 구현
많은 브라우저가 귀하의 사이트를 열 때 Let’s Encrypt로부터 OCSP를 불러올 것입니다. 이것은 성능과 개인정보 문제입니다. 귀하 사이트로의 연결은 Let’s Encrypt로 보조 연결을 기다리지 않아야 합니다. 또한 OCSP는 사람들이 어떤 사이트를 방문하는지 Let’s Encrypt에 요청합니다. 저희는 좋은 개인정보 보호정책을 가지고 있고 OCSP의 요청이 있어도 개인정보를 기록하지 않으며, 우선 데이터를 받지 않는 것이 낫다고 생각합니다. 또한, OCSP에 제공하는 대역폭 비용은 처음으로 브라우저가 Let’s Encrypt 사이트를 방문할 때마다 저희 인프라 비용의 큰 부분을 차지할 것으로 예상됩니다.
OCSP를 사용하지 않도록 함으로써, 귀하의 웹 사이트 성능을 향상시킬 수 있고, 사용자에게 더 나은 개인정보 보호기능을 제공하고, Let’s Encrypt가 최대한 많은 사람들에게 효율적으로 서비스할 수 있습니다.
방화벽 구성
Let’s Encrypt를 사용하려면 ACME 클라이언트를 실행하는 기계로부터 아웃바운드 포트 443 트래픽을 허용해야 합니다. ACME 서비스의 IP 범위를 게시하지 않으며 예고 없이 변경될 것입니다.
“http-01” ACME 과제의 경우, 인바운드 80 포트 트래픽을 허용해야 합니다. 유효성 검사를 위해 IP 범위를 게시하지 않으며 IP 범위는 예고없이 변경됩니다.
참고: 웹 서버에 대한 일반 HTTP 접근을 항상 허용하고 HTTP로 리다이렉션하는 것이 좋습니다. 포트 80 연결을 거절하거나 삭제하는 웹 서버보다 더 나은 사용자 환경을 제공하며 동일한 수준의 보안을 제공합니다.
모든 문제를 해결하려면,권한 있는 DNS 서버에 인바운드 포트 53 트래픽(TCP 및 UDP)를 허용해야 합니다.
지원하는 키 알고리즘
Let’s Encrypt는 2048, 3072, 4096비트 길이의 RSA 키와 P-256 또는 P-384 ECDSA 키를 사용합니다. 이는 계정 키와 인증서 키 모두 해당됩니다. 계정 키는 인증서 키로 재사용할 수 없습니다.
우리의 권장사항은 기본적으로 RSA 인증서를 제공하는 이중 인증서 구성과 지원을 나타내는 클라이언트에 대한 (더 작은) ECDSA 인증서를 제공하는 것입니다.
기본 HTTPS
호스팅 제공업체의 경우, 자동적으로 인증서를 발급하고 귀하의 설정에 따라 모든 호스트 이름에 대해 HTTPS를 구성하며, HTTP 또는 HTTPS URL로 리다이렉트 여부에 대해 사용자 설정을 제공하는 것이 좋습니다. 기존 계정의 경우 기본값으로 사용하지 않도록 설정되어 있지만, 신규 계정의 경우 기본값으로 허용하도록 설정하는 것을 권장합니다.
추론: 기존 웹 사이트들은 HTTP 서브 리소스 (스크립트, CSS 및 이미지)를 포함할 수 있습니다. 이 사이트들이 자동적으로 HTTPS 버전으로 리다이렉트 한다면 브라우저는 혼합된 컨텐츠 차단에 의해 이 서브 리소스들을 차단할 것입니다. 따라서 이 사이트의 기능을 제한할 수 있습니다. 하지만, 사이트를 새로 만들거나 HTTPS로 리다이렉트하는 사이트를 만든 사람은 HTTPS 서브 리소스만 포함했을 가능성이 높습니다. 만약 HTTP 서브 리소스를 포함하려고 한다면,, 그 웹 사이트가 제대로 동작하지 않는다고 통지할 것입니다.
저희는 고객들에게 기본값으로 설정된 60일의 기간을 가진 HTTP 제한 전송 보안(HSTS) 헤더를 사용하는 것을 권장합니다. 그러나 이 설정은 HTTPS를 제공하지 않는 호스팅 업체로 이동해야 하는 안내가 동반되야 하고, 브라우저 내 캐시된 HSTS 설정은 해당 사이트를 이용 불가하게 만들 것입니다. 고객과 호스트 제공업체는 HSTS 헤더가 심각한 실패로 인증서 에러가 발생할 수 있다는 사실을 알아야 합니다. 이 경우에 이름 불일치나 만료된 인증서에 대한 브라우저 경고를 클릭할 수 있지만, 브라우저는 활성 HSTS 헤더가 있는 호스트 이름을 클릭하는 것을 허용하지 않습니다.
갱신해야 할 시기
전체 수명의 1/3이 남아 있는 경우, 인증서를 자동으로 갱신하는 것이 좋습니다. 90일의 기간을 가진 Let’s Encrypt의 인증서는 만료 30일 전에 갱신해야 한다는 것입니다.
10,000개 이상의 호스트 이름을 위해 발급하는 경우, 갱신을 큰 부분으로 일괄 처리하는 대신에 소규모 실행으로 자동 갱신하는 것도 권장합니다. 이 방법은 위험이 감소됩니다: Let’s Encrypt에 갱신이 필요한 시점에 운영 중단이 있거나 시스템에 일시적인 장애가 있는 경우, 모든 인증서가 아니라 일부 인증서에만 영향을 미칩니다. 또한 저희의 수용량 계획이 쉬워집니다.
모든 도메인이 신속하게 시작할 수 있도록 인증서를 다량 발행하는 것이 좋습니다. 그런 다음, 일반적으로 갱신하기 하루 전에 일부 인증서를 갱신하는 일회성 프로세스를 수행하고 일부는 일반적으로 이틀 전에 갱신하도록 하는 등의 방법으로 갱신 시간을 분산시킬 수 있습니다.
정기적인 배치 작업을 자동으로 구성하는 클라이언트 소프트웨어를 제공하는 경우, 항상 특정 시간에 실행되지 않고 당일 중 임의의 시간 간격으로 실행되도록 하십시오. 이렇게 하면 Let’s Encrypt가 임의적인 트래픽 급증을 받지 않도록 보장합니다. Let’s Encrypt가 최대 부하를 충족하기 위해 허용량을 제공해야 하는 상황에서 트래픽 급증을 줄이는 것이 비용 절감에 도움이 될 것입니다.
실패 재시도
갱신 실패를 치명적인 오류로 간주해서는 안됩니다. 귀하의 발급 서비스에서 지수적인 백오프 패턴을 사용하여 인증서 하나당 하루에 한 번씩 최대값을 초과하는 점진적 재시도 논리를 구현해야 합니다. 예를 들어, 효과적인 백오프 일정은 다음과 같습니다: 1분 후에 첫 번째 시도, 10분 후에 두 번째 재시도, 100분 후에 세 번째 재시도, 하루 뒤에 4번째 그리고 연속적인 재시도입니다. 물론 관리자가 도메인 단위 또는 글로벌 단위로 초기에 재시도를 요청할 수 있는 방법이 있습니다.
재시도를 철회한다는 것은 귀하의 발급 소프트웨어가 실패와 성공 여부를 계속 추적하고, 신규 발행을 시도하기 전에 최근에 실패한 부분이 있는지 확인한다는 것을 의미합니다. 반복적인 실패는 영구적일 수 있기 때문에 시간당 수백 번 발행을 시도하는 것은 의미가 없습니다.
모든 오류는 특정 문제가 해결되야 하는지 확인하기 위해 담당 관리자에게 전송되어야 합니다.