eMudhra 인증서 사고 총정리: 신뢰 저장소 점검 시리즈 글

eMudhra 인증서 사고 총정리: 신뢰 저장소 점검법

안녕하세요,

그로메트릭 입니다. 🐸

 

2026년 10월 17일, 한 연구자가 eMudhra 중간 인증기관(CA) 8곳의 개인키가 불충분한 무작위성으로 생성되어 복구될 수 있다고 보고했습니다. 여기에는 TLS 인증서용 6개와 코드 서명용 2개가 포함됩니다. 영향받는 TLS 키를 가진 사람은 웹사이트나 서비스용 인증서를 만들 수 있고, 해당 체인을 여전히 신뢰하는 클라이언트는 이를 받아들일 수 있다는 점이 핵심 리스크입니다. 브라우저와 운영체제 벤더는 영향받는 인증서를 차단했지만, 다른 소프트웨어는 별도로 존재하거나 번들된 인증서 신뢰 저장소(trust store)에 의존할 수 있어 브라우저 보호만으로는 조직 전체의 조치가 끝났다고 말할 수 없습니다.

이번 글은 소나타입이 10월 21~23일에 공개한 eMudhra 관련 글 세 편을 하나로 엮었습니다.

먼저 사고 개요와 소나타입 제품 영향, 고객이 취해야 할 조치를 살펴봅니다. 이어서 Java의 blocked.certs가 SHA-256 지문으로 인증서를 차단하는 방식이 재인코딩된 인증서를 놓칠 수 있음을 보여 준 재현 테스트를 소개합니다. 마지막으로 Java, Node.js, Python, Go, Git 등 개발자 도구가 어떤 인증서 체인을 신뢰하는지 점검하는 오픈소스 감사 스크립트와 그 한계를 다룹니다.

 

*아래 글은 소나타입(Sonatype)의 공식 블로그 글을 번역하여 재구성해 작성되었습니다.

---

[Part 1] eMudhra CA 사고: 소나타입의 평가와 대응 가이드 📋

소나타입은 업계 전반에 영향을 미친 eMudhra 인증기관(CA) 사고에 대응하고 있습니다. 이번 사고는 일부 소나타입 제품과 배포본이 사용하는 인증서 신뢰 저장소(trust store)에 영향을 줍니다. 소나타입은 영향받는 구성 요소를 업데이트하고 있으며, 그동안에는 운영체제, 런타임, 애플리케이션 벤더가 제공하는 인증서 신뢰 저장소 업데이트를 적용하시기 바랍니다.

eMudhra CA 이슈 요약

2026년 10월 17일, 한 연구자가 eMudhra 중간 인증기관(CA) 8곳의 개인키가 불충분한 무작위성으로 생성되어 복구될 수 있다고 보고했습니다. 영향받는 중간 CA 중 6곳은 TLS 인증서용, 2곳은 코드 서명용이었습니다. 영향받는 TLS 키를 가진 사람은 웹사이트나 서비스용 인증서를 만들 수 있으며, 해당 체인을 여전히 신뢰하는 클라이언트는 이 인증서를 받아들일 수 있습니다.

(※ 그로메트릭 참고: 소나타입 원문 간에 날짜 표기가 다릅니다. 위 글은 10월 17일 보고로 안내하지만, 이어지는 Part 2 원문에서는 키 침해일을 10월 20일로 표기하고 있어 날짜가 조금 다르게 나옵니다. 두 글 모두 원문 그대로 옮겼습니다.)

브라우저와 운영체제 벤더는 영향받는 인증서를 차단하는 조치를 취했습니다. 그 밖의 소프트웨어는 별도로 존재하거나 번들된 인증서 신뢰 저장소에 의존할 수 있어 업데이트가 필요하므로, 조직은 브라우저와 운영체제 외의 시스템도 함께 점검해야 합니다.

소나타입 제품에 미치는 영향

소나타입은 최신 인증서 신뢰 데이터를 반영한 업데이트된 Docker 이미지와 패치 릴리스를 준비하고 있습니다. 아래 표는 영향받는 소나타입 제품과 조치 현황을 정리한 것입니다. 기존 Docker 이미지와 번들된 JVM은 자동으로 업데이트되지 않습니다.

