키는 4였다: 소프트웨어가 신뢰할 웹사이트는 누가 정하는가

이 글은 자동 번역되었습니다. 원문은 영어로 제공됩니다.

최종 업데이트: 2026년 10월 25일 · 읽는 시간 20분

여기 문제가 생겼다

2026년 10월 17일 토요일 UTC 18시 5분, Chrome Root Program에 한 보안 연구자의 제보가 들어왔다. 공개적으로는 웨인이라는 이름으로만 알려진 인물이다. 그는 인도 벵갈루루에 본사를 둔 상장사 eMudhra가 운영하는 인증기관(CA) 여덟 곳의 개인 키를 갖고 있다고 주장했다. 이를 증명하려고 그는 여덟 개의 키로 각각 똑같은 짧은 메시지에 서명해 보였다. “여기 문제가 생겼다 – 웨인.”

그는 어디에도 침입할 필요가 없었다. 소식이 알려진 뒤 보안 연구자 스콧 헬름이 키가 어떤 모습이었는지 설명했다. 그중 하나는 그냥 숫자 4였다. 다른 두 개는 56과 115였다. 헬름은 자신의 노트북에서 공개된 인증서만으로 키를 전부 복구했고, 1초도 걸리지 않았다고 말했다. 기자들이 독자적으로 확인한 결과에서도 eMudhra의 “EM OV TLS CA – G3C” 뒤에 있던 개인 키는 4였다.

여덟 곳은 중간 인증기관이었다. 인증서 회사에서 다른 이들의 자격 증명에 서명하는 실무 계층이다. 그중 여섯 곳은 웹사이트용 인증서를 발급할 권한이 있었고, 이 여섯 곳은 크롬, Mozilla, 마이크로소프트, 애플의 루트 프로그램이 신뢰하고 있었다. 나머지 두 곳은 코드 서명용, 곧 소프트웨어 제작사가 자사 프로그램에 서명할 때 쓰는 인증서를 위한 것이었고, 마이크로소프트가 신뢰했다. 이들의 키는 잘못 생성되었기 때문에, 어디를 봐야 할지 아는 사람이라면 누구나 원래 공개되도록 설계된 인증서 자체에서 키를 계산해 낼 수 있었다. 2025년 4월 인증서가 만들어진 순간부터 그랬다.

UTC 19시 45분, 제보가 들어온 지 1시간 40분 만에 크롬은 제보 내용을 확인하고 사용자들에게 차단 조치를 내려보냈다. 누구도 업데이트를 설치하거나 브라우저를 다시 시작할 필요가 없었다.

속도가 중요했던 것은 그런 키로 할 수 있는 일 때문이다. 웹사이트용 키 여섯 개 가운데 하나라도 손에 넣고 누군가의 연결을 가로챌 수 있는 사람이라면, 진짜 사이트가 어느 인증서 회사를 쓰든 상관없이 은행이든 이메일 서비스든 어떤 사이트의 위조 인증서라도 내밀 수 있었고, eMudhra의 체인을 신뢰하는 소프트웨어는 그 인증서를 받아들였을 것이다. 이를 가로막는 주요 방어 장치는 두 가지였다. 일부 소프트웨어는 반드시 요구하지만 상당수는 요구하지 않는 Certificate Transparency라는 공개 기록 체계, 그리고 각 소프트웨어가 제때 받은 차단 조치다.

위조 인증서가 통했을지는 평소에는 보이지 않는 결정들에 달려 있었다. 누가 웹사이트를 보증하는가, 그 보증인을 믿어야 한다고 누가 정하는가, 그리고 보증인이 망가진 것으로 드러났을 때 그 믿음을 얼마나 빨리 거둬들일 수 있는가.

인증서가 보증하는 것

웹사이트 인증서는 은행의 웹 주소 같은 이름을 공개 키와 묶어 주는, 서명된 작은 문서다. 공개 키는 개인 키와 쌍을 이룬다. 개인 키는 비밀로 간직되며 디지털 서명을 만들고, 공개 키는 그 서명이 짝인 개인 키에서 나왔는지 누구나 확인할 수 있게 해 준다. 브라우저가 사이트에 접속하면, 사이트는 인증서에 담긴 공개 키와 짝을 이루는 개인 키를 갖고 있음을 증명한다. 인증서 자체는 이 공개 키가 이 이름의 것이라고 말하고, 인증기관, 곧 CA가 그 진술에 서명함으로써 이를 보증한다.

웹사이트 인증서에 서명하기 전에 CA는 신청자가 해당 도메인을 통제하는지 확인해야 한다. 승인된 방법 하나는 신청자에게 무작위 값을 준 다음, 인터넷의 공개 주소록인 그 도메인의 DNS 레코드에서 그 값을 찾는 것이다. 도메인을 통제하는 사람만이 그곳에 값을 넣을 수 있다. CA는 또 소유 증명이라는 기술적 검사로 신청자가 인증받으려는 개인 키를 실제로 갖고 있는지 확인할 수도 있다. 다만 기반이 되는 표준은 신청자의 말을 그대로 믿는 것도 허용한다.

