Cloudflare에서 TLS 인증서를 발급하는 데 이용하는 공적으로 신뢰할 수 있는 인증 기관(CA)인 Let's Encrypt에서는 두 가지 별개의 인증서 체인에 의존합니다. 하나는 2000년부터 사용되어 온 세계적으로 신뢰받는 CA인 IdenTrust와 교차 서명한 인증서이고, 다른 하나는 Let's Encrypt의 자체 루트 CA인 ISRG Root X1입니다. Let's Encrypt가 출시된 이래, ISRG Root X1은 자체 장치 호환성을 꾸준히 확보하고 있습니다.
2024년 9월 30일, IdenTrust와 교차 서명한 Let's Encrypt의 인증서 체인이 만료됩니다. 교차 서명이 만료되면 서버에서 더 이상 교차 서명 체인이 서명한 인증서를 제공할 수 없게 됩니다. 대신 모든 Let's Encrypt 인증서는 ISRG Root X1 CA를 사용합니다.
2016년 이후에 출시된 대부분의 장치 및 브라우저 버전에서는 ISRG Root X1이 이미 해당 클라이언트의 신뢰 저장소에 설치되어 있으므로 변경으로 인한 문제는 발생하지 않을 것입니다. 이는 최신 브라우저와 운영 체제가 민첩하고 유연하도록 설계되어, 새로운 인증 기관을 포함하도록 업데이트할 수 있는 업그레이드 가능한 신뢰 저장소를 갖추고 있기 때문입니다.
인증서 체인의 변경은 Android 버전 7.1.1(2016년 출시) 또는 이전 버전을 실행하는 장치와 같은 레거시 장치 및 시스템에 영향을 미칩니다. 그 이유는 이러한 장치가 교차 서명 체인에만 의존하고 신뢰 저장소에 ISRG X1 루트가 없기 때문입니다. 이러한 클라이언트에서 Let's Encrypt 인증서로 보호되는 도메인에 액세스하면 TLS 오류 또는 경고가 발생합니다. 저희가 직접 데이터를 살펴본 결과, 전체 Android 요청 중 2.96%가 이번 변경의 영향을 받게 될 장치에서 발생하는 것으로 나타났습니다. 이는 인터넷에 접속할 수 없게 되는 트래픽의 상당 부분을 차지합니다. Cloudflare에서는 이러한 사용자들을 온라인 상태로 유지하기 위해 최선을 다하고 있으며, 고객에게 수동으로 수정할 것을 요구하지 않고도 구형 장치에서 사용자에게 계속 서비스를 제공할 수 있도록 인증서 파이프라인을 수정할 계획입니다.
모두를 위한 더 나은 인터넷
과거에 저희는 SHA-1 기반 알고리즘이 더 이상 사용되지 않음에 따라 클라이언트를 계속 지원할 수 있도록 "No Browsers Left Behind(뒤처지는 브라우저 없음)"와 같은 노력에 투자했습니다. 이제는 다가오는 Let's Encrypt 변경 사항에 동일한 접근 방식을 적용하려고 합니다.
저희는 Cloudflare에서 CA에 지시하는 모든 업무 흐름에서 인증 기관으로서의 Let's Encrypt를 배제하기로 결정했고, 이는 Universal SSL 고객과 "기본 CA"를 선택하는 SSL for SaaS 이용 고객에게 영향을 미쳤습니다.
교차 서명 체인이 만료되기 전 인증서 수명 주기(90일)인 2024년 6월부터 다른 CA를 사용하기 위해 갱신 예정인 Let's Encrypt 인증서를 마이그레이션하기 시작합니다. 이 CA에서는 변경의 영향을 받는 이전 장치와의 호환성을 보장하게 됩니다. 즉, 앞으로는 고객이 Let's Encrypt를 CA에 요청한 경우에만 Let's Encrypt 인증서를 받게 됩니다.
Let's Encrypt에서 진행하고 있는 변경은 필요한 변경입니다. Cloudflare에서 새로운 표준과 프로토콜을 지원하려면 공개 키 인프라(PKI) 생태계를 더욱 민첩하게 만들어야 합니다. Let's Encrypt에서는 교차 서명 체인을 종료하여 장치, 브라우저, 클라이언트에서 적응형 신뢰 저장소를 지원하도록 압박하고 있습니다.
그러나 저희는 이와 같은 변경을 과거에도 목격한 바 있으며, 이러한 변경은 새로운 표준의 채택을 촉진하는 반면, 새로운 기술에 대한 액세스가 제한되는 경제적으로 불리한 지역의 사용자에게 더 큰 영향을 미칩니다.
Cloudflare의 사명은 더 나은 인터넷을 구축하는 것이며, 이는 전 세계 사용자를 지원하는 것을 의미합니다. 저희는 이전에 Let's Encrypt 변경에 관한 블로그 게시물을 게시한 적이 있으며, 영향을 받을 것으로 예상되는 고객은 인증 기관을 전환하도록 요청했습니다. 그러나 그러한 변경의 영향을 판단하는 것은 어렵습니다. 신뢰 저장소 비호환성으로 인한 오류율은 주로 클라이언트에게 기록되므로 도메인 소유자의 가시성이 떨어집니다. 또한 현재는 호환되지 않는 장치에서 들어오는 요청이 없을 수 있지만, 향후 사용자에게 중단 없는 액세스가 보장되지는 않습니다.
Cloudflare의 인증서 파이프라인은 수년에 걸쳐 진화하여 탄력적이고 유연하므로, 고객에게 부정적인 영향을 주지 않으면서 이와 같은 변화에 원활하게 적응할 수 있습니다.
Cloudflare에서 강력한 TLS 인증서 파이프라인을 구축한 방법
현재 Cloudflare에서는 고객을 대신하여 수천만 개의 인증서를 관리합니다. Cloudflare에게 성공적인 파이프라인이란 다음과 같습니다.
고객은 언제나 자신의 도메인에 대한 TLS 인증서를 받을 수 있음
CA 관련 문제가 고객의 인증서 획득 능력에 전혀 영향이 없음
모범적 보안 관행 및 최신 표준을 활용함
향후 확장을 위한 최적화 가능
다양한 클라이언트 및 장치 지원
Cloudflare에서는 최고 수준의 서비스를 유지하기 위해 매년 인증서 파이프라인에 새로운 최적화를 도입합니다. 그 방법은 다음과 같습니다...
고객이 항상 도메인에 대한 TLS 인증서를 받을 수 있도록 보장
2014년 Universal SSL 서비스를 출시한 이래, Cloudflare에서는 네트워크로 보호되는 모든 도메인에 TLS 인증서를 발급하고 제공하는 업무를 담당해 왔습니다. 이는 사소해 보일 수도 있지만, 도메인에서 인증서를 받으려면 성공적으로 실행해야 하는 몇 가지 단계가 있습니다.
도메인 소유자는 인증서를 발급하고 갱신할 때마다 도메인 제어 유효성 검사를 완료해야 합니다.
인증 기관에서는 도메인 제어 유효성 검사 토큰을 확인하여 인증서를 발급해야 합니다.
도메인에 어느 CA를 사용할 수 있는지 지정하는 CAA 레코드를 확인하여 권한 있는 당사자만 인증서를 발급할 수 있도록 해야 합니다.
인증 기관에서 인증서를 발급할 수 있어야 합니다.
이러한 각 단계에는 도메인 소유자, CDN, 인증 기관 등 여러 당사자 간의 조정이 필요합니다. Cloudflare에서는 당사 플랫폼의 성공에 관해서 제어 능력을 갖기를 원합니다. 그래서 저희는 이러한 각 단계를 성공적으로 완료하는 것을 저희 업무로 수행하고 있습니다.
Cloudflare에서는 인증서 발급 및 갱신 시 고객의 노력이 최소화되도록 보장합니다. 인증서를 받으려면 도메인 소유자는 도메인 제어 유효성 검사(DCV)를 완료하여 실제로 도메인을 소유하고 있음을 입증해야 합니다. 인증서 요청이 시작되면 CA는 도메인 소유자가 DNS 레코드 또는 HTTP 토큰에 배치해야 하는 DCV 토큰을 반환합니다. Cloudflare를 DNS 공급자로 사용하는 경우 Cloudflare에서는 CA에서 반환된 TXT 토큰을 DNS 레코드에 자동으로 배치하여 사용자를 대신하여 DCV를 완료합니다. 또는 외부 DNS 공급자를 이용하는 경우 고객 개입 없이 자동 갱신을 위해 Cloudflare에 DCV를 위임하는 옵션을 제공합니다.
DCV 토큰이 배치되면 인증 기관(CA)에서 이를 유효성 검사합니다. CA에서는 스푸핑 시도를 방지하기 위해 여러 시점에서 이 확인을 수행합니다. 그러나 이러한 검사는 여러 국가 및 자율 시스템(ASN)에서 수행되므로 이로 인해 Cloudflare WAF 규칙이 트리거되어 DCV 검사가 차단될 수 있습니다. Cloudflare에서는 DCV가 성공적으로 완료될 수 있도록 이러한 요청이 차단되지 않도록 하기 위해, 이러한 요청이 CA에서 온 것임을 인식하도록 WAF 및 보안 엔진을 업데이트했습니다.
내부 요건 또는 규제 준수로 인해 CA 기본 설정이 있는 고객도 있습니다. 승인되지 않은 CA에서 도메인에 대한 인증서를 발급하지 못하도록 하기 위해 도메인 소유자는 CAA(Certification Authority Authorization) DNS 레코드를 만들어 해당 도메인에 대한 인증서를 발급할 수 있는 CA를 지정할 수 있습니다. 고객이 항상 인증서를 받을 수 있도록 Cloudflare에서는 인증서를 요청하기 전에 CAA 레코드를 확인하여 어떤 CA를 사용해야 하는지 파악합니다. CAA 레코드가 Cloudflare의 파이프라인에서 사용할 수 있는 모든 CA를 차단하고 고객이 선택한 CA의 인증서를 업로드하지 않은 경우, Cloudflare는 고객을 대신하여 CAA 레코드를 추가하여 고객이 인증서를 발급받을 수 있도록 합니다. 저희는 가능한 한 선호도에 따라 최적화합니다. 그렇지 않은 경우, 선호하는 CA에서 제공되지 않은 경우에도 도메인에 항상 TLS 인증서를 사용할 수 있도록 하여 중단을 방지하는 것이 저희 임무입니다.
현재 Cloudflare에서는 공적으로 신뢰할 수 있는 인증 기관이 아니므로 높은 가용성을 위해 CA에 의존합니다. 하지만 100%의 가용 시간을 기대하는 것은 현실적이지 않습니다. 대신 CA를 이용할 수 없게 될 경우에 대비하여 저희 파이프라인을 준비해야 합니다.
CA 관련 문제가 고객의 인증서 획득 능력에 영향을 미치지 않도록 보장하기
Cloudflare에서는 사고가 발생하기 전에 예방하는 것, 즉 미리 생각하는 것을 선호합니다. CA를 이용할 수 없게 되는 것은 드문 일이 아닙니다. 때로는 정전으로 인해 이런 일이 발생하는 경우도 있지만, 대부분의 경우 CA에는 유지 관리 기간이 있어 일정 기간 이용할 수 없게 됩니다.
CA 이중화를 보장하는 것이 저희 임무이므로 항상 인증서를 발급할 수 있는 여러 CA를 준비하여 항상 고가용성을 보장합니다. Universal SSL 인증서를 발급하는 다른 CA를 발견했다면 이는 의도적인 것입니다. 단일 장애 지점을 방지하기 위해 CA 전체에 로드를 균등하게 분산합니다. 또한 대기 시간과 오류율을 면밀히 관찰하여 문제를 감지하고 사용 가능하고 성능이 뛰어난 다른 CA로 자동 전환합니다. 모르실 수도 있지만, 저희가 이용하는 CA 중 하나에서는 매달 약 4회의 유지 관리 기간이 예정되어 있습니다. 이런 일이 발생하면 자동화된 시스템이 원활하게 시작되어 모든 것이 원활하게 실행됩니다. 이 시스템은 매우 잘 운영되어 모든 것이 제대로 작동하므로 내부 팀에서 더 이상 호출을 받지 않습니다.
보안 모범 사례 및 최신 표준 채택
보안은 Cloudflare의 최우선 순위였으며 앞으로도 그럴 것이므로 고객의 데이터와 개인 키를 보호하기 위해 가장 높은 보안 표준을 유지하는 것은 매우 중요합니다.
지난 10년 동안 CA/Browser Forum에서는 인증서 유효 기간을 업계 표준으로 5년에서 90일로 단축할 것을 주장해 왔습니다. 이러한 변화는 키 손상 위험을 최소화하는 데 도움이 됩니다. 인증서가 90일마다 갱신되면, 인증서의 개인 키는 해당 기간 동안만 유효하므로 악의적인 행위자가 손상된 자료를 이용할 수 있는 기간이 줄어듭니다.
Cloudflare에서는 이러한 변화를 완벽하게 수용했으며, 기본 인증서 유효 기간을 90일로 설정했습니다. 이를 통해 정기적인 키 교체가 보장되므로 보안 상태가 강화되며, 추가적인 오버헤드 없이 인증서의 빈번한 갱신에 맞추어 자동화를 촉진하는 DCV 위임과 같은 도구를 개발할 수 있게 되었습니다. 이를 통해 인증서 갱신 실패에 대한 걱정 없이 개인 키를 자주 교체하려는 고객을 위해 2주 정도로 유효 기간이 짧은 인증서를 제공할 수 있습니다.
Cloudflare는 항상 새로운 프로토콜 및 표준의 최전선에 있었습니다. 새로운 프로토콜을 지원하면 채택률이 급증한다는 것은 잘 알려진 사실입니다. 이번 달에 Google Trust Services에서 발급한 인증서에 대한 ECDSA 지원을 추가할 예정입니다. ECDSA를 사용하면 RSA와 동일한 수준의 보안을 얻을 수 있지만, 더 작은 키를 사용합니다. 키가 작다는 것은 인증서가 작아지고 TLS 연결을 설정하기 위해 전달되는 데이터가 적다는 것을 의미하므로 연결이 빨라지고 로드 시간이 빨라집니다.
향후 확장을 위한 최적화 가능
현재 Cloudflare에서는 매일 거의 100만 개의 인증서를 발급합니다. 최근에 인증서 수명을 단축하는 추세로 전환됨에 따라 저희는 파이프라인을 계속 개선하고 있습니다. 하지만 저희 파이프라인이 상당한 로드를 처리할 수 있더라도, 저희와 함께 확장하려면 여전히 CA에 의존해야 합니다. 통합하는 모든 CA의 경우 저희는 즉시 해당 CA의 가장 큰 소비자 중 하나가 됩니다. Cloudflare에서는 CA에게 높은 기준을 적용하고 확장 가능하도록 인프라를 개선하도록 독려합니다. 이는 Cloudflare 고객에게 도움이 될 뿐만 아니라, CA에서 대량의 발급을 처리하도록 함으로써 인터넷에도 도움이 됩니다.
이제 Let's Encrypt의 신뢰 체인 단축에 따라 파이프라인에 개선 사항을 추가하여 모두에게 최고의 장치 호환성을 보장할 수 있습니다.
레거시 및 최신 클라이언트를 비롯한 모든 클라이언트 지원
예정된 Let's Encrypt 변경 사항이 적용되면 레거시 장치에서는 Let's Encrypt 인증서로 보호되는 도메인이나 앱에 요청을 할 수 없게 됩니다. Cloudflare에서는 인터넷 액세스가 세계 어느 곳에서도 중단되지 않도록 하기 위해, 이러한 변화에도 불구하고 고객에게 최고의 장치 호환성을 계속 제공하고자 합니다.
최근의 모든 개선 사항 덕분에 저희는 인증서 파이프라인의 서비스 품질이나 신뢰성에 영향을 주지 않으면서 Let's Encrypt에 대한 의존도를 줄일 수 있게 되었습니다. 변경 전 인증서 수명 주기(90일) 전에 영향을 받는 장치와 호환되는 다른 CA를 사용하도록 인증서 이동을 시작할 예정입니다. 이렇게 함으로써 고객이 별도의 조치를 취하지 않아도 받게 될 영향이 줄어듭니다. Let's Encrypt를 계속 사용할 고객은 Let's Encrypt를 CA로 선택한 고객뿐입니다.
예정된 Let's Encrypt 변경에서 예상되는 사항
Let's Encrypt의 교차 서명 체인은 2024년 9월 30일에 만료됩니다. Let's Encrypt에서는 2024년 6월 6일에 이 체인에서 인증서 발급을 중단할 계획이지만, Cloudflare에서는 2024년 9월 9일까지 모든 Let's Encrypt 인증서에 대해 교차 서명된 체인을 계속 제공할 예정입니다.
변경 전 90일 또는 인증서 수명 주기 전에 Let’s Encrypt 인증서를 다른 인증 기관을 사용하도록 전환하기 시작할 예정입니다. Cloudflare가 CA 선택을 담당하는 모든 제품에 대해 이러한 변경을 적용할 예정입니다. 즉, "기본 CA" 선택과 함께 Universal SSL 및 SSL for SaaS를 사용하는 고객에 대해 이 변경이 자동으로 수행됩니다.
Let's Encrypt를 CA로 선택한 모든 고객에게는 Let's Encrypt 인증서 목록과 함께 레거시 장치에서 해당 호스트 이름을 사용하고 있는지 여부에 대한 정보가 포함된 이메일 알림이 발송됩니다.
2024년 9월 9일 이후, Cloudflare에서는 ISRG Root X1 체인을 사용하여 모든 Let's Encrypt 인증서를 제공합니다. 사용 중인 인증서 제품에 따라 다음과 같은 결과를 예상해야 합니다.
Universal SSL
Universal SSL을 사용할 경우 Cloudflare에서는 도메인의 인증서에 사용되는 CA를 선택합니다. 따라서 Cloudflare에서는 고객을 위한 최상의 인증서를 선택할 수 있습니다. Universal SSL을 사용하는 경우에는 이러한 변경에 대비하기 위해 어떠한 변경 작업도 하지 않아도 됩니다. Cloudflare에서는 호환성이 더 높은 CA를 사용하도록 인증서를 자동으로 전환합니다.
고급 인증서
Advanced Certificate Manager를 사용할 경우 고객은 사용하려는 CA를 구체적으로 선택합니다. Let’s Encrypt가 인증서의 CA로 특별히 선택된 경우 고객이 내부 요구 사항으로 인해 이 CA를 특별히 선택했을 수 있으므로 그 선택을 존중하지만, 인증서 고정을 구현한 경우에는 이를 권장하지 않습니다.
Let's Encrypt에서 발급된 고급 인증서를 사용하는 도메인이 변경 사항의 영향을 받는 것으로 확인되면 고객에게 어떤 인증서가 Let's Encrypt를 CA로 사용하고 있는지, 해당 도메인이 변경으로 인해 영향을 받을 클라이언트로부터 요청을 받고 있는지 여부를 알리기 위해 이메일 알림을 보냅니다. CA를 다른 공급자로 변경하기로 선택한 경우, 그에 대한 책임은 고객이 집니다.
SaaS용 SSL
SSL for SaaS의 경우 고객에게는 두 가지 옵션이 있습니다. 기본 CA를 사용하여 Cloudflare에서 발급 기관을 선택하거나, 사용할 CA를 지정하는 것입니다.
CA 선택을 Cloudflare에 맡기는 경우, Cloudflare에서는 자동으로 장치 호환성이 더 높은 CA를 이용합니다.
사용자 지정 호스트 이름으로 특정 CA를 지정하면 Cloudflare에서는 그 선택을 존중합니다. 저희는 SaaS 공급자 및 플랫폼에 이메일을 보내 어떤 사용자 지정 호스트 이름이 레거시 장치로부터 요청을 수신하는지 알려주게 됩니다. CA를 다른 공급자로 변경하기로 선택한 경우, 그에 대한 책임은 고객이 집니다.
사용자 지정 인증서
Let's Encrypt와 직접 통합하고 사용자 지정 인증서를 사용하여 Let's Encrypt 인증서를 Cloudflare에 업로드하는 경우 "호환" 또는 "최신" 번들 방법을 선택하고 이 인증서를 2024년 9월 9일 이전에 업로드하는 한 인증서는 교차 서명된 체인과 함께 번들로 제공됩니다. 9월 9일 이후에는 모든 Let's Encrypt 인증서를 ISRG 루트 X1 체인과 함께 번들로 제공합니다. "사용자 정의" 번들 방법을 사용하면 항상 Cloudflare에 업로드된 체인을 제공합니다. 이 방법을 사용하여 Let's Encrypt 인증서를 업로드하는 경우 CA 만료 날짜인 2024년 9월 30일 이후에 업로드된 인증서에 올바른 인증서 체인이 포함되어 있는지 확인해야 합니다.
또한, 앱에 연결되는 클라이언트를 관리하고 있다면 ISRG Root X1을 포함하도록 신뢰 저장소를 업데이트하는 것을 권장합니다. 인증서 고정을 사용하는 경우, 핀을 제거하거나 업데이트하세요. 일반적으로 모든 고객이 인증서를 고정하지 않는 것을 권장합니다. 그럴 경우 일반적으로 인증서 갱신 또는 CA 변경 중에 문제가 발생하기 때문입니다.
결론
인터넷 표준은 계속 진화되고 개선될 것입니다. 우리는 이러한 변화를 지지하고 수용하면서 새로운 기술을 쉽게 사용할 수 없는 지역에서 사용자를 온라인 상태로 유지하고 인터넷 액세스를 유지하는 것이 우리의 책임임을 인식해야 합니다. Cloudflare를 사용하면 언제든 앱에 가장 적합한 설정을 선택할 수 있습니다.
추가적인 변경 사항은 개발자 문서를 참고하시기 바랍니다.