이 글은 Sonatype 공식 블로그의 The Limits of Fingerprint Blocklists: A Reproducible Java Certificate Bypass을 에스코어가 공식 파트너로서 한국어로 번역한 콘텐츠입니다.
에스코어 인사이트
인증서의 SHA-256 지문을 차단 목록에 등록하는 것만으로는 논리적으로 동일한 인증서의 모든 인코딩을 차단할 수 없다는 점을 보여주는 사례입니다. 다만 실험 결과를 모든 Java 환경에 일반화해서는 안 됩니다.
•
운영 중인 JDK 버전과 신뢰 저장소별로 인증서 차단 목록 적용 상태 및 검증 동작을 확인합니다.
•
인증기관 신뢰 제거 등 공급업체가 권고하는 조치를 검토하면서 정상 TLS 연결에 미치는 영향을 사전 점검합니다.
•
신뢰 저장소 변경 전 의존 서비스와 인증서 체인을 확인하고, 변경 후 TLS 오류와 인증서 검증 실패를 모니터링합니다.
Sonatype 원문 번역
인증서 지문 차단 목록의 한계: 재현 가능한 Java 인증서 검증 우회
핵심 요약
•
Sonatype의 테스트에서 Java의 blocked.certs는 차단 목록에 등록된 인코딩의 인증서는 거부했지만, 인코딩을 변경한 인증서는 테스트한 환경에서 여전히 검증을 통과했습니다.
•
eMudhra 사고와 관련된 ECDSA 서명 중간 인증서 및 RSA 서명 중간 인증서를 사용해 이 동작을 재현했습니다. 인코딩을 변경한 각 인증서는 원본과 다른 SHA-256 지문을 가졌습니다.
•
이 결과는 테스트한 JDK 버전과 신뢰 저장소 구성에 한정됩니다. 최신 공급업체 권고를 따르고 실제 배포하는 런타임과 신뢰 저장소에서 보호 조치가 제대로 작동하는지 확인해야 합니다.
인증서 차단 목록이 알려진 문제가 있는 인증서는 거부하더라도, 동일한 인증서의 다른 인코딩까지 모두 차단하지는 못할 수 있습니다.
Sonatype은 eMudhra 인증서 사고에 대한 Java의 대응을 조사하면서 이 문제를 확인했습니다. 해당 완화 조치는 SHA-256 지문으로 유출된 중간 인증서를 식별합니다. 그러나 인증서 지문은 인코딩된 바이트 값 그 자체를 토대로 계산됩니다.
AI 지원 검토 과정에서 Sonatype Research Labs는 Opus 5.5에 Java의 정확한 지문 일치 방식으로 구현된 차단을 우회할 수 있는지 질문했습니다. AI 모델은 바이트 단위로 정확히 일치하는지만 확인하면 동등한 다른 인증서 인코딩을 놓칠 가능성이 있다고 지적했습니다.
연구진은 ECDSA 및 RSA 인증서 모두에서 이 동작을 확인했습니다. 인코딩을 변경한 중간 인증서는 원본과 SHA-256 지문이 달랐지만, Java 신뢰 저장소를 사용하는 테스트에서 여전히 유효한 인증서로 검증됐습니다. 이는 정확한 지문 일치 방식의 한계를 보여줍니다. 이미 알려진 인증서의 바이트 값은 식별할 수 있어도 동등한 인코딩을 모두 포괄한다고 보장할 수는 없습니다.
아래에서는 인코딩 변경이 어떻게 작동하는지, 테스트에서 어떤 결과가 나왔는지, 인증서 차단 목록만을 완화 조치로 사용하기 전에 무엇을 확인해야 하는지 설명합니다.
사건의 시작: eMudhra 인증서 침해
2026년 10월 20일, eMudhra 중간 인증기관의 개인키 여러 개가 유출된 사실이 알려졌습니다. 개인키를 확보한 사람은 신뢰된 루트 인증기관까지 이어지는 인증서 체인의 일부로 신뢰받을 수 있는 인증서를 생성할 수 있게 됐습니다. 이에 브라우저 및 플랫폼 공급업체는 차단 조치와 신뢰 저장소 변경으로 대응했습니다.
그 과정에서 Java를 위한 완화 조치도 마련됐습니다. 영향을 받은 중간 인증서를 blocked.certs에 추가하는 방식입니다. Sonatype 연구진의 질문은 더 구체적이었습니다. 지문에 기반한 차단 조치가 해당 인증서의 유효한 모든 인코딩을 거부하는가?
정확한 지문 일치 방식의 차단 원리
인증서는 정형화된 문서로, 주체, 공개키, 발급자, 유효기간, 디지털 서명 등의 정보를 담습니다. Java의 blocked.certs는 SHA-256 지문으로 인증서를 식별합니다. 이 지문은 인증서가 인코딩된 바이트 값에서 계산되므로, 바이트가 조금만 달라져도 다른 지문이 생성됩니다.
이 방식은 정밀하게 인증서를 차단할 수 있지만 차단 목록에 등록된 인코딩과 정확히 일치해야 합니다. 인증서의 인코딩을 변경해도 서명 검증을 통과한다면 새 인코딩은 다른 지문을 갖게 되므로 기존 차단 항목과 일치하지 않을 수 있습니다. 연구진은 실제로 다른 인코딩이 여전히 검증되는지 알아보기 위해 ECDSA와 RSA, 두 가지 서명 형식을 조사했습니다.
인코딩을 바꾸면 검증 결과도 달라진다
연구진은 eMudhra 사고 권고문에 포함된 인증서 체인 두 개를 테스트했습니다. 하나는 ECDSA로 서명된 중간 인증서를, 다른 하나는 RSA로 서명된 중간 인증서를 포함했습니다. 각 테스트에서는 원본 중간 인증서의 SHA-256 지문을 JDK의 blocked.certs 파일 사본에 추가했습니다. 그런 다음 개인키 없이 중간 인증서의 인코딩을 변경하고 인증서 체인이 여전히 검증을 통과하는지 확인했습니다.
인코딩은 다음 두 방식으로 변경했습니다.
•
ECDSA: 서명 값의 s를 동일한 서명을 표현하는 또 다른 유효한 값인 n − s로 변경했습니다.
•
RSA: 외부 서명 알고리즘 식별자에서 NULL 매개변수를 제거했습니다. 인증서 데이터에 대한 서명은 그대로 유지했습니다.
두 테스트 모두 결과는 같았습니다. Java는 중간 인증서의 지문이 차단 목록에 등록된 원본 인증서 체인을 거부했습니다. 반면 인코딩을 변경해 다른 지문을 갖게 된 중간 인증서의 체인은 신뢰했습니다. 이후 복사한 JDK 신뢰 저장소에서 관련 루트 인증서를 제거하자 두 인증서 체인 모두 거부됐습니다.
실제 런타임에서 완화 조치를 검증해야 한다
각 조직은 실제 배포하는 Java 런타임과 신뢰 저장소에서 인증서 관련 완화 조치가 제대로 작동하는지 확인해야 합니다. Sonatype의 테스트에서는 관련 루트 인증서를 제거하자 두 인증서 체인이 모두 거부됐지만 이 조치로 정상적인 TLS 연결도 중단될 수 있습니다. 따라서 신뢰 저장소를 변경하기 전에 영향을 받는 서비스를 파악하고 인증서 체인을 테스트한 뒤 배포 후 TLS 연결 실패 여부를 모니터링해야 합니다.
최신 공급업체 권고를 따르고 예외 사항도 문서화해야 합니다. 이번 결과는 연구진이 조사한 JDK 버전과 신뢰 저장소 구성에만 해당하므로 조직 내 다른 런타임이나 TLS 통신 경로에서는 통제 조치를 별도로 검증해야 합니다.
에스코어는 Sonatype 공식 파트너로서 소프트웨어 공급망 보안 및 오픈소스 거버넌스 구축을 지원합니다.
도입이나 구축이 필요하시면 언제든 문의해 주세요.
지원 솔루션: Nexus Repository · Repository Firewall · Lifecycle · Sonatype Guide