세상의 모든 CA를 브라우저가 직접 점검할 수는 없으므로, 신뢰는 사슬을 따라 위임된다. 맨 위에는 루트 인증서가 있고, 이 인증서들은 운영체제나 브라우저 안에 함께 실려 오는 루트 스토어라는 목록에 담겨 있다. 루트는 중간 인증기관에 권한을 주고, 중간 인증기관은 웹사이트가 쓰는 인증서를 발급한다. 소프트웨어는 사이트의 인증서를 보면 사이트에서 중간 인증기관으로, 다시 루트로 서명을 거슬러 올라가고, 체인이 자신의 스토어에 있는 루트에서 끝나고, 모든 서명이 검증되고, 인증서가 유효기간 안에 있으면서 접속하려는 이름을 포함하고, 소프트웨어의 다른 규칙 어디에도 걸리지 않을 때에만 그 사이트를 받아들인다.

애플, 구글, 마이크로소프트, Mozilla 같은 운영체제·브라우저 개발사가 운영하는 루트 프로그램은 인증기관을 심사하고 어떤 루트를 스토어에 넣을지 결정한다. 중간 인증기관의 개인 키가 그토록 값진 이유가 여기에 있다. eMudhra의 중간 인증기관이 그랬듯 특정 이름으로 제한되어 있지 않다면, 중간 인증기관은 어떤 도메인의 인증서에도 서명할 수 있고, 그 인증서는 위로 신뢰받는 루트까지 검증된다. 루트 자체의 키는 따로 잠가 둘 수 있다. 일상적인 서명은 중간 인증기관의 키가 맡고, 그 키가 유출되면 루트의 보증도 함께 유출된다.

이 가운데 어느 것도 웹사이트가 정직한지는 알려 주지 않는다. 브라우저의 자물쇠 아이콘이 그런 뜻으로 널리 받아들여지는데도 그렇다. 2021년 구글이 이 문제를 연구했을 때 자물쇠의 의미를 제대로 이해한 참가자는 11%에 불과했고, 피싱 사이트도 거의 모두 HTTPS를 써서 똑같이 자물쇠를 띄웠다. 2023년 구글은 크롬에서 자물쇠를 다른 아이콘으로 바꾸겠다고 발표했다. 기본적인 인증서는 연결이 그 이름의 키를 가진 누군가에게 간다는 것만 말해 준다. 사이트 뒤에 있는 조직의 이름까지 밝히는 인증서도 있지만, 그 의도를 보증하는 인증서는 없다.

층이 하나 더 있다. 2013년 구글 엔지니어들이 제시한 Certificate Transparency는 인증서를 공개 로그에 올려, 각 CA가 무엇을 발급했는지 누구나 감사할 수 있게 한다. 설계자들은 결국에는 클라이언트가 로그에 기록되지 않은 인증서를 모두 거부하게 하려 했다. 그러면 CA가 발급했든 CA의 키를 훔친 도둑이 발급했든, 로그 밖에 둔 인증서는 거부된다. 크롬은 자사 루트 스토어에 기대는 모든 연결에 대해 기본적으로 이렇게 한다.

응답받지 못한 경고

CA 키를 만드는 규칙은 엄격하다. 루트와 일부 중간 인증기관 키에 대해, 브라우저 루트 프로그램과 CA가 함께 관리하는 업계 규정집인 Baseline Requirements는 CA가 문서로 정한 키 생성 스크립트를 따르고, 자격을 갖춘 감사인이 키 세리머니에 입회하거나 그 전 과정을 영상으로 기록하도록 정하고 있다. 모든 CA 키는 여러 사람이 함께 생성해야 하며, 그중 누구도 혼자서 키를 만들 수 있을 만큼의 지식을 모두 갖고 있어서는 안 된다.

2025년 4월 30일 eMudhra는 중간 인증기관 24개를 한꺼번에 만들었다. A, B, C로 이름 붙인 세 시리즈였고, 키 종류는 RSA와 P-384라는 타원곡선 방식 두 가지, 용도는 네 가지였다. 망가진 키 여덟 개는 B와 C 시리즈의 P-384 키 전부였다. 여덟 개 모두 256보다 작은 정수였다. 전부 풀어 쓰면 각각 0이 길게 늘어서다가 마지막 바이트에만 무언가가 들어 있는 모양이었다.

이 키를 추측할 수 있었던 이유

P-384 곡선의 개인 키는 그냥 숫자 하나다. 1과 어떤 고정된 상한 사이에서 무작위로 고른 수이며, 그 상한 자체가 384비트 길이다. 공개 키는 개인 키로부터 계산되는데, 이 계산은 앞으로 하기는 쉽지만 제대로 된 무작위 수라면 거꾸로 되돌리기는 가망이 없다. 공개 키는 인증서에 인쇄되어 있다. 숫자 4는 완벽하게 적법한 개인 키이면서, 누구라도 맨 먼저 시도해 볼 숫자 가운데 하나이기도 하다. Mozilla는 이렇게 작은 키는 거의 즉시 복구할 수 있다고 지적했다. 1, 2, 3, 그렇게 256까지 공개 키를 계산해 인증서에 있는 것과 하나씩 비교하면 된다. 둘이 일치하면 개인 키는 출발점이 된 바로 그 숫자다. 제대로 된 무작위 키에는 그런 짧은 후보 목록이 없다. 스콧 헬름의 말대로 그 범위에는 대략 10의 115제곱 가지 가능성이 있고, “그러니 그걸 뒤져 볼 사람은 앞으로도 영영 없을 것”이다. Mozilla의 데니스 잭슨은 이 작업을 로컬에서 돌아가는 AI 에이전트에게도 맡겨 보았다. 에이전트들은 간단한 프롬프트 하나로 첫 시도에 키를 복구했다.

