eMudhra(이무드라), 글로벌 SSL/TLS 인증서 사업 철수 — 키 유출 닷새 만에 결정, 인증서 3만 장 교체 남았다 | 뉴스

인도 인증기관 이무드라(eMudhra)가 10월 22일(현지시간) 이사회 결정으로 글로벌 SSL/TLS 인증서 사업에서 자발적으로 철수한다고 발표했다.

중간 인증서(Intermediate CA) 8개의 개인키가 한 바이트짜리 숫자였다는 사실이 드러나 모질라·구글이 루트를 긴급 불신임한 지 이틀 만이다. 회사는 TLS가 매출의 약 1%에 불과하고 무료 인증서와의 경쟁으로 수익성도 떨어졌다고 설명했다. 기존 고객에게는 파트너를 통해 무료로 인증서를 바꿔 주겠다고 했지만, 그 파트너가 누구인지와 일정은 아직 밝히지 않았다.

3줄 요약

이무드라는 글로벌 SSL/TLS 사업을 접는다. 인도 전자서명(DSC)·eSign, CertiNext 같은 기업용 PKI 제품은 그대로 운영한다.
모질라와 크롬은 emSign ECC Root CA - G3를 긴급 제거했다. 이무드라는 이 루트 아래 인증서 약 3만 장을 RSA 루트(G1) 체인으로 옮기겠다고 했고, 그중 97%가 ACME로 발급된 것이라고 밝혔다.
emSign/eMudhra 인증서를 쓰는 사이트는 다른 CA로 갈아타는 편이 낫다. 서버 쪽에서는 CA 번들, certifi, pip 같은 클라이언트도 업데이트해야 한다.

이무드라가 밝힌 글로벌 TLS 사업의 매출 비중

약 3만 장

G3(ECC) 루트 아래에서 옮겨야 하는 인증서 추정치

97%

그중 ACME로 발급된 비율

8비트

유출된 중간 CA 개인키의 실제 크기(값 4~237)

무슨 일이이사회가 TLS 사업 철수를 결정했다

이무드라는 인도 벵갈루루에 본사를 둔 상장사(BSE 543533, NSE EMUDHRA)로, 해외에서는 emSign이라는 브랜드로 TLS 인증서를 팔아 왔다. 10월 22일 보도자료 제목은 짧았다. "eMudhra to Exit global SSL/TLS Certificate Business." 본문에 따르면 이사회는 글로벌 SSL/TLS 인증서 사업에서 자발적으로 물러나기로 결정했다.

V. 스리니바산(V. Srinivasan) 회장은 사고 대응이 성실했다고 주장했다. 문제의 CA를 발견 후 14시간 안에 폐기했고, 해당 CA에서 발급된 최종 사용자(end entity) 인증서는 없으며, 인프라 침해나 데이터 유출도 없었다는 것이다. 철수 이유로는 세 가지를 들었다. TLS가 전체 매출의 약 1%에 불과하다는 점, 데이터 주권·컴플라이언스 요구 때문에 비용과 복잡도가 해마다 늘었다는 점, 일부 대형 사업자가 인증서를 공짜로 발급하면서 투자 대비 수익이 크게 줄었다는 점이다.

눈에 띄는 대목도 있다. 보도자료는 이번 사고를 둘러싼 "소셜 미디어의 증폭"이 TLS가 회사에서 차지하는 비중에 걸맞지 않은 수준의 관심을 불러왔다고 적었다. "많은 인증기관에게 SSL/TLS는 사업의 전부지만, 이무드라에게는 훨씬 넓은 디지털 솔루션 포트폴리오의 일부"라는 문장도 들어 있다. 철수가 사고 책임을 지는 결정이라기보다 수익성 판단이라는 쪽에 무게를 둔 표현이다.

배경한 바이트짜리 개인키, 간단히 다시 보기

사고 자체는 지난주에 터졌다. 10월 17일(토) 20:06 UTC에 한 연구자가 애플·구글·마이크로소프트·모질라와 이무드라에 이무드라 중간 CA 8개의 개인키가 노출됐다고 알렸다. 이 키들은 P-384 타원곡선 키인데, 원래 384비트 무작위 수여야 할 개인키 d가 모두 256보다 작았다. 스콧 헬름(Scott Helme)이 공개 인증서에서 직접 복구한 값은 4, 56, 115, 155, 156, 230, 66, 237이었다. 1×G부터 255×G까지 계산해 보면 끝나는 수준이다.