자체 관리(self-managed) 환경에서는 해당 업데이트 Docker 이미지 또는 패치 릴리스가 제공되는 대로 설치하시기 바랍니다.

자체 호스팅(self-hosted) 솔루션:

제품	영향받는 버전	조치 현황
Sonatype Nexus Repository	2026년 10월 21일 이전에 릴리스된 모든 버전	진행 중
Sonatype IQ Server (Lifecycle, SBOM Manager, Firewall, Developer)	208 및 이전 버전	진행 중

클라우드 솔루션:

제품	영향 여부	조치 현황
Sonatype Nexus Repository	예	완료
Sonatype IQ Server (Lifecycle, SBOM Manager, Firewall, Developer)	예	완료
Sonatype Guide	예	완료

업데이트 소식은 소나타입 Help 문서에서 계속 확인하시기 바랍니다. 소나타입이 해당 제품에 대한 안내를 제공하지 않는 한, 제품에 번들된 JVM 신뢰 저장소를 수동으로 변경하지 마십시오.

고객이 해야 할 조치

고객은 가능한 한 빨리 다음 조치를 취해야 합니다.

• 브라우저와 운영체제를 신속하게 업데이트하십시오.
• 컨테이너와 애플리케이션을 포함해 신뢰 저장소를 번들하는 모든 소프트웨어와 인증서 신뢰 저장소를 업데이트하십시오.
• eMudhra가 발급한 인증서를 사용하는 시스템을 관리한다면, 인증서 공급자에게 연락해 인증서 체인이 영향을 받는지, 교체 또는 다른 조치가 필요한지 확인하십시오.
• 인증서 검증 경고를 우회하지 마십시오.

앞으로의 계획

소나타입은 자사 제품과 배포본의 인증서 신뢰 상태를 검토하고 있으며, 필요한 곳에 업데이트를 준비하고 있습니다. 수정된 버전이 나오는 대로 제품별 안내를 보안 이벤트 채널과 관련 제품 업데이트 채널에 게시할 예정입니다.

eMudhra 인증기관 사고는 Go 및 관련 생태계 프로젝트에서 CVE-2026-111943으로 추적되고 있습니다. 조직에서는 Amazon Linux 패키지에 대한 CVE-2026-113470, Red Hat의 RHSB-2026-012 등 관련 권고도 접할 수 있습니다. 이러한 식별자는 영향받는 소프트웨어와 신뢰 저장소 전반에서 사고를 추적하는 데 도움이 되며, 조치 방법은 제품과 환경에 따라 다를 수 있습니다.

취약점 상세 내용은 Sonatype Guide의 CVE-2026-111943 페이지에서 확인할 수 있습니다. Sonatype Guide는 무료로 구독할 수 있습니다. 조치는 운영체제, 런타임, 애플리케이션 벤더가 제공하는 해당 안내를 따르시기 바랍니다.

---

[Part 2] 지문 기반 차단목록의 한계: 재현 가능한 Java 인증서 우회 ⛓️‍💥

핵심 요약 (TL;DR)

• 소나타입의 테스트 결과, Java의 blocked.certs는 목록에 있는 인증서 인코딩은 거부했지만, 테스트한 구성에서는 여전히 검증을 통과하는 재인코딩 버전은 받아들였습니다.
• eMudhra 사고와 관련된 ECDSA 서명 및 RSA 서명 중간 인증서에서 이 동작을 재현했습니다. 재인코딩된 인증서는 각각 SHA-256 지문이 달랐습니다.
• 이 결과는 테스트한 JDK 버전과 신뢰 저장소 구성에 적용됩니다. 최신 벤더 안내를 따르고, 실제로 배포하는 런타임과 신뢰 저장소에서 보호 조치가 동작하는지 검증하십시오.

인증서 차단목록은 알려진 불량 인증서를 거부하더라도 같은 인증서의 다른 인코딩은 놓칠 수 있습니다.