키 세리머니에서 어떻게 그렇게 작은 숫자가 나왔을까? 10월 19일 게시된 eMudhra의 예비 설명은 그날 사용한 스크립트에 결함이 있었다는 것이다. eMudhra에 따르면 회사는 키 내보내기를 시험하려고 평소 절차를 일회성으로 바꾸는 것을 승인했는데, 코딩 오류 때문에 하드웨어가 정상적인 키 쌍 옆에 더 약한 두 번째 키 쌍을 만들었고, 이름표가 비슷해 보이는 탓에 약한 키가 실수로 인증서 요청에 쓰였다. 키는 CA 키를 생성하고 지키도록 고안된 변조 방지 장치, 곧 Utimaco가 만든 하드웨어 보안 모듈에서 생성됐다고 한다.

eMudhra는 이 설명을 예비적인 것이라고 부르며, 설명은 핵심 수수께끼를 풀지 못한 채 남겨 둔다. Mozilla의 공개 버그 리포트에 글을 단 한 사람은, 키가 정책을 어기고 보안 하드웨어 밖에서 만들어져 안으로 옮겨졌거나, 아니면 하드웨어가 어떤 식으로든 스스로 결함 있는 키를 만들도록 설정될 수 있었거나 둘 중 하나라고 지적했다. Mozilla의 공개 메일링 리스트에서 또 다른 참여자는, 하드웨어 안의 진짜 키를 가리키는 작은 파일을 소프트웨어가 키 자체로 착각했을 수 있다는 확인되지 않은 추정을 내놓았다. Mozilla는 훨씬 더 공을 들였지만 같은 묶음에서 나온 A 시리즈의 P-384 키는 복구하지 못했다. Mozilla는 10월 20일 24시간 기한을 붙여 eMudhra에 질문을 보냈고, 10월 23일까지 답을 받지 못했고, 약한 키가 어떻게 생겨났는지에 대한 설명도 나오지 않았다.

기록으로 확인되는 것은 문제가 1년도 더 전에 이미 모습을 드러냈다는 사실이다. 2025년 6월 한 공개 모니터링 서비스에서, eMudhra가 바로 이 중간 인증기관들에 대해 서명이 유효하지 않은 인증서 폐지 목록 여섯 개를 내놓고 있는 것이 드러났다. 인증서 폐지 목록(CRL)은 CA가 취소한 인증서를 담은 서명된 명부이며, 그 서명은 CA 인증서에 담긴 공개 키로 검증되어야 한다. 당시 eMudhra의 보고서에 따르면 또 다른 인증서 회사인 섹티고가 2025년 6월 3일 이메일로 처음 경고했지만, 그 메시지는 내부 필터에 격리되어 아무도 보지 못했다. 잘못된 목록은 6월 6일 교체됐다.

2026년 10월 eMudhra는 그때의 수정이 무엇이었는지 설명했다. 목록은 처음에 원래의, 제대로 무작위로 만든 키로 서명됐다. 그런데 인증서에는 약한 키의 공개 키 쪽이 들어 있었기 때문에 그 서명은 검증에 실패했고, 회사는 결함 있는 키로 목록에 다시 서명했다. 그러니까 2025년 6월 eMudhra는 자사 인증서가 자신들이 쓰고 있다고 생각한 키와 맞지 않는다는 증거를 쥐고 있었고, 그러고는 목록을 고쳤다.

Chrome Root Program은 eMudhra가 운영을 멈추고, 이 CA들에 왜 키 쌍이 두 개 존재하는지 조사하고, 인증서를 폐지하는 대신 왜 목록에 다시 서명하는 데 그쳤는지 물었다. eMudhra는 자사의 루트와 발급 CA가 2년 연속 독립 감사를 거쳤다고 말한다. 웨인의 제보 사흘 전인 2026년 10월 14일, eMudhra는 다른 루트인 emSign Root TLS CA – G1의 폐지 목록을 게시했는데, 이 목록의 서명 역시 검증되지 않았다.

두 가지 차단 스위치

크롬의 첫 대응이 빨랐던 것은 키를 겨냥했기 때문이다. 크롬은 CRLSet이라는 차단 목록을 운영하며, 구글은 이를 백그라운드에서 브라우저로 내려보낸다. UTC 19시 45분에 적용된 업데이트는 여섯 중간 인증기관의 공개 키 지문을 차단했다. 차단 대상을 키로 지정했기 때문에, 위조범이 나중에 만들지도 모를 인증서까지 포함해 그 키를 쓰는 모든 인증서가 차단 범위에 들어갔다. Mozilla는 자체 목록인 OneCRL로 파이어폭스에서 해당 인증서를 차단했고, UTC 22시 59분에 작업을 마쳤다. OneCRL은 사용자가 파이어폭스를 업데이트하거나 다시 시작하지 않아도 작동한다.