8개 중 6개는 TLS 발급용(DV·OV·EV, 각각 G3B·G3C 두 세대), 2개는 코드 서명용이다. 모두 2025년 4월 30일 키 생성 의식에서 만들어졌고, 2025년 5월 섹티고(Sectigo)의 AAA Certificate Services 루트로 교차 서명까지 받았다. 이무드라는 10월 21일 성명에서 키 생성 과정의 wrap/unwrap 단계 결함으로 강한 키 옆에 약한 키 한 벌이 따로 만들어졌고, 그 약한 키가 루트 스토어에 올라갔다고 설명했다. 사고의 기술적 원리와 오라클 자바 경보(CVE-2026-91403) 대응은 앞서 정리한 기술노트: 오라클 자바 CVE-2026-91403과 이무드라 CA 키 유출에 자세히 적어 두었다. 이 기사는 그 뒤에 나온 소식만 다룬다.

모질라 보안 블로그, 모질라 버그 2083449, 스콧 헬름 분석, 이무드라 보도자료를 바탕으로 정리
날짜(UTC 기준)	누가	무엇을
10월 17일	연구자 → 루트 프로그램	중간 CA 8개 개인키 노출 보고. 크롬은 같은 날 저녁 CRLSet으로 차단, 모질라는 22:59 UTC까지 OneCRL 배포 완료
10월 19일	섹티고	AAA Certificate Services로 교차 서명한 해당 중간 CA 폐기 완료
10월 20일	모질라·크롬	모질라가 emSign ECC Root CA - G3 긴급 제거 결정(NSS 3.131.1, Firefox 158.0.1 등), 크롬도 같은 경로 결정. 이무드라는 G3 아래 발급 중단
10월 21~22일	이무드라·mitmproxy	이무드라 사고 성명(21일)과 TLS 사업 철수 발표(22일). mitmproxy는 --emudhra 커밋 후 12.3 공개

기존 고객은인증서는 어떻게 되나

보도자료의 "Seamless transition for customers" 항목에 나온 약속은 네 가지다. 첫째, G1 RSA 루트는 전환이 끝날 때까지 고객을 계속 지원한다. 둘째, 이무드라가 영향받는 고객에게 먼저 연락해 전환 기간 동안 파트너사 인증서로 무료 교체해 준다. 셋째, 발급된 모든 인증서가 만료되거나 교체될 때까지 폐기 목록(CRL)과 인증서 상태(OCSP) 서비스를 계속 돌린다. 넷째, 루트 프로그램에 대한 남은 의무, 특히 전체 근본 원인 보고서를 끝까지 제출한다.

숫자는 모질라 버그 트래커에서 나왔다. 모질라가 10월 20일 G3 루트 제거를 통보하자 이무드라 측은 "초기 추정으로 옮겨야 할 인증서가 약 30,000장이고 약 97%가 ACME로 들어왔다"며 "유일한 대안인 G1(RSA 루트) 체인의 중간 CA로 옮기겠다"고 답했다. 모질라는 이 시점에 emSign Root CA - G1의 신뢰는 제거하지 않는다고 밝혔다. 다만 철수 발표 이후에는 G1 체인으로 옮겨 봐야 결국 다시 한 번 옮겨야 한다. 그래서 "파트너"가 어디인지가 중요하다.

그 부분은 아직 비어 있다. 10월 22일 버그 트래커에는 이 보도자료를 인용하면서 파트너가 누구인지, 교체 인증서가 어느 루트 아래서 나오는지, 재발급 대상 수량과 교체 일정, 사용자를 제때 다른 루트로 옮길 방법을 묻는 댓글이 올라왔다. 계속 운영한다는 전자서명 사업이 CCADB에 등록된 emSign 코드 서명·S/MIME 루트와 관련 있는지도 물었다. 기사를 쓰는 시점까지 이무드라의 공식 답변은 확인하지 못했다.

크롬 루트 프로그램의 지적

구글 크롬 루트 프로그램은 10월 21일 버그에 질문 목록을 올리면서 이무드라 공지의 빈틈을 짚었다. 상태 페이지와 보도자료 어디에도 불신임된 루트(emSign ECC Root CA - G3)나 영향받는 중간 CA의 이름·일련번호·SHA-256 지문이 없고, 루트 스토어 제거 일정이나 버그 링크도 없으며, 가입자가 자기 인증서가 영향받는지 판단하는 방법도 설명하지 않는다는 것이다. 또 CA 이름에 쓰인 브랜드 emsign.com은 공지가 없는 제품 페이지로 리다이렉트된다고 했다. 고객 입장에서는 공지만 읽고 무엇을 해야 할지 알기 어렵다는 얘기다.

업계 반응mitmproxy의 --emudhra, 헬름의 "Eight Bits of Trust"

