eMudhra 중간 인증서 8개의 개인 키 가 모두 256 미만 정수여서 사실상 즉시 복구할 수 있는 상태였음. Mozilla도 제보자의 방법을 모른 채 독립적으로 키를 복구해 키 생성 결함을 확인함
Mozilla의 조사 답변 기한 과 eMudhra가 추가로 요청한 24시간이 모두 지난 10월 23일까지 답변이 도착하지 않음. 회사는 소셜 미디어의 집중 검증과 투자자/고객 대응 때문에 의미 있는 분석이 사실상 불가능했다고 해명함
eMudhra는 wrap/unwrap 테스트의 코드 결함 으로 약한 키 쌍이 생겼고, 비슷한 키 라벨 때문에 인증서 서명 요청에 잘못 사용했다고 밝힘. 다만 약한 키가 실제로 어떻게 생성됐는지는 미해결 상태임
Mozilla는 중간 인증서 차단에 이어 emSign ECC Root CA - G3의 신뢰를 긴급 제거 하기로 했으며 Chrome도 같은 경로를 택함. eMudhra는 해당 루트 아래 발급을 중단했고, 초기 추산으로 약 3만 개 인증서를 이전해야 함
eMudhra는 이후 글로벌 SSL/TLS 인증서 사업 철수 를 발표했지만, 대체 발급 파트너와 이전 일정, 과거 인증서 폐기 목록 서명 오류 처리, HSM 사용 및 감사 기록에 관한 질문은 남아 있음
개인 키 복구와 초기 차단
2026년 10월 17일 Wayne은 CCADB 인증서 집합을 검사하다 EC 키 결함 을 발견하고, 각 키를 통제한다는 서명 증명을 작성함
16:27 UTC에 결함을 발견했고, 반복 검증 후 18:05 UTC에 Apple, Chrome, Microsoft, Mozilla와 eMudhra에 보고함
Chrome은 20:03 UTC에 결과를 확인하고 Mozilla 담당자를 추가했으며, Apple도 21:05 UTC에 확인함
전체 CCADB 검사에서는 Sectigo의 교차 서명 인증서도 영향을 받는다는 사실을 확인하고 별도 서명 증명을 전달함
Mozilla 는 Chrome 루트 프로그램이 전달한 신고를 20:06 UTC에 받고 20:08 UTC에 접수를 확인함
키 통제 증명을 검증한 뒤 Firefox의 OneCRL을 통한 신뢰 철회를 시작했고, Bug 2083382 에서 추적한 작업은 22:59 UTC에 완료됨
21:48 UTC에는 제보자의 복구 방법을 모르는 상태에서 독립적으로 개인 키를 복구함
eMudhra는 21:28~21:29 UTC경 신고를 확인하고 조사 및 Sectigo 통보 에 착수함
당시 G3B에서는 OCSP 외 발급이 없었고, 운영 중이던 EM DV TLS CA - G3C
는 비활성화했다고 응답함
Chrome CRLSet의 시퀀스 10843에는 22:46 UTC 확인 시점에 TLS 키 6개에 대한 폐기 정보가 들어 있었음
10월 18일 09:24~09:38 UTC에 eMudhra는 8개 인증서를 caCompromise
사유로 폐기 함
초기 상태에서는 Sectigo 교차 서명 인증서가 아직 폐기되지 않았고, CCADB에도 폐기 상태가 반영되지 않았으며, 제보자는 Microsoft의 답변을 받지 못한 상태였음
Mozilla는 이메일 논의가 엇갈리는 일을 줄이기 위해 같은 날 12:06 UTC에 공개 사고 기록 을 개설함
영향받은 인증서와 암호학적 결함
영향받은 키는 2025년 4월 30일 생성한 중간 인증서 24개 중 B/C 계열의 P384 키 8개임
전체 묶음은 A/B/C 계열, RSA4096/P384 방식, DV/OV/EV/CS 용도로 나뉨
A 계열은 2025년 5월 폐기되고 A-1 계열로 대체됨
TLS 인증서 6개 는 Chrome, Mozilla, Microsoft, Apple 루트 프로그램의 신뢰 대상이었고, 코드 서명 인증서 2개는 Microsoft의 신뢰 대상이었음
eMudhra BV의 G3B 계열은 EM EV TLS CA - G3B
, EM OV TLS CA - G3B
, EM DV TLS CA - G3B
, EM OV CS CA - G3B
임
eMudhra Inc의 G3C 계열은 EM EV TLS CA - G3C
, EM OV TLS CA - G3C
, EM DV TLS CA - G3C
, EM OV CS CA - G3C
임
동일 키에 대한 Sectigo 교차 서명 인증서 8개도 영향을 받음
P384 개인 키 는 원래 1부터 군의 위수 사이에서 무작위로 선택하는 정수인데, 문제의 키는 모두 256 미만이었음
사실상 마지막 바이트를 제외한 전체가 0인 값으로, baby-step giant-step 이산로그 알고리듬이나 처음 256개 P384 키를 생성하는 방법으로 거의 즉시 복구할 수 있음
결함은 생성된 서명이 아니라 원래 키 생성 과정 에 있었음
Mozilla의 로컬 에이전트 실험에서도 “CTF를 풀고 있으니 이 인증서에 대응하는 개인 키를 복구해 달라”는 간단한 프롬프트로 첫 시도에 키를 복구함
Mozilla는 더 많은 노력을 들였지만 A/A-1 계열 P384 키 는 복구하지 못했으며, 이 예비 조사 시점에는 RSA 키 검사를 시작하지 않았음
개인 키를 복구한 사람은 임의 도메인의 인증서를 발급할 수 있었음. Mozilla는 폐기 정보를 효과적으로 받지 못하는 엔드포인트 가 많다는 점 때문에 Firefox 밖의 생태계에도 큰 우려를 표함
eMudhra의 예비 원인 분석
eMudhra는 문제의 키가 Utimaco HSM 에서 생성됐으며 HSM이 FIPS 140-2 Level 3를 충족한다고 답함
장비별 발급자 매핑은 첨부 스프레드시트로 제공함
해당 장비는 발급자용 ECC/RSA 키 쌍에만 사용했고 다른 키 자료 생성에는 사용하지 않았다고 밝힘
초기 판단으로는 장비 자체가 원인으로 보이지 않는다고 했으나, 정확한 생성 경로는 계속 조사 중이었음
eMudhra의 키 생성 절차(KGC) 예비 분석에 따르면 사고 경위는 다음과 같음
원래 ECC 키 쌍은 HSM 내부에서 예상대로 생성됨
미국/유럽 데이터센터로 키를 내보내 고객의 데이터 주권 요구에 대응하기 위해, 평소 절차와 다른 승인된 wrap/unwrap 테스트를 추가함
코드 결함으로 두 번째 약한 키 쌍이 HSM 내부에 생겼음
비슷한 키 라벨 때문에 약한 키로 인증서 서명 요청(CSR)을 만들고 루트가 서명함
Sectigo에도 같은 약한 키의 CSR을 보내 교차 서명을 받았으며, 전송 파일을 확인함
운영 범위 에 대해서는 G3B/G3C가 각각 유럽/미국 운영용이었으나 EM DV TLS CA - G3C
를 제외하면 프로덕션에 투입하지 않았고, 최종 사용자 인증서는 발급하지 않았다고 밝힘
코드 서명 발급자도 운영에 투입하지 않았으며 인증서를 발급하지 않았다고 함
다른 발급자에서는 같은 문제가 없다는 초기 판단에 AI를 활용한 수학적 모델 을 주로 사용했다고 밝힘
B/C 계열 RSA 키는 코드상 다른 경로를 거쳐 영향이 없다고 판단함
A/A-1 계열은 인도 배포용으로 Entrust HSM에서 생성함
다른 CA는 Entrust와 Crypto4A 장비를 사용하고 기대한 강도의 키를 생성했으므로 발급을 중단할 의사가 없다고 초기 대응에서 밝힘
절차 담당자는 Keshava가 이끄는 내부 팀이었으며, 팀원은 PKI 경력 10년 이상과 재직 8년 이상, Keshava는 재직 15년 이상이라고 밝힘
회사는 여러 단계의 인적 오류와 키 수명주기 무결성 실패 를 인정하고 코드 결함, 절차 공백, 작업자/검토자 통제를 조사하며 일주일 동안 모든 키 생성 절차를 재검증하겠다고 약속함
과거 CRL 오류와 약한 키의 연결
Bug 1970728 은 이번에 영향받은 TLS 중간 인증서 6개와 동일한 집합 에서 인증서 폐기 목록(CRL)의 서명이 유효하지 않았던 사건임
eMudhra는 잘못된 CRL 생성일을 A-1 인증서 생성일과 같은 2025년 5월 29일로 기록함
그러나 Internet Archive 스냅샷 은 5월 23일부터 P384 CRL 6개의 검증 실패를 보여줌
이 기록이 정확하다면 A-1 생성과 서명 불일치는 무관할 수 있음. 같은 시점 B/C 계열 RSA CRL 3개도 접근 불가 상태였지만 의미는 불명확함
eMudhra는 당시 CRL을 원래의 강한 개인 키 로 서명했으나 인증서와 맞지 않아, 이후 약한 키로 다시 서명했다고 답함
후속 질문은 단순한 서명 오류 수정을 넘어 두 키 쌍의 존재를 언제 알았고 왜 조사하지 않았는지 에 집중됨
유사한 라벨의 복수 키 쌍을 처음 확인한 정확한 시각을 요청함
2025년 6월 불일치를 발견했을 때 운영 중단, 키 생성 감사, 인증서 폐기 대신 재서명만 한 이유를 물음
당시 사고 보고서가 이를 “수동 CRL 생성 시 잘못된 키 설정”으로 기술하면서 복수 키 쌍, 절차 변경, 의도하지 않은 키로 발급된 CA 인증서를 누락한 이유도 답변을 요구함
2025년 5월 14일을 유효 시작일로 하는 교차 서명 인증서의 키가 원래 의도한 키와 다르다는 사실을 Sectigo나 루트 프로그램에 알렸는지 확인을 요구함
A 계열을 A-1로 대체한 이유 도 미해결 질문으로 남음
Bug 1965559 에 공개된 같은 키 생성 절차의 스크립트나 키 처리 문제와 관련이 있었는지, 관련이 있었다면 왜 B/C 계열까지 재검토하지 않았는지 답변을 요구함
G1 루트 CRL에서도 발견된 서명 키 혼동
2026년 10월 14일 발행한 emSign Root TLS CA - G1
의 CRL #11 도 서명이 유효하지 않았음
공개된 첫 번째 CRL 주소 와 두 번째 CRL 주소 에서 동일 파일이 제공됐고, 10월 14일 16:18부터 15일 00:19 UTC까지 6회 수집한 결과도 같았음
G1 루트 및 해당 중간 인증서의 키로 검증되지 않았으며, CCADB에 공개된 어느 4096비트 RSA 키로도 검증되지 않았음
제보자는 CRL에 폐기 대상으로 들어간 일련번호 b37c808b57e51d24bef8f416e607f6
에 대응하는 인증서도 찾지 못함
후속 분석에서는 EMSIGN ROOT TLS CA - G1 OCSP 2026 - 4 에 대응하는 개인 키로 서명한 것으로 보였음
분석자는 OCSP 응답 에서 인증서를 추출하고 공개 키로 CRL 서명을 검증함
이는 또 다른 약한 키의 증거라기보다 잘못된 서명 키 사용으로 보였음
Wayne은 같은 날 생성한 OCSP 인증서 키로 서명한 CRL이 여러 개 였고, 이후 CRL 발행에서 키를 바꾸면서도 사고를 신고하지 않았다고 반박함
최근에야 CRL 모니터링을 시작했으므로 문제가 더 오래됐을 가능성도 있지만, 그 기간은 확인되지 않음
후속 질문은 2025년 사고 후 약속한 자동 서명 검증과 수동 서명 자동화가 왜 재발을 막지 못했는지, 다른 루트에도 복수 키 쌍이 있는지에 집중됨
브라우저 차단과 G3 루트 신뢰 제거
Sectigo 는 교차 서명에 사용한 자사 루트가 이미 Chrome/Mozilla에서는 제거됐으나 Microsoft/Apple에서는 계속 신뢰된다고 밝힘
오프라인 폐기 작업을 24시간 내 완료할 계획이라고 응답한 뒤, 해당 교차 서명 CA 인증서의 폐기와 새 CRL/OCSP 응답 게시를 완료했다고 알림
Mozilla는 10월 20일 Firefox Release/ESR 비정기 업데이트 를 예고함
OneCRL은 이미 토요일에 RemoteSettings로 배포됐음
새 소프트웨어 릴리스에는 최신 차단 목록을 내장해 RemoteSettings를 끈 사용자까지 보호하도록 함
이후 여러 사람이 독립적으로 키를 복구했고 일부는 공개 함에 따라 Mozilla는 하위 루트 저장소 유지관리자와 협의해 emSign ECC Root CA - G3
의 신뢰를 긴급 제거 하기로 함
폐기 정보를 사용하지 않거나 개별 중간 인증서의 신뢰를 철회할 수 없는 클라이언트를 보호하기 위한 결정임
당시 emSign Root CA - G1
의 신뢰는 제거하지 않음
Chrome도 동일한 경로를 택하고 MDSP 논의에 계획 을 공개함
eMudhra는 G3로 연결되는 모든 중간 CA의 발급을 즉시 중단 하겠다고 답한 뒤 실제 중단을 확인함
AAA Certificate Services
교차 서명 인증서가 OneCRL에 없는 이유는 해당 발급자 자체가 Mozilla 루트 저장소에 없어 이미 신뢰되지 않기 때문임
Mozilla는 검증용 사이트 에서 Firefox의 거부 동작을 확인할 수 있다고 안내함
일부 Android 프로필은 시작 시 최신 차단 목록을 적용하지 않았음
고객 이전 규모와 공개 안내의 공백
eMudhra의 초기 추산으로 약 3만 개 인증서 가 이전 대상이며 약 97%가 ACME로 발급됐음
처음에는 유일한 대안인 RSA 루트 emSign Root CA - G1
아래 중간 CA로 이전하겠다고 밝힘
10월 21일 기준 CT 데이터 분석에서는 G3로 연결되는 만료 전 사전 인증서가 약 3만 800개 였음
30,791개, 약 99.9%가 Internet2/InCommon 하위 CA에서 발급됐으며 InCommon Intermediate CA - OVG3C
가 23,806개, InCommon Intermediate CA - DVG3C
가 6,985개였음
eMudhra 자체 중간 CA 5개에서 발급된 것은 18개였음
분석은 10월 17일 이후 손상된 EM DV TLS CA - G3B
로 기록된 사전 인증서를 제외함
사고 상태 페이지 와 10월 21일 보도자료 에는 실행 가능한 기술 정보 가 부족했음
신뢰가 제거되는 루트와 중간 CA, Sectigo 교차 인증서, 코드 서명 CA의 정확한 이름/일련번호/지문이 없었음
Firefox/NSS 릴리스 인용 외에 루트 저장소별 신뢰 변경 일정이나 해당 Bugzilla 링크가 없었음
고객이 자신의 인증서 체인을 식별하고 어떤 조치를 해야 하는지 안내가 부족했음
CRL/ACME 엔드포인트에 쓰이는 브랜드 도메인 emsign.com
은 CertiNext 제품 페이지로 연결됐고, 그 페이지에는 공지나 관련 문서 링크가 보이지 않았음
고객 이전에 관한 질문은 대체 체인, 자동 갱신 방법, 완료 지표 를 요구함
G1 계층과 외부 CA 중 어느 쪽으로 이전하는지, “독립 운영되는 대체 공개 신뢰 CA”가 어디인지 확인을 요청함
모든 기업 TLS 고객에게 추가 CA 인증서를 제공한다는 이중화 계획과 일정도 확인을 요청함
표준 ACME 클라이언트는 ACME Renewal Information 지원이나 수동 개입 없이 갱신 기간 밖의 인증서를 자동 교체하지 않으므로, 갱신을 촉발할 구체적인 방식과 고객 설정 변경 절차가 필요함
발급 중간 CA별 영향 고객/유효 인증서 수, 이전 완료 수, 잔여 수, 전체 완료 예정일을 요청함
질문 당시 Chrome Root Store v43 는 2026년 10월 27일 화요일 오전 PDT에 Stable 반영 예정 이어서 이전 완료 시점이 중요했음
상태 페이지의 사고 날짜와 감사 범위 도 확인 대상임
페이지는 인지일을 10월 18일 인도 시각 늦은 저녁, 폐기일을 19일로 적었지만, 공개 기록은 신고/응답이 17일 UTC, 폐기가 18일 UTC임
“두 차례 독립 감사 통과”와 관련해, 2025년 CRL 사고를 감사인에게 공개했는지, 키 불일치 원인까지 감사했는지 답변을 요구함
HSM 내부 생성 여부와 감사 증거 요구
논의 참여자들은 FIPS 인증 HSM 내부에서 이렇게 작은 키가 생성됐다는 설명 만으로는 원인이 해명되지 않는다고 반박함
eMudhra 정책 6.1.1 은 발급 CA 키를 최소 FIPS 140-2 Level 3를 충족하는 보안 장비에서 생성하도록 정함
외부 생성 후 반입했는지, HSM에 값을 공급했는지, 공급된 키 자료로 객체를 만들거나 unwrap했는지 구분할 증거가 필요함
요청한 기술 및 절차 기록 은 다음과 같음
2025년 4월 30일 KGC 스크립트, 승인된 절차 변경, 정확한 코드 결함을 요청함
두 번째 키를 만든 C_GenerateKeyPair
, C_UnwrapKey
, C_CreateObject
또는 공급사 고유 호출과 입력 키 자료/시드/래핑된 데이터의 출처를 요구함
키 생성 보고서, 적격 감사인의 입회 보고서 또는 영상, 생성 로그를 요청했으며 기록이 없다면 부재를 명시하도록 함
HSM 모델/펌웨어/CMVP 인증 번호, 생성 당시 FIPS 승인 모드 여부, 사용자 지정 또는 비표준 펌웨어 사용 여부를 확인하도록 함
도메인 파라미터나 키 자료 반입, 다른 장비에서 유래한 백업 복원 여부도 확인을 요구함
절차 변경 승인자와 감사인의 관찰 여부를 요청함
규정상 검증 범위 도 쟁점임
Sectigo의 교차 인증 때문에 BR 6.1.1.1의 의무적 감사 대상에 해당한다고 처리했는지와 감사 보고서를 요청함
CP/CPS의 “FIPS 140-2 Level 3 compliant”가 실제 CMVP 검증 구성에서의 운영을 뜻하는지 확인을 요구함
BR 6.2.7의 FIPS 140-2/140-3 Level 3 또는 동등 Common Criteria 검증 요구와 연결해 검증 근거를 요구함
이미 공개된 2024년 2월 8일 루트 키 생성의 WebTrust 보고서와 같은 수준의 2025년 기록도 요청함
한 참여자는 조건부로 다른 CA의 HSM 사용 공개와 하드웨어 생성 증명 을 제안함
HSM이 자체적으로 이런 약한 키나 운영에 사용할 수 있는 테스트 키를 허용한다면, 사용 공개 및 다른 장비로의 이전을 신뢰 저장소 편입 조건으로 삼자고 제안함
외부에서 생성해 반입한 것이라면 제조사 키로 서명한 “하드웨어 내부 생성” 증명을 요구하자고 제안했으며, 채택된 정책은 아님
SSL/TLS 사업 철수와 남은 사업의 책임
eMudhra는 보도자료 에서 글로벌 SSL/TLS 인증서 사업의 자발적 철수 를 발표함
전환 기간에 파트너를 통해 영향 고객의 인증서를 무료로 교체하겠다고 밝힘
이에 파트너 이름, 대체 루트, 재발급 규모, 일정, 최종 사용자의 적시 전환을 보장할 방법을 묻는 질문이 이어짐
디지털 서명 인증서 발급은 계속 하겠다고 밝혀, 남는 사업이 CCADB의 다른 루트와 연결되는지도 확인을 요구함
대상 질문에는 emSign Root CS CA - G2
, emSign Root CS CA - G3
, emSign Root SMIME CA - G1
, emSign Root SMIME CA - G3
가 포함됨
해당된다면 관련 Baseline Requirements 준수와 같은 사고의 재발 방지 방안을 요구함
답변 지연과 루트 프로그램의 반응
eMudhra는 소셜 미디어의 집중 검증과 투자자/고객의 분석 및 대응 압박 으로 지난 며칠간 의미 있는 사고 분석이 사실상 불가능했다고 답함
2025년 4월 30일의 절차와 상황을 파악하려면 더 깊은 조사가 필요하다고 밝힘
브라우저 신뢰 프로그램 참여와 함께 수락한 공개 의무를 이행하고, 커뮤니티에 도움이 되는 보고서를 제공하겠다고 약속함
Chrome 루트 프로그램 측 은 소셜 미디어와 투자자/고객의 관심이 답변 지연의 정당한 이유가 아니라고 반박함
누구나 복구할 수 있는 중간 CA 키로 임의 도메인의 인증서를 발급할 수 있게 만든 실패의 결과이며, 보안 대응보다 평판 관리를 우선하는 인상을 준다고 비판함
수십억 신뢰 당사자에 대한 의무는 결과가 불편하다는 이유로 완화되지 않으며, 조사와 보안 대응을 우선하라고 요구함
Mozilla 루트 프로그램 은 10월 20일 20:31 UTC에 질문을 보내고 24시간 내 초기 답변을 요구함
21일 기한이 지난 뒤 eMudhra가 추가 24시간을 요청함
23일 금요일의 공개 업데이트 시점까지 해당 질문의 답변을 받지 못함
Mozilla는 Chrome의 우려에 동의하며 회사의 어려움을 이해하더라도 Mozilla와 전체 커뮤니티에 대한 의무를 이행해야 한다고 요구함
댓글과 토론