백그라운드로 내려보내는 목록은 그것을 받는 소프트웨어만 보호한다. 10월 20일 Mozilla는 설정 탓에 차단 목록이 도착하지 못한 사용자를 위해 파이어폭스 업데이트를 내놓았고, 이어서 차단 목록을 적용하지 않던 일부 안드로이드용 파이어폭스 프로필을 위한 수정도 내놓았다. 구글은 10월 19일 월요일 UTC 22시 무렵부터 구글 플레이 서비스를 통해 안드로이드 기기에 같은 효과의 차단 조치를 보내기 시작했고, 이튿날 대부분의 기기가 이를 받았다고 밝혔다. 마이크로소프트와 애플도 며칠 안에 뒤따랐다. 다만 애플이 조치한 정확한 날짜는 공개된 설명마다 엇갈린다.

인증기관들도 움직였다. eMudhra는 10월 18일 UTC 9시 38분까지 인증서 여덟 개를 모두 폐지 처리했고, 사유는 CA 키 손상으로 기재했다. 중간 인증기관에 교차 서명을 해 주었던 섹티고는 10월 19일 교차 인증서 폐지를 마쳤다. 크롬은 또 Certificate Transparency 로그가 침해된 CA로 이어지는 인증서를 모두 거부하도록 조치했다. 이로써 위조 인증서는 CT를 검사하는 소프트웨어가 요구하는 로그 기록을 더는 얻을 수 없게 됐다.

더 무거운 수단은 중간 인증기관에 권한을 준 루트를 제거하는 것이다. 10월 20일 Mozilla는 그때쯤 여러 사람이 독자적으로 키를 복구했다는 점을 들어, 망가진 중간 인증기관 위에 있는 eMudhra의 루트 emSign ECC Root CA – G3를 루트 스토어에서 긴급 제거하기로 결정했다. 파이어폭스에는 이 조치가 필요 없었다. 파이어폭스는 이미 OneCRL이 막고 있었다. 이 조치는 OneCRL 없이 Mozilla의 루트 목록이나 그로부터 파생된 목록을 쓰는 다른 모든 이를 위한 것이었다. Mozilla는 이 변경으로 일부 서버가 새 인증서 체인으로 옮겨 가기 전까지 그 사용자들에게는 접속할 수 없게 될 것이라고 경고했다.

크롬도 같은 루트를 자사 스토어에서 제거했다. 구글은 이 변경이 태평양 시간 기준 2026년 10월 27일 화요일 오전에 Chrome Root Store에 기대는 모든 기기에 적용되고, 테스트 버전인 카나리와 베타에는 그보다 먼저 적용될 것으로 예상했다. 구글은 그 결과 이 루트로 이어지는 일부 정상 인증서가 크롬에서 작동을 멈출 것이라고 분명히 밝혔다.

두 스위치는 무엇을 잡아내고 누구에게 피해를 주는지가 다르다. 루트를 제거하면 정직한 웹사이트의 경로까지 포함해 그 루트를 지나는 경로가 모두 끊기지만, 다른 루트를 지나는 경로는 놓친다. 그리고 eMudhra의 중간 인증기관에는 다른 경로가 하나 더 있었다. 섹티고가 이들에 교차 인증을 해 주면서, 같은 키를 코모도 이름으로 발급된 AAA Certificate Services라는 루트에 연결해 두었던 것이다. 크롬은 2025년 4월 이 루트를 이미 제외했지만, 일부 시스템은 여전히 이를 신뢰했다. 우분투는 지원 중인 모든 릴리스에서 emSign ECC Root CA – G3를 제거했고, 코모도 루트를 아직 싣고 있던 구버전 릴리스에서는 그 루트까지 제거했다. 중간 인증기관 자체를 기준으로 하는 차단은 모든 경로를 한 번에 잡아낸다. Go 프로그래밍 언어가 이 방식을 택했다. 10월 19일 출시된 버전부터 Go의 인증서 검사기는 침해된 중간 인증기관이 하나라도 포함된 체인을, 어느 루트에서 끝나든 걸러 낸다.

나머지 모두가 해야 할 업데이트

10월 18일 Mozilla는 공개 버그 리포트에, 많은 엔드포인트가 폐지 정보를 받을 실질적인 방법이 없기 때문에 더 넓은 생태계가 걱정된다고 썼다. 브라우저에는 백그라운드 목록이 있었다. 보안 연결을 맺는 다른 소프트웨어 상당수에는 그런 것이 전혀 없다.

Mozilla의 데니스 잭슨이 만든 공개 페이지인 사고 추적 사이트는 누가 노출되어 있는지 조목조목 짚었다. 신뢰하는 루트 묶음을 자체적으로 싣고 배포하는 애플리케이션과 라이브러리는 소프트웨어 업데이트가 필요했다. 슬랙과 디스코드 같은 데스크톱 프로그램의 기반 프레임워크인 일렉트론으로 만든 앱도 마찬가지였다. 이런 앱은 패치된 릴리스로 다시 빌드되어야만 일렉트론의 수정 사항을 반영한다.