반응 중 가장 상징적인 건 mitmproxy였다. HTTPS 트래픽을 들여다보는 프록시 도구인데, 10월 21일 --emudhra 옵션을 커밋했고 22일 12.3 버전을 "eMudhra Edition"이라는 이름으로 내놨다. 보통 mitmproxy로 HTTPS를 가로채려면 대상 기기에 mitmproxy 자체 CA를 설치해야 한다. --emudhra를 켜면 유출된 키로 리프 인증서를 서명하기 때문에, 아직 트러스트 스토어를 업데이트하지 않은 클라이언트는 아무 설정 없이 그 인증서를 믿는다. 섹티고 교차 서명을 앞에 두는 --emudhra-old도 있다. 2021년 이전 트러스트 스토어처럼 AAA Certificate Services만 믿는 오래된 클라이언트를 시험하기 위한 옵션이다. 반대로 mitmproxy 자신은 certifi를 올려 해당 루트를 더 이상 믿지 않게 했다. 유출 키가 이제 누구나 쓰는 도구에 들어갔다는 뜻이다.

스콧 헬름의 글 "Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds"는 이 사건이 왜 "봉쇄할 수 없는" 사고인지를 설명했다. 키를 누가 훔친 게 아니라 인증서가 생긴 날부터 사실상 공개 상태였기 때문에, 2025년 4월부터 약 17개월 동안 누가 키를 복구했는지 알 방법이 없다는 것이다. 크롬은 인증서 투명성(CT)을 강제하고 이 CA 체인의 TLS 인증서가 CT에 한 번도 나타나지 않았으므로 기본 설정의 크롬에서 위조 인증서가 신뢰됐을 가능성은 없다고 했다. 헬름은 이 설명이 맞다고 보면서도, CT는 오발급을 탐지할 뿐 막지는 못하고 대부분의 비브라우저 소프트웨어는 CT를 검사하지 않는다고 지적했다.

그는 로컬 서버에 api.stripe.com용 위조 인증서를 올려 시험했다. 기본 설정에서 curl은 "SSL certificate verify ok"를 출력했고, 파이썬은 핸드셰이크를 마쳤고, Node는 authorized: true를 돌려줬다. 테스트한 모든 리눅스·macOS 기기에서 같은 결과가 나왔다. 윈도 CryptoAPI는 폐기 검사를 켜지 않으면 체인을 받아들였다. 헬름은 업데이트할 수 없는 공유기·카메라·임베디드 기기의 펌웨어가 이 인증서를 만료일인 2039년 7월까지 믿게 된다고 경고했다.

클라이언트별로 정리하면 이렇다. 최신 크롬·파이어폭스·사파리는 중간 CA를 직접 막고 CT를 강제하므로 업데이트만 확인하면 된다. 파이썬은 공식 공지가 certifi 2026.10.19, pip 26.2.2, uv 0.13.4 이상을 권고했는데, pip는 내장 certifi를 시스템 스토어와 함께 항상 읽기 때문에 OS 쪽만 고쳐서는 막을 수 없다. curl·Node·Go·자바처럼 디스크의 CA 번들을 쓰는 도구는 OS의 ca-certificates 패키지를 올리고 컨테이너 이미지를 캐시 없이 다시 빌드해야 한다.

왜 중요한가CA 하나가 사라지는 방식

대형 CA가 사고 끝에 신뢰를 잃는 일은 처음이 아니다. 그래도 이번처럼 사고 보고부터 사업 철수 발표까지 닷새밖에 걸리지 않은 경우는 드물다. 키 값이 4였다는 사실은 설명이 필요 없을 만큼 직관적이었고, 루트 프로그램도 망설일 이유가 없었다. 이무드라가 "소셜 미디어 증폭"을 탓했지만, 버그 트래커에는 키 문제와 별개로 10월 14일 G1 루트의 CRL 서명이 검증되지 않았다는 보고도 올라와 있다. 남은 G1 루트를 바라보는 시선도 곱지 않을 것이다.

사업 규모가 매출의 1%라는 말은 반대로 읽을 수도 있다. TLS가 핵심이 아닌 회사가 웹 PKI의 신뢰 앵커를 쥐고 있었다는 뜻이다. 루트 하나가 브라우저, 운영체제, 언어 런타임, 펌웨어에 동시에 들어가는 구조에서는 작은 사업부의 실수 하나가 수많은 비브라우저 클라이언트를 오랫동안 위험하게 만든다.

영삼

영삼의 한마디

솔직히 이무드라 인증서를 쓰는 국내 사이트는 많지 않을 것이다. 내가 더 신경 쓰이는 쪽은 클라이언트다. 내 서버의 크론 작업, 배포 스크립트, 오래된 도커 베이스 이미지에서 도는 curl과 pip는 브라우저처럼 똑똑하지 않다. 이번 주에 서버마다 ca-certificates를 올리고 pip 버전을 확인했는데, 한참 전에 만든 가상환경 하나에서 예전 pip가 그대로 돌고 있었다. 인증서를 발급받는 쪽보다 검증하는 쪽 숙제가 더 오래 남을 것 같다.