소나타입은 eMudhra 인증서 사고에 대한 Java의 대응을 살펴보다가 이를 확인했습니다. 이 완화 조치는 SHA-256 지문으로 침해된 중간 인증서를 식별합니다. 그러나 인증서의 지문은 인코딩된 정확한 바이트로 계산됩니다.

 

AI 기반 검토 과정에서 Sonatype Research Labs는 Opus 5.5에게 Java의 정확 지문(exact-fingerprint) 차단을 우회할 수 있는지 물었습니다. 이 AI 모델은 바이트가 정확히 일치해야 하는 방식이 동등한 인증서 인코딩의 여지를 남길 수 있다고 지적했습니다.

 

eMudhra소나타입은 ECDSA와 RSA 인증서 모두에서 이 동작을 확인했습니다. 재인코딩된 중간 인증서는 SHA-256 지문이 달랐음에도 Java 신뢰 저장소 테스트에서 여전히 검증을 통과했습니다. 이는 정확 지문 차단의 한계를 보여 줍니다. 이 방식은 알고 있는 인증서 바이트는 식별할 수 있지만, 동등한 모든 인코딩을 반드시 포괄하지는 않습니다.

이 글에서는 재인코딩이 어떻게 이루어지는지, 테스트가 무엇을 보여 주는지, 인증서 차단목록을 유일한 완화 수단으로 믿기 전에 팀이 무엇을 확인해야 하는지 설명합니다.

시작: eMudhra 인증서 침해

여러 eMudhra 중간 인증기관 키가 2026년 10월 20일 침해되었으며, 키를 입수한 누구든 신뢰받는 루트로 이어지는 체인의 일부로 신뢰될 수 있는 인증서를 만들 수 있게 되었습니다. 이에 따라 Java 측 완화 조치도 나왔습니다. 영향받는 중간 인증서를 blocked.certs에 추가하는 것입니다. 소나타입의 연구는 더 좁은 질문에서 출발했습니다. 지문 기반 차단이 해당 인증서의 유효한 인코딩을 모두 거부하는가?

(※ 그로메트릭 참고: 이 글 원문은 키 침해일을 10월 20일로 표기하고 있어, 앞선 Part 1 원문의 10월 17일 보고 시점과 날짜가 다릅니다. 두 글 모두 원문 표기 그대로 옮겼습니다.)

Exact-Fingerprint 차단은 어떻게 작동할까

인증서는 구조화된 문서입니다. 주체(subject), 공개 키, 발급자, 유효 기간, 디지털 서명 같은 정보를 담고 있습니다. Java에서 blocked.certs는 SHA-256 지문으로 인증서를 식별합니다. 지문은 인증서의 인코딩된 바이트로 계산되므로, 바이트가 조금만 바뀌어도 지문이 달라집니다.

그래서 지문 차단은 정밀하지만, 일치 여부는 차단목록에 올라 있는 정확한 인코딩에 좌우됩니다. 인증서를 재인코딩해도 서명 검증을 통과할 수 있다면, 새 인코딩은 지문이 달라 목록의 항목과 일치하지 않을 수 있습니다. 대체 인코딩이 실제로 여전히 검증을 통과하는지 확인하기 위해 소나타입은 ECDSA와 RSA 두 가지 서명 형식을 살펴보았습니다.

인코딩을 바꾸면 결과가 달라진다

소나타입은 eMudhra 사고 권고에 나온 두 인증서 체인, 즉 ECDSA 서명 중간 인증서 체인과 RSA 서명 중간 인증서 체인을 테스트했습니다. 각 체인에 대해 재현 스크립트는 원본 중간 인증서의 SHA-256 지문을 JDK의 blocked.certs 파일 사본에 추가하고, 개인키 없이 중간 인증서의 인코딩을 바꾼 다음, 체인이 여전히 검증을 통과하는지 확인했습니다.

두 가지 인코딩 변경은 다음과 같습니다.

• ECDSA: 스크립트가 서명 값을 s에서 n − s로 바꿉니다. 이는 서명의 또 다른 유효한 표현입니다.
• RSA: 바깥쪽 서명 알고리즘 식별자에서 NULL 파라미터를 제거합니다. 인증서 데이터에 대한 서명은 그대로입니다.