운영체제 자체의 신뢰 파일에 난 구멍도 있었다. 10월 22일 현재 사고 추적 사이트에 따르면 macOS는 침해된 중간 인증기관을 차단했지만, curl, git, python3를 비롯한 내장 명령줄 도구는 폐지 여부를 확인하지 않은 채 별도의 파일로 인증서를 검사했고, 그 파일은 업데이트되지 않은 상태였다. 우분투에서는 10월 22일까지 Canonical이 해결하지 못한 동기화 문제 때문에 시스템 업데이트 뒤에도 자바의 루트 스토어를 수동으로 손봐야 했고, 스냅 패키지로 설치한 브라우저는 시스템 스토어를 아예 쓰지 않았다.

자체 목록을 싣고 다니는 라이브러리에도 구멍이 있었다. Go는 CVE-2026-111943에 대한 보안 릴리스 1.27.3과 1.26.10으로 수정 사항을 내놓았다. 널리 쓰이는 파이썬의 certifi 번들은 10월 18일 emSign 루트 네 개를 모두 제거했다가, 2026.10.19 태그를 단 릴리스에서 영향받지 않은 세 개를 복원했다. 10월 23일의 자동 릴리스는 그 세 개 가운데 두 개를 다시 뺐다. 그리고 제조사만 고칠 수 있는 제품도 있었다. 시스코의 보안 조직 탈로스는 업데이트가 필요할 가능성이 큰 제품으로 가상 사설망을 특히 지목했다.

이 모든 것의 밑바탕에는 Certificate Transparency가 있었다. 대부분의 브라우저는 이를 강제하지만, curl을 비롯한 브라우저 외 클라이언트 상당수는 그렇지 않다. eMudhra 키로 만들어 로그에 한 번도 기록하지 않은 위조 인증서는 크롬에서는 거부되겠지만, 그런 클라이언트가 여전히 eMudhra의 체인을 신뢰하고, 이를테면 자사 서버의 알려진 인증서만 받아들이는 앱처럼 다른 무언가가 막아서지 않는 한 받아들여질 수 있었다.

시스템이 제대로 작동했다는 주장에는 강력한 근거가 있다. 10월 17일 크롬의 차단 이전에 여섯 중간 인증기관으로 이어지는 웹사이트 인증서가 Certificate Transparency에 기록된 적은 없었으므로, 2025년 4월 키가 만들어진 때부터 그 차단까지 이 키로 만든 위조 인증서가 CT를 강제하는 클라이언트를 상대로 쓰였을 수는 없다. 탈로스는 10월 21일 UTC 14시 현재 실제 환경에서 악의적으로 쓰인 사례를 보지 못했다고 밝혔다. eMudhra는 영향받은 중간 인증기관 가운데 실제 운영에 투입된 것은 하나뿐이었고, 그 어느 것도 웹사이트나 소프트웨어 제작사에 인증서를 발급한 적이 없다고 말한다.

CT를 내내 강제해 온 소프트웨어라면 그 주장은 옳고, 보호는 주말의 긴급 조치가 아니라 상시 규칙에서 나왔다. 다만 그 범위는 “시스템은 제대로 작동했다”는 말이 풍기는 것보다 좁다. 안드로이드용 파이어폭스는 2025년 11월 11일 사용자에게 처음 배포된 145 버전에 와서야 Certificate Transparency를 강제하기 시작했다. 안드로이드 앱은 안드로이드 16부터에야 내장 CT 검사를 쓸 수 있고, 안드로이드 17용으로 빌드되어야만 기본으로 적용받는다.

긴급 조치는 그 뒤에 벌어진 일에서도 중요했다. Mozilla가 루트 스토어를 받아 쓰는 하위 관리자들에게 처음 보낸 공지는 키를 누구나 복구할 수 있다는 사실을 일부러 밝히지 않았다. 10월 20일이 되자 그것은 거의 의미가 없어졌다. 여러 사람이 독자적으로 키를 복구했고, 헬름은 그 값 여덟 개를 모두 공개했다. 키가 사실상 공개된 뒤로, 키와 새로운 위조 사이를 가로막은 것은 차단 조치와 CT 로그의 거부였다. 10월 24일까지 공개된 어떤 자료도 2025년 4월부터 2026년 10월 사이 공격자들이 결함 있는 키를 CT를 강제하지 않는 클라이언트에 사용했는지 보여 주지 않았다.

스위치는 누가 쥐고 있나

브라우저와 운영체제가 어떤 루트를 신뢰할지는 루트 프로그램이 결정하며, 프로그램의 규칙은 그 주인에게 폭넓은 재량을 준다. 크롬의 정책은 구글이 “단독 재량으로” 인증서를 포함하거나 제거하며, 포함된 인증서는 저마다 그것을 유지하는 위험보다 큰 가치를 사용자에게 제공해야 한다고 규정한다. Mozilla의 정책은 언제든, 어떤 이유로든 단독 재량으로 인증서를 비활성화하거나 제거할 수 있다고 말한다. Mozilla는 또 포함에 대해 어떤 수수료도 받지 않는다고 밝힌다.

그 재량은 여러 방식으로 행사되어 왔다. 2014년 인도 국립정보센터가 여러 구글 도메인에 대해 무단으로 인증서를 발급한 뒤, 크롬은 그 위에 있던 India CCA 루트를 내치지 않았다. 그 루트를 인도 도메인 목록으로 제한했다. 그보다 3년 전 네덜란드의 한 인증기관에 대한 대응은 전면적이었다. 2011년 9월 3일 구글은 DigiNotar가 운영하는 모든 인증기관을 거부하기로 결정했고, 17일 뒤 네덜란드 법원은 이 회사에 파산을 선고했다.