개발자가 할 일emSign 인증서를 쓰고 있다면

먼저 내 도메인이 이무드라 체인을 쓰는지 확인한다. 발급자(issuer)에 eMudhra나 emSign이 보이면 해당된다. 97%가 ACME로 발급됐다는 건 대부분 자동 갱신 환경이라는 뜻이니, 클라이언트의 ACME 디렉터리 주소만 다른 CA로 바꿔도 교체는 금방 끝난다. G1 체인으로 재발급받는 방법도 있지만, 회사가 사업을 접는다고 발표한 이상 두 번 이사하는 셈이다.

# 서버 인증서 체인의 발급자 확인
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | grep -E "s:|i:"

# 파이썬 환경 점검: certifi 2026.10.19, pip 26.2.2 이상인지
python -m pip --version
python -c "import certifi; print(certifi.__version__)"

# 데비안/우분투 서버 CA 번들 갱신
sudo apt update && sudo apt install --only-upgrade ca-certificates

점검 체크리스트

도메인별 인증서 발급자 확인. eMudhra/emSign이면 다른 CA로 재발급하고 이무드라의 교체 안내 메일을 기다리지 않는다
ACME 클라이언트(certbot, acme.sh 등) 설정에서 서버 주소를 바꾸고 갱신을 시험한다
서버·CI 러너·컨테이너의 ca-certificates, certifi, pip, uv, Node, 자바 런타임 업데이트. 도커는 캐시 없이 다시 빌드
이무드라 코드 서명 인증서로 서명된 바이너리를 배포하고 있다면 재서명 계획을 세운다
업데이트가 어려운 IoT 기기는 제조사 공지를 확인하고, 당장 어렵다면 외부 통신 구간을 좁힌다

이무드라가 약속한 근본 원인 보고서와 파트너·일정 공개가 다음 관전 포인트다. 크롬과 모질라가 남은 G1 루트를 어떻게 처리할지도 지켜봐야 한다. 버그 트래커에서 CRL 서명 문제처럼 추가로 지적된 사항에 대한 답변도 아직 나오지 않았다.

자주 묻는 질문

이무드라 SSL/TLS 사업 철수란?

이무드라는 10월 22일 이사회 결정으로 글로벌 SSL/TLS 인증서 사업에서 자발적으로 물러난다고 발표했다. 중간 CA 개인키 유출 사고 직후 나온 결정이며, 회사는 TLS 매출 비중이 약 1%에 불과하고 수익성이 떨어졌다는 점을 이유로 들었다. 인도 전자서명과 기업용 PKI 제품 사업은 계속한다.

emSign 인증서를 쓰는 사이트는 어떻게 해야 하나?

다른 CA로 인증서를 재발급받는 것이 가장 확실하다. 이무드라는 파트너사를 통해 무료로 교체해 주겠다고 했지만 파트너 이름과 일정은 아직 공개하지 않았다. ACME로 발급받았다면 ACME 서버 주소만 바꿔 갱신하면 된다.

emSign ECC Root CA - G3 불신임이란?

모질라가 10월 20일 이 루트의 신뢰를 긴급 제거하기로 하고 NSS 3.131.1에 반영한 조치다. 크롬도 같은 경로를 따르기로 했다. 유출된 중간 CA 8개가 이 루트 아래 있었기 때문이며, 모질라는 같은 시점에 emSign Root CA - G1의 신뢰는 제거하지 않았다.

mitmproxy --emudhra 옵션이란?

mitmproxy 12.3에 추가된 옵션으로, 유출된 이무드라 중간 CA 키로 가로채기용 인증서를 서명한다. 트러스트 스토어를 업데이트하지 않은 클라이언트는 별도 CA 설치 없이 이 인증서를 믿는다. 오래된 클라이언트용으로 섹티고 교차 서명을 앞세우는 --emudhra-old도 함께 나왔다.

파이썬 pip가 이무드라 사고에 취약한지 확인하려면?

pip 버전이 26.2.2 이상인지, certifi가 2026.10.19 이상인지 확인하면 된다. 파이썬 공식 공지에 따르면 pip는 내장 certifi를 시스템 트러스트 스토어와 함께 항상 읽기 때문에 OS 쪽 설정만으로는 막을 수 없다. 오래된 가상환경도 하나씩 pip를 올려야 한다.

eMudhra(이무드라), 글로벌 SSL/TLS 인증서 사업 철수 — 키 유출 닷새 만에 결정, 인증서 3만 장 교체 남았다