eMudhra to Exit Global SSL/TLS Business After 8 Intermediate CA Keys Found Easily Guessable
중간 CA 키 8개가 쉽게 추측되자 eMudhra, 글로벌 SSL/TLS 사업 철수
인도 인증기관 eMudhra가 중간 인증기관(CA) 키 8개가 쉽게 추측되는 값으로 드러난 뒤 글로벌 SSL/TLS 사업에서 철수하기로 했습니다. Chrome과 Firefox의 신뢰 중단으로 약 3만 800개의 인증서가 영향을 받으며, ACME 자동 갱신 환경도 별도 이전 작업이 필요합니다.
- 주제
에디터 노트
이번 사건에서 사업 철수보다 구체적인 부담은 인증서 교체 방식에 있습니다. 약 3만 개 가운데 ACME 발급분이 97%지만 일반 클라이언트는 갱신 시점 전에 인증서를 바꾸지 않으므로, 운영자가 ARI 지원 여부와 클라이언트 설정을 확인해야 합니다. 인증서 발급을 중단하는 결정만으로 서비스 전환이 끝나지 않는 이유입니다. eMudhra는 문제의 키로 웹사이트 인증서를 발급하지 않았고 CT 로그에서도 차단 전 관련 인증서가 발견되지 않았다고 밝혔습니다. 반면 Firefox와 Chrome의 신뢰 중단은 해당 ECC 루트 아래의 정상 인증서까지 영향을 주며, 2025년 CRL 처리와 이번 설명을 둘러싼 Chrome의 질문도 남아 있습니다. Reddit에서는 다른 디지털 신원 제품까지 믿기 어렵다는 반응과 실제 인증서 교체에 하루를 썼다는 경험이 나왔습니다. 다만 다른 사업 제품의 키 관리 결함이 확인됐다는 근거는 이 자료에 없습니다.
AI 요약
인도 인증기관 eMudhra는 중간 인증기관(Intermediate CA) 인증서 8개의 개인 키를 연구자가 복구한 뒤 글로벌 SSL/TLS 인증서 사업에서 철수한다고 발표했습니다. 이사회는 연구자가 문제를 신고한 지 5일 뒤인 목요일에 철수를 결정했습니다. eMudhra는 영향을 받는 고객에게 파트너사가 발급한 무료 인증서를 제공하겠다고 밝혔지만, 파트너사 이름과 철수 일정은 공개하지 않았습니다.
키 유출과 브라우저 신뢰 중단
8개 키 가운데 6개는 웹사이트용 TLS 인증서 발급에 쓰이는 중간 CA의 키입니다. 연구자는 10월 17일 Apple, Google, Microsoft, Mozilla와 eMudhra에 문제를 신고했습니다. CA 개인 키는 큰 난수여야 하지만, 발견된 값 8개는 모두 256보다 작아 거의 즉시 알아낼 수 있었습니다. Reddit 댓글에는 키 값이 4, 56, 66, 115, 155, 156, 230, 237이었다는 주장이 나왔습니다.
Chrome은 해당 키에 연결된 루트 인증서 emSign ECC Root CA - G3의 신뢰를 10월 27일 태평양 시간 오전부터 중단할 예정입니다. Mozilla는 10월 20일 Firefox에서 같은 루트 인증서를 신뢰하지 않기로 했습니다. 브라우저가 루트 인증서를 제거하면 그 아래에서 발급한 정상 인증서도 신뢰 체인에서 제외됩니다. Google은 해당 루트에 연결된 웹사이트 운영자에게 Chrome Root Store에 포함된 다른 PKI 계층의 TLS 인증서를 즉시 발급받아 설치하라고 안내했습니다.
Chrome이 공개 인증서 투명성(Certificate Transparency, CT) 로그를 집계한 결과 10월 21일 기준 해당 루트에 연결된 미만료 인증서는 약 30,800개였습니다. 그중 99.9%는 고등교육기관을 위한 인증 서비스 InCommon을 거쳐 발급됐습니다. Internet2가 운영하는 InCommon은 올해 4월부터 7월 사이 서비스를 eMudhra의 CertiNext 플랫폼으로 옮겼습니다. Google은 Chrome 차단 전에 문제의 중간 CA로 발급된 웹사이트 인증서가 CT 로그에 나타나지 않았으므로, CT 로그를 요구하는 Chrome 등 소프트웨어에서 악용된 인증서는 없었다고 밝혔습니다. eMudhra도 해당 키로 웹사이트나 사용자에게 인증서를 발급하지 않았으며 시스템 침해도 없었다고 말했습니다.
고객의 인증서 이전
eMudhra는 이전 대상 인증서가 약 3만 개이며 약 97%가 서버에서 인증서를 자동 요청하고 갱신하는 ACME 프로토콜로 발급됐다고 추산했습니다. 그러나 일반 ACME 클라이언트는 갱신 시점이 오기 전 인증서를 자동 교체하지 않습니다. ACME Renewal Information(ARI)을 지원하거나 운영자가 수동으로 개입해야 합니다. ECC 계층에서 RSA 계층으로 옮길 때는 클라이언트 설정을 바꿔야 할 수도 있습니다.
Cornell은 영향을 받는 사용자에게 ECC 대신 RSA 인증서를 요청하라고 안내했습니다. Cornell 자체적으로 영향을 받는 인증서가 300개 이상이며, RSA 인증서는 영향을 받지 않은 eMudhra 루트에 연결된다는 설명입니다. University of Michigan은 InCommon의 RSA 인증서는 현재 영향을 받지 않지만 해당 루트도 신뢰를 잃을 가능성이 있다고 밝혔습니다. 대학의 당장 대안은 Let's Encrypt입니다.
eMudhra는 ECC 루트와 별도인 G1 RSA 루트 인증서는 전환이 끝날 때까지 고객을 계속 지원한다고 밝혔습니다. Mozilla는 emSign Root CA - G1에 대한 신뢰를 당장은 유지하기로 했지만 Chrome은 eMudhra의 나머지 CA 인증서를 계속 신뢰할지 검토하고 있습니다. eMudhra는 미국 고객에게 독립적으로 운영되는 다른 공개 신뢰 CA 계층의 새 인증서를 발급하고 있다고 설명했습니다. 회사는 철수 전까지 G1 계층에서 신규 인증서를 계속 발급할지 밝히지 않았습니다. 폐기 확인과 상태 조회 서비스는 발급한 모든 SSL/TLS 인증서가 만료되거나 교체될 때까지 유지할 계획입니다. 디지털 서명 인증서, eSign, InCommon이 사용하는 CertiNext 사업은 계속합니다.
G1 계층과 과거 폐기 목록 문제
연구자는 Mozilla의 공개 버그 보고서에서 eMudhra가 10월 14일 게시한 emSign Root TLS CA - G1의 인증서 폐기 목록(CRL) 서명이 해당 CA의 키로 검증되지 않는다고 지적했습니다. CRL은 CA가 폐기한 인증서 목록입니다. 같은 보고서의 다른 참여자는 목록이 eMudhra의 OCSP 인증서 키로 서명된 것으로 보이며, 이는 또 다른 약한 키보다 잘못된 서명 키를 사용한 사례로 보인다고 설명했습니다. OCSP 인증서는 인증서 폐기 여부에 대한 응답을 서명합니다.
Chrome은 10월 21일 공개 보고서에서 어떤 키가 목록에 서명했는지, eMudhra가 해당 CA나 루트에 둘 이상의 키 쌍을 보유하는지 물었습니다. 고객이 G1과 다른 CA 중 어디로 옮기는지, 10월 27일 예정된 신뢰 제거 전에 이전이 언제 완료되는지도 질의했습니다. eMudhra는 10월 20일 G1이 유일한 대안이라고 했고, 다음 날에는 미국 고객에게 다른 공개 신뢰 계층의 인증서를 발급한다고 밝혔습니다.
2025년에도 eMudhra는 이번에 문제가 된 중간 CA 6개의 잘못된 CRL을 게시했습니다. 당시 사고 보고서는 각 중간 CA의 올바른 개인 키로 CRL을 다시 생성해 문제를 해결했다고 설명했습니다. 하지만 eMudhra는 10월 19일 Mozilla에 처음에는 사용하려던 키로 목록에 서명했고, 서명이 유효하지 않자 이번 달 발견된 약한 키로 다시 서명했다고 알렸습니다. Chrome은 2025년 사고 보고서에서 CA마다 키 쌍이 두 개였다는 사실을 공개하지 않은 점을 들어 투명성과 사고 대응에 우려를 표했습니다. 목요일 13시 31분 UTC 기준 eMudhra는 Chrome의 공개 질문에 답하지 않았으며, 버그 보고서에 남긴 마지막 공개 댓글은 10월 20일자였습니다.
Reddit 반응
- @pfiflichopf — 회사는 자신들이 얼마나 큰 악몽을 만들었는지 깨닫지 못하는 것 같습니다.
- @frankster — TLS가 세계에 중요한 정도에 비해 감시가 과도하다는 말은 맞지 않습니다. 다만 회사 수익 대부분이 전자서명, IAM, 디지털 신원에서 나오고 인증서 수익은 적다는 뜻으로 보입니다. 밀려나기 전에 먼저 사업을 접는 상황일 수도 있고, 해고당하면서 사직한다고 말할 기회를 얻은 것일 수도 있습니다.
- @dcheesi — 이런 일이 있었는데도 그들의 '보안' 제품을 믿을 수 있겠습니까?
- @I_AM_GODDAMN_BATMAN — 하루 동안 여러 서비스를 교체하고 업데이트하고 배포해야 했습니다. 그래도 CircleCI 사고보다는 나았습니다.
- @kernpanic — '추측 가능하다'고 했는데 키 하나는 4였습니다.
- @Afillatedcarbon — 개인 키 값은 4, 56, 66, 115, 155, 156, 230, 237이었습니다. 이 시점에 사업에서 철수해 다행입니다.
- @diabolic_recursion — 256비트 수를 뽑으려다 실수로 255 이하의 난수를 고른 것일 가능성이 있습니다. 심각한 실수지만 완전히 터무니없는 상황은 아닙니다.
- @diesal3 — 소셜 미디어가 있었든 없었든 이들은 차단됐을 겁니다. 공개 키 암호화의 기본을 높은 권한을 가진 CA가 실패했으니 다른 CA와 브라우저 개발자, 고객은 즉시 떠날 수밖에 없습니다.
- @granadesnhorseshoes — 공개 웹의 상용 X.509 PKI는 암호 기술 자체가 아니라 나머지 체계가 문제라고 오래전부터 생각했습니다. 루트 CA를 누가 검증했는지 불분명하고, 최종 사용자는 eMudhra를 신뢰하기로 선택한 적도 없는 경우가 많습니다. 브라우저의 자물쇠 표시는 거짓말입니다.
- @tvtb — 웹에서 인증서 고정 기능은 아직 쓰이나요? HPKP는 사라졌습니다.
- @cult_of_me — PKI는 실수였습니다. 다른 무언가가 필요합니다.
원문: The Hacker News / 번역·요약: Trawling