두 테스트 모두 같은 결과가 나왔습니다. Java는 중간 인증서의 지문이 목록에 있는 원본 체인은 거부했지만, 지문이 다른 재인코딩 중간 인증서가 포함된 체인은 신뢰했습니다. 복사한 JDK의 신뢰 저장소에서 해당 루트를 제거한 뒤에는 두 체인 모두 거부되었습니다.

실제 사용하는 런타임에서 완화 조치를 검증하세요

팀은 실제로 배포하는 Java 런타임과 신뢰 저장소에서 인증서 완화 조치를 검증해야 합니다. 소나타입의 테스트에서는 해당 루트를 제거하면 두 체인이 모두 거부되었지만, 이는 정상적인 TLS 연결도 중단시킬 수 있습니다. 신뢰 저장소를 변경하기 전에 의존하는 서비스를 파악하고, 해당 인증서 체인을 테스트하며, 배포 후 TLS 실패를 모니터링하십시오.

 

최신 벤더 안내를 따르고 예외 사항은 문서로 남기십시오. 이 결과는 소나타입이 검토한 JDK 버전과 신뢰 저장소 구성에만 해당하므로, 다른 런타임과 환경 내 다른 TLS 경로에 대해서는 각각 별도로 통제 수단을 검증해야 합니다.

---

[Part 3] eMudhra 인증서 사고: 개발자 도구 신뢰 상태 점검 가이드 ✅

브라우저 보호는 eMudhra 인증기관 사고에 대한 중요한 1차 대응이었습니다. 하지만 조직이 더 어려운 질문, 즉 영향받는 인증서 체인을 아직도 신뢰하는 다른 도구와 환경은 무엇인가라는 질문에는 답해 주지 못합니다.

 

인증서 신뢰는 여러 곳에서 올 수 있습니다. 도구는 운영체제의 신뢰 저장소, 번들된 인증서 목록, 또는 Java JDK의 cacerts 같은 런타임 전용 저장소를 사용할 수 있습니다. 따라서 한 대의 머신에서도 브라우저, 개발자 도구, 런타임마다 신뢰 동작이 다를 수 있습니다. 신뢰 저장소 하나를 업데이트한다고 모든 저장소가 업데이트되지는 않습니다.

 

결국 eMudhra 이슈는 소프트웨어 공급망 문제로 봐야합니다. 팀은 신뢰가 어디에 설정되어 있는지 찾고, 어떤 시스템에 조치가 필요한지 파악하며, 업데이트가 개발자와 빌드 프로세스가 실제로 사용하는 도구에 반영되었는지 확인해야 합니다.

먼저 각 도구가 무엇을 신뢰하는지에서부터 시작하세요.

소나타입 오픈소스 프로그램 오피스(OSPO)의 글로벌 디렉터인 Paul Horton은 Unix 계열 머신에서 선택된 개발자 도구를 점검할 수 있도록 오픈소스 eMudhra Audit and Fix 스크립트를 만들었습니다.

이 스크립트는 Java, Node.js, Python, Go, Git 같은 도구와 시스템 인증서 번들 및 기타 구성 요소를 점검합니다. 지원되는 경우, 영향받는 중간 인증서로 이어지는 체인을 가진 두 테스트 호스트에 실제 HTTPS 요청을 보낸 뒤, 대조군으로 GitHub를 확인합니다. 이 대조군은 인증서 거부와 네트워크 접근 불가 같은 다른 연결 문제를 구분하는 데 도움이 됩니다. 또한 일부 도구 버전을 사고 참조 문서에 기재된 수정 버전과 비교합니다. 실시간 프로브와 버전 점검 결과가 서로 다르면 실시간 프로브 결과가 우선합니다.

 

기본적으로 감사는 머신에 아무것도 설치, 변경, 삭제하지 않습니다. 임시 프로브 프로그램을 만들고 일반적인 HTTPS 요청을 보낼 뿐이며, 이 요청은 파일 내용을 전송하지 않습니다. 네트워크 프로브가 적합하지 않은 환경이라면 --no-network 옵션으로 프로브를 건너뛰고 버전 점검만 실행할 수 있습니다.

 