DigiNotar, 2011년

DigiNotar의 침해 사실은 평범한 사용자를 통해 세상에 알려졌다. 2011년 8월 28일 이란 인터넷 서비스 업체 ParsOnline의 한 고객이 구글 지원 포럼에 크롬이 띄운 인증서 경고에 관한 글을 올렸다. 그 인증서는 구글의 것이라고 주장했고, 시스템을 침입당한 DigiNotar에서 나온 것이었다. 네덜란드 정부의 의뢰로 조사에 나선 보안 업체 Fox-IT의 조사관들은 나중에, google.com 주소를 포괄하는 부정 인증서가 약 30만 명의 사용자를 노린 대규모 공격에 쓰였다는 사실을 밝혀냈다. 피해자는 거의 모두 이란에 있었고, 이들의 구글 트래픽은 가로채이거나 다른 곳으로 돌려졌을 가능성이 크다. 조사관들은 위조 인증서의 상태를 확인한 서로 다른 인터넷 주소 29만 8,140개에서 이 추정치를 끌어냈으며, 이를 매우 거친 근사치라고 불렀다. 9월 3일 네덜란드 정부는 DigiNotar에 대한 신뢰를 공개적으로 철회했다. 2026년 10월 말까지 eMudhra 키를 이용한 공격은 보고되지 않았다. DigiNotar는 CA의 서명 권한이 그것을 쓸 의지가 있는 사람의 손에 들어가면 무슨 일이 벌어지는지 보여 주었다.

구글은 크롬 루트 스토어에 포함되려면 CA 소유자가 크롬 사용자를 보호하는 데 필요한 기술적 역량과 운영상의 엄격함을 지속적으로 입증해야 한다고 썼고, eMudhra의 나머지 CA 인증서를 유지해야 할지 “면밀히 조사하고 있다”고 밝혔다. 10월 23일 eMudhra는 공개 버그 리포트에, 소셜미디어의 집중적인 감시와 투자자·고객의 분석 때문에 이번 사건을 의미 있게 분석하는 것이 “사실상 불가능”해졌다고 썼다. 크롬은 같은 날, 그것은 변명이 될 수 없으며 eMudhra는 이 시스템에 기대고 있다가 자사의 실수로 위험에 노출된 “수십억” 명의 사람들에게 여전히 의무를 지고 있다고 답했다.

eMudhra 이사회는 이미 10월 22일 글로벌 SSL/TLS 인증서 사업에서 철수하기로 결정한 상태였다. 회사는 이 사업이 자사 사업에서 아주 작은 부분을 차지할 뿐이라고 말한다.

같은 회사들은 CA/Browser Forum이라는 기구에서 CA와 함께 공동 규칙도 만든다. eMudhra가 결함 있는 키를 생성하기 19일 전인 2025년 4월 11일 마감된 투표에서 애플, 구글, 마이크로소프트, Mozilla는 모두 웹사이트 인증서의 수명을 줄이는 데 찬성했고, eMudhra를 포함한 인증서 발급기관 25곳도 찬성표를 던졌다. 이 안건의 논리는 인터넷 규모에서 폐지는 사람들을 충분히 보호하지 못하지만 만료는 보호한다는 것이었다. 안건은 “인증서 유효기간, 그리고 신뢰 당사자가 이를 강제하는 일은 놀라울 만큼 믿을 만하다”고 했다. 2026년 10월 시행 중인 규칙에 따르면 2026년 3월 15일부터 발급되는 웹사이트 인증서의 유효기간은 최대 200일이고, 2027년 3월 15일부터는 100일, 2029년 3월 15일부터는 47일이다.

이 상한은 웹사이트가 쓰는 인증서에, 발급 날짜를 기준으로 적용된다. 규칙의 조문은 이번 사건의 중심에 있는 CA 인증서에는 상한을 두지 않으므로, 수명이 짧아졌더라도 eMudhra의 중간 인증기관이 만료되지는 않았을 것이다. 폐지가 사라진 것도 아니다. 무료 인증기관 Let’s Encrypt는 브라우저가 인증서를 하나씩 조회할 수 있게 해 주던 OCSP 서비스를 2025년 8월 종료했다. 조회할 때마다 어느 인터넷 주소에서 어느 사이트를 방문하는지가 CA에 알려졌기 때문이다. 10월 17일의 긴급 차단은 사실상 브라우저 제조사가 직접 관리하고 내려보낸 폐지 목록이었다.

이런 구조는 막대한 권력을 소수의 민간, 그것도 대부분 미국 기업의 손에 쥐여 준다. eMudhra 사례가 보여 주는 것은 그 권력이 어떻게 행사되는가다. 누구나 질문과 기한과 답변을 읽을 수 있는 공개 버그 리포트에서, 제거하는 쪽의 회사들이 직접 그 이유를 공개하면서 행사된다.

옮겨 가야 하는 인증서들