팀은 결과를 활용해 조치가 필요한 도구를 파악하고 다음에 무엇을 조사할지 결정할 수 있습니다. 감사 결과는 조치의 출발점일 뿐, 조직의 모든 시스템이 보호된다는 확인은 아닙니다.

결과를 조치로 연결하세요 

팀은 스크립트의 출력을 다음과 같이 활용할 수 있습니다.

• 워크스테이션에서 영향받거나 영향받을 가능성이 있는 도구를 식별합니다.
• 각 도구가 어떻게 설치되었고 어떤 신뢰 저장소를 사용하는지 확인합니다.
• 해당하는 운영체제, 런타임 또는 애플리케이션 벤더의 업데이트를 적용합니다.
• 점검을 다시 실행하고 여전히 조치가 필요한 시스템을 기록합니다.

이 스크립트에는 선택 사항인 --fix 모드도 있어, 지원하는 일부 변경을 변경 전마다 확인을 구하며 적용할 수 있습니다. 여기에는 지원되는 도구의 업그레이드나 시스템 또는 런타임 신뢰 저장소의 변경이 포함될 수 있습니다. 진행하기 전에 README와 제안된 조치를 검토하십시오. --dry-run 옵션을 사용하면 아무것도 변경하지 않고 fix가 무엇을 할지 확인할 수 있습니다. 가능하면 벤더 업데이트를 우선하고, 어떤 우회 방법이든 신뢰 저장소에 의존하는 시스템과 서비스에서 테스트하십시오.

스크립트가 볼 수 없는 영역도 존재합니다

이 스크립트는 실행되는 머신만 감사합니다. 원격 호스트, 컨테이너, 프로젝트별 의존성은 스캔하지 않습니다. 점검 범위는 지정된 도구와 설치 경로로 제한되며, 일부 도구는 실시간 프로브 없이 버전 점검만 받습니다. 따라서 개발자 워크스테이션의 결과로는 CI 러너, 컨테이너 이미지, 프로덕션 호스트, 다른 직원의 머신 상태를 확인할 수 없습니다.

 

조직은 이러한 환경을 조사의 별도 영역으로 다뤄야 합니다. 컨테이너 이미지, 빌드 에이전트, 관리 대상 시스템은 각각에 적용되는 절차와 벤더 안내에 따라 업데이트하고 검증하십시오. 소나타입 제품은 제품별 업데이트와 지침에 대해 최신 Help 문서를 따르시기 바랍니다.

eMudhra 사고는 브라우저 상태만으로는 조직이 조치를 마쳤는지 답할 수 없는 이유를 보여 주었습니다. 신뢰 저장소는 도구와 환경 전반에 흩어져 있으며, 각각 담당자와 상태를 검증할 방법이 필요합니다. Paul의 스크립트는 이 전체 중 일부를 살펴볼 수 있는 실용적인 방법을 제공합니다. 작업을 마무리하려면 여전히 더 넓은 인벤토리, 벤더 업데이트, 후속 점검이 필요합니다.

 

이 스크립트는 Sonatype Nexus Community의 일부입니다. 피드백을 주거나 기여하고 싶다면 기여 가이드라인(Contribution Guidelines)에 따라 프로젝트에 참여하십시오. 커뮤니티 프로젝트이므로 소나타입이 공식적으로 지원하지는 않습니다.

 

eMudhra 사고와 소나타입의 대응에 대한 배경은 본 글의 Part 1을 참고하십시오.

---

출처

소나타입 블로그 
1) eMudhra CA Incident: Sonatype's Assessment and Guidance

eMudhra CA Incident: Sonatype's Assessment and Guidance

2) Limits of Fingerprint Blocklists: A Reproducible Java Certificate Bypass

Limits of Java Certificate Bypass: Fingerprint Blocklist Insights

3) eMudhra Certificate Incident: A Practical Audit to Inspect Developer Tools

eMudhra Incident: A Practical Audit to Inspect Tools