루트 제거는 발표하기는 빠르지만 그 충격을 소화하기는 더디다. 10월 21일 현재 크롬은 emSign ECC Root CA – G3로 이어지는 만료되지 않은 사전 인증서를 약 3만 800건으로 집계했다. 사전 인증서란 발급 전에 투명성 로그에 제출되는 인증서 사본이다. 따라서 이 수치는 로그에 기록된 인증서의 수이지, 그 인증서를 아직 쓰고 있는 웹사이트의 수가 아니다. 이 가운데 3만 791건, 즉 99.9%는 미국 네트워크 기관 Internet2가 운영하는 인증서 서비스 InCommon 소속 중간 인증기관 두 곳에서 나왔다. 이 두 곳은 망가진 중간 인증기관 여덟 곳에 들지 않았다. 그저 제거되는 루트에 매달려 있었을 뿐이다. eMudhra는 약 3만 건의 인증서가 옮겨 가야 하며, 거의 모두 서버가 인증서를 자동으로 요청하고 갱신하게 해 주는 프로토콜인 ACME로 발급됐다고 추정했다. eMudhra는 10월 20일 G3 루트 아래에서의 발급을 중단했다.

자동화만으로 이 문제가 풀리지는 않는다. 표준 ACME 클라이언트는 CA가 조기 갱신을 요청할 수 있게 하는 더 새로운 확장 기능을 지원하거나 누군가 직접 개입하지 않는 한, 갱신 날짜가 돌아와야만 인증서를 교체한다. 크롬은 10월 21일, eMudhra의 타원곡선 계층에서 RSA 계층으로 옮겨 가려면 클라이언트 설정도 바꿔야 할 수 있다고 지적했다.

InCommon의 인증서는 eMudhra를 모회사로 둔 공급업체 CertiNext를 통해 나온다. 10월 22일 InCommon은 가입자들에게, 봄과 여름에 걸친 성공적이지만 고된 이전 작업을 마친 뒤 이번 주에는 많은 가입자가 인증서 오류에 대응하고 자신들이 통제할 수 없는 변화에 맞춰 계획을 세우느라 시간을 보냈다고 전했다. 그날 아침 InCommon의 권고는 타원곡선 인증서 발급이 재개될 때까지 영향받은 인증서를 RSA로 재발급하라는 것이었다.

eMudhra는 10월 20일, G3 고객에게 남은 유일한 대안은 자사의 RSA 루트인 emSign Root CA – G1으로 이어지는 중간 인증기관이라고 밝혔다. Mozilla는 같은 날, 현 시점에서는 G1에 대한 신뢰를 철회하지 않는다고 말했다. G1은 크롬이 10월 20일 면밀히 조사하고 있다고 밝힌 eMudhra의 나머지 인증서에 포함돼 있었고, 10월 24일까지 크롬은 아무 결정도 발표하지 않았다. 10월 21일 크롬은 eMudhra에 고객을 G1으로 옮기는지, 다른 회사의 계층으로 옮기는지, 아니면 둘 다인지 확인해 달라고 요청했다.

10월 22일 저녁 나온 InCommon의 공지는 당장의 문제를 해결했다. 타원곡선 인증서가 이제 G1 루트로 이어진 채 다시 발급되기 시작했고, 기존 클라이언트는 설정을 바꾸지 않고도 갱신할 수 있었다. 같은 공지는 eMudhra가 30일 뒤, CertiNext가 확정할 날짜에 자사 공개 루트로 이어지는 모든 중간 인증기관에서 발급을 중단하며, InCommon이 대체 경로를 마련하고 있다고 전했다. 봄과 여름에 걸쳐 고된 이전 작업을 한 차례 마친 가입자들에게, 루트 하나의 제거는 또 한 번의 이전을 뜻했다.

관련 기사

• 미국의 제재 명단은 헤이그의 재판소에 어디까지 닿는가
• 비트코인, 다음은 무엇인가?
• AI는 실제로 어떻게 작동하는가: 헤드라인은 모르고 개발자는 아는 것

더 읽을거리

아마존 어소시에이트로서 Eikleaf는 적격 구매를 통해 수익을 얻습니다. 아래 도서 링크는 제휴 링크로, 이를 통해 구매하시면 추가 비용 없이 소정의 수수료를 받을 수 있습니다.

추천 영상

생성형 AI 고지

이 페이지의 일부 내용은 생성형 AI의 도움을 받아 생성 및/또는 편집되었습니다.

미디어

웹사이트 주소창의 HTTPS와 자물쇠 – Wikimedia Commons (사진: Santeri Viinamäki, CC BY-SA 4.0)

nCipher nShield F3 하드웨어 보안 모듈 – Wikimedia Commons (사진: Alexander Klink, CC BY 3.0)

구글플렉스 본사 – Wikimedia Commons (사진: Asoundd, CC BY-SA 4.0)

주요 출처 및 참고문헌

Mozilla Bugzilla. “Bug 2083449: eMudhra: Private key compromise of Intermediate Certificates.” Opened 18 October 2026, comments to 23 October 2026. https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

Chrome and Android Security Teams. “Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates.” Google, The Keyword, 20 October 2026. https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/

Mozilla dev-security-policy mailing list. “Compromised eMudhra Intermediate Certificates” thread, posts by Dennis Jackson (Mozilla) and the Chrome Root Program, 20 October 2026, and by Wayne and Corey Bonnell, 21 October 2026. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE

Jackson, Dennis. “eMudhra Intermediate CA Compromise.” Incident tracking site, 20 October 2026, updated 22 October 2026. https://emudhra.we-have-a-problem.com/

InCommon (Internet2). “Moving Forward Together: InCommon Certificate Service Update.” Updates of 22 October 2026. https://incommon.org/about/news/incommon-certificate-service-update

InCommon (Internet2). “InCommon Certificate Service FAQ.” Last updated 22 October 2026, 18:30 ET. https://incommon.org/certificates

Stanescu, Luci. “eMudhra CA compromise fixes available.” Ubuntu blog, Canonical, 20 October 2026, updated 22 October 2026. https://ubuntu.com/blog/emudhra-ca-compromise-fixes-available

Canonical. “USN-8944-1: ca-certificates update” and “USN-8944-2: ca-certificates update.” Ubuntu security notices, 20 October 2026. https://ubuntu.com/security/notices/USN-8944-1 and https://ubuntu.com/security/notices/USN-8944-2

Go team. “[security] Go 1.27.3 and Go 1.26.10 are released.” golang-announce, posted 20 October 2026 (releases dated 19 October 2026). https://groups.google.com/g/golang-announce/c/66pojueaQek

Go project. “Release History.” Accessed 24 October 2026. https://go.dev/doc/devel/release

certifi. “Remove emsign (#437),” “Restore unaffected emSign roots (#439) (#440)” and “2026.10.23 (#445).” python-certifi repository, 18, 20 and 23 October 2026. https://github.com/certifi/python-certifi/commit/5cb238caeeb6c30ec1a7309ad3e16a5aa7b10ce8 and https://github.com/certifi/python-certifi/commit/662df63d7906df66f1f07c0751a3dfe9da14d914 and https://github.com/certifi/python-certifi/commit/b60466c9f2882d9cf088943c650b0faac06c080c

Cisco Talos. “Compromised eMudhra intermediate certificates.” Talos Intelligence blog, 21 October 2026. https://blog.talosintelligence.com/compromised-intermediate-certificates/

eMudhra Limited. “eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA.” 21 October 2026. https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca

eMudhra Limited. “eMudhra to exit global SSL/TLS certificate business.” 22 October 2026. https://emudhra.com/en/press-release/emudhra-to-exit-global-ssl-tls-certificate-business

Abrams, Lawrence. “Mozilla, Google, Apple block compromised eMudhra CA certificates.” BleepingComputer, 20 October 2026. https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/

Helme, Scott. “Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds.” 20 October 2026. https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/

Sharwood, Simon. “Indian certification authority eMudhra’s private keys compromised – one of them was the number ‘4’.” The Register, 20 October 2026. https://www.theregister.com/a/5304312

Mozilla Bugzilla. “Bug 1970728: eMudhra: Invalid CRL signatures.” June 2025. https://bugzilla.mozilla.org/show_bug.cgi?id=1970728

Mozilla. “Firefox for Android 145.0 release notes.” 11 November 2025. https://www.firefox.com/en-US/firefox/android/145.0/releasenotes/

Cooper, D., et al. “RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.” IETF, May 2008. https://www.rfc-editor.org/rfc/rfc5280

Laurie, B., Langley, A., and Kasper, E. “RFC 6962: Certificate Transparency.” IETF, June 2013. https://www.rfc-editor.org/rfc/rfc6962

CA/Browser Forum. “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.3.1.” 4 October 2026, sections 3.2.2.4.7, 6.1.1.1 and 6.3.2. https://github.com/cabforum/servercert/blob/3574ae809e5f909b58ee4c26b7bac4a3b9e78421/docs/BR.md

CA/Browser Forum. “Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods.” 11 April 2025. https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

Google. “Chrome Root Program Policy, Version 1.8.” Last updated 5 February 2026. https://googlechrome.github.io/chromerootprogram/crp/policy/

Mozilla. “Mozilla Root Store Policy, Version 3.1.” Effective 1 July 2026. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Aas, Josh. “OCSP Service Has Reached End of Life.” Let’s Encrypt, 6 August 2025. https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life/

Adrian, David, Serena Chen, Joe DeBlasio, Emily Stark and Emanuel von Zezschwitz. “An update on the lock icon.” Chromium Blog, May 2023. https://blog.chromium.org/2023/05/an-update-on-lock-icon.html

von Zezschwitz, Emanuel, Emily Margarete Stark and Serena Chen. “‘It builds trust with the customers’ – Exploring User Perceptions of the Padlock Icon in Browser UI.” SecWeb 2022, IEEE. https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/

Android Developers. “Network security configuration: Certificate transparency.” Accessed 24 October 2026. https://developer.android.com/privacy-and-security/security-config

Langley, Adam. “Maintaining digital certificate security.” Google Online Security Blog, July 2014. https://security.googleblog.com/2014/07/maintaining-digital-certificate-security.html

Adkins, Heather. “An update on attempted man-in-the-middle attacks.” Google Online Security Blog, 29 August 2011, updated 3 September 2011. https://security.googleblog.com/2011/08/update-on-attempted-man-in-middle.html

Fox-IT. “Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach.” 13 August 2012. https://zoek.officielebekendmakingen.nl/blg-191225.pdf