뒤로

2026/10/30

브라우저는 몇 시간 만에 보호되었습니다. 엔터프라이즈 Java는 어떨까요? eMudhra 인증서 사고에 대한 LOGIQ의 대응

브라우저는 침해된 eMudhra 중간 인증서를 몇 시간 만에 차단했지만, 모든 JDK는 자체 트러스트 스토어를 사용합니다. Azul과 BellSoft의 배포 내용, LOGIQ의 조치, 지금 점검할 사항을 정리합니다.

핵심 요약

  • 2026년 10월 17일, Mozilla는 eMudhra 중간 CA 인증서 8개의 개인 키가 침해되었다는 보고를 받았습니다. 브라우저들은 몇 시간에서 며칠 사이에 이 인증서들을 차단했습니다. eMudhra는 해당 키가 악용되었다는 증거를 알지 못한다고 밝혔습니다.
  • Java는 브라우저나 운영체제의 신뢰 결정을 따르지 않습니다. 모든 JDK와, JDK를 번들로 포함하는 모든 컨테이너 이미지 및 애플리케이션은 각자 자체 트러스트 스토어를 갖고 있습니다. 따라서 각각을 개별적으로 업데이트해야 합니다.
  • Azul은 10월 21일과 10월 24일 두 차례에 걸쳐 정기 일정 외 Zulu 업데이트를 배포했습니다. 두 번째 업데이트는 첫 번째 수정만으로는 충분하지 않았기 때문에 나온 것이므로, 10월 21일의 해결 방법만으로는 더 이상 충분하지 않습니다.
  • BellSoft는 Java 8, 11, 17, 21, 25, 27용 수정된 Liberica 빌드를 공개했습니다. LOGIQ는 BellSoft 지원 채널을 통해 이 빌드를 확보하여 고객에게 제공했습니다.
  • 해야 할 일: 운영 중인 모든 Java 런타임을 찾고, 정확한 벤더와 빌드를 확인하고, 해당 벤더의 수정 빌드로 전환하고, TLS 연결을 테스트하고, 정기 일정 외 릴리스를 계속 주시하십시오.

무슨 일이 있었나

2026년 10월 17일 토요일 20:06 UTC, Mozilla는 eMudhra 중간 인증서 8개의 개인 키가 침해되었다는 보고를 받았습니다. Mozilla는 중앙 폐기 목록인 OneCRL을 통해 Firefox에서 이 8개 인증서를 차단했으며, 이 업데이트는 3시간도 채 지나지 않은 22:59 UTC까지 표준 설정을 사용하는 사용자에게 적용되었습니다. Mozilla는 10월 20일 이 사고를 공개했습니다. 또한 설정상 OneCRL 업데이트가 차단된 사용자를 위해 Firefox 포인트 릴리스를 배포했고, 해당 중간 인증서에 서명한 루트 인증서를 NSS 트러스트 스토어에서 제거했습니다.

위험 요소는 인증서 위조입니다. 이 키 중 하나를 보유한 사람은 자신이 관리하지 않는 사이트의 HTTPS 인증서를 발급할 수 있습니다. 여기에 더해 클라이언트와 해당 사이트 사이에 끼어들 수 있다면, 그 사이트를 사칭하여 트래픽을 읽거나 변조할 수 있습니다.

지금까지 이런 일이 발생했다는 증거는 없습니다. eMudhra는 사고 관련 성명에서 8개 중간 인증서가 10월 18일에 폐기되었고, 그중 어느 것도 최종 엔터티 인증서를 발급한 적이 없으며, “문제가 공개되기 전에 누군가 취약한 키를 복구하거나 악용했다는 증거를 알지 못한다”고 밝혔습니다. eMudhra는 원인을 2025년 키 세리머니 중에 생성된 취약한 키로 설명합니다. 정확한 근본 원인은 아직 확인하지 못했으며 조사가 진행 중이라고 밝혔습니다. 브라우저 루트 프로그램들은 예방 차원에서 이 중간 인증서들의 상위에 있는 eMudhra 루트를 불신 처리했습니다.

즉, 이 글은 확인된 공격에 관한 것이 아니라 노출 기간을 줄이는 방법에 관한 것입니다.

Java에 별도의 수정이 필요한 이유

브라우저와 운영체제는 인증 기관에 대한 신뢰를 자동으로 중단하는 메커니즘을 갖추고 있으며, 이번에도 이를 신속하게 사용했습니다. Azul의 사고 설명에 따르면 Chrome은 같은 날, Apple은 10월 19일, Microsoft는 10월 20일에 해당 인증서를 차단했습니다.

Java는 이러한 조치를 전혀 이어받지 않습니다. JDK는 자체 파일을 기준으로 어떤 인증서를 신뢰할지 결정합니다.

  • 자체 트러스트 스토어. 모든 JDK는 자체 cacerts 파일을 포함하여 배포됩니다. 운영체제의 인증서 번들을 업데이트하거나 브라우저를 재시작해도 이 파일은 바뀌지 않습니다.
  • 기본적으로 폐기 여부를 확인하지 않음. Azul 문서에 따르면 Java는 이 중간 인증서들이 체인으로 연결되는 루트 인증서를 신뢰하며 “기본적으로 폐기 여부를 확인하지 않습니다.” eMudhra가 중간 인증서를 폐기한 것만으로는 Java 클라이언트가 보호되지 않습니다.
  • 수많은 사본. 하나의 서버에서 시스템 JDK, 애플리케이션에 번들된 JDK, jlink 런타임, 여러 컨테이너 이미지가 함께 실행될 수 있으며, 각각 트러스트 스토어 사본을 따로 갖고 있습니다. 각 사본은 업데이트되거나 다시 빌드될 때까지 노출된 상태로 남습니다.

따라서 외부로 TLS 호출을 하는 Java 서비스는 사내의 모든 브라우저가 보호된 이후에도 여전히 위조된 인증서를 수락할 수 있습니다. 이 글이 다루는 것이 바로 이 공백입니다.

Azul의 두 차례 긴급 업데이트

Azul은 10월 분기 릴리스 이후 Azul Zulu에 대해 정기 일정 외 업데이트를 두 차례 배포했습니다.

  • 10월 21일: 첫 번째 정기 일정 외 업데이트는 침해된 중간 인증서 8개를 JDK의 차단 목록(JDK 11 이상은 blocked.certs, 이전 버전은 blacklisted.certs)에 추가합니다. 대상은 Zulu 27, 25, 21, 17, 11, 8, 7, 6입니다. Azul의 CVE 목록에는 CVE-2026-91403으로 기록되어 있습니다. Azul은 즉시 업데이트할 수 없는 런타임을 위해 차단 목록 파일을 교체하는 수동 해결 방법도 공개했습니다.
  • 10월 24일: Azul은 차단 목록만으로는 문제가 완전히 해결되지 않는다는 사실을 확인했습니다. 두 번째 정기 일정 외 업데이트는 특정 CA 인증서를 cacerts에서 완전히 제거하여 CVE-2026-114820(JSSE, 기본 점수 9.1)을 수정합니다. 이 글을 작성하는 시점에 이 빌드는 Azul의 보안 전용 CPU 라인에서 2026년 10월 CPU 기반(예: Zulu 21.53.114, 17.69.114, 11.91.114, 8.97.0.112)과 2026년 7월 CPU 기반 모두로 제공됩니다. Azul은 PSU 빌드가 별도 업데이트로 뒤따를 “가능성이 높다”고 밝혔습니다.

10월 24일 업데이트로 권장 사항이 바뀌었습니다. 현재 Azul의 해결 방법 페이지는 이 방법이 “더 이상 문제를 완전히 해결하지 못한다”고 경고하며, Azul은 모든 고객에게 최신 릴리스로 업데이트할 것을 권고합니다. 10월 21일 업데이트나 해결 방법을 적용했더라도 10월 24일 빌드가 여전히 필요합니다. Azul은 자체 분석 글에서 리스핀 결정부터 보안 전용 빌드가 고객에게 전달되기까지 약 12시간이 걸렸다고 밝혔습니다.

BellSoft가 Liberica JDK용으로 배포한 내용

BellSoft는 10월 21일 정기 2026년 10월 Liberica JDK 릴리스를 공개했습니다. 이 분기 릴리스에는 52개의 수정된 CVE가 명시되어 있으며 Java 6 및 7용 CPU 빌드(6u521, 7u521)가 포함되어 있습니다. 릴리스 노트에서는 eMudhra 문제를 다루지 않습니다.

BellSoft는 별도의 가이드인 “Java에서 침해된 eMudhra 중간 인증서 불신 처리하기”(최종 업데이트 10월 27일)에서 eMudhra 문제를 다룹니다. 이 가이드는 수정 빌드로 Liberica JDK 8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5, 27.0.1.0.3+5를 제시합니다. 아직 업데이트할 수 없는 시스템을 위해서는 영향을 받는 루트를 트러스트 스토어에서 제거하는 임시 완화 조치를 안내합니다. 다만 이 조치가 정상적인 인증서 체인을 손상시킬 수 있으므로 먼저 테스트해야 한다고 경고합니다.

벤더를 비교할 때는 두 가지 사항이 중요합니다.

  • CVE 목록이 동일하지 않습니다. Azul과 BellSoft는 10월 주기에 대해 각자 CVE 목록을 공개하며, 개수와 설명이 서로 다릅니다. 위에서 언급한 두 Azul CVE ID는 Azul의 기록에서 가져온 것입니다. BellSoft의 가이드에는 이 ID들이 언급되어 있지 않습니다. 사용 중인 빌드의 정확한 수정 사항은 해당 벤더의 릴리스 노트에서 확인하고, 한 벤더의 목록이 다른 벤더의 JDK에도 적용된다고 가정하지 마십시오.
  • Java 6과 7은 BellSoft의 eMudhra 목록에 포함되어 있지 않습니다. BellSoft의 최신 Java 6 및 7 빌드는 제공되고 있지만, eMudhra 가이드의 수정 빌드 목록은 Java 8부터 시작합니다. Liberica 6 또는 7을 사용 중이라면, 해당 빌드를 신뢰하기 전에 트러스트 스토어 변경이 포함되어 있는지 문의하거나 벤더의 완화 조치를 적용하십시오. Azul은 Zulu 6 및 7용 10월 24일 빌드를 제공하고 있습니다.

LOGIQ의 대응

LOGIQ는 BellSoft와 Azul의 Java 빌드를 고객에게 배포하고, 고객이 이전 Oracle JDK 버전에서 마이그레이션하도록 지원하고 있습니다. 다음은 저희가 수행한 조치와 이 글을 작성하는 시점(10월 29일)의 항목별 상태입니다.

완료

  • 10월 21~22일: 벤더 공지 검토. Azul의 10월 21일 정기 일정 외 공지와 BellSoft의 2026년 10월 릴리스 공지를 받아 검토했습니다. 같은 날 두 벤더에 대한 다운로드 및 리포지토리 작업을 시작했습니다. 두 릴리스를 별개로 취급했으며, BellSoft의 분기 릴리스에 Azul과 동일한 eMudhra 수정이 포함되어 있다고 가정하지 않았습니다.
  • 10월 23일: Liberica 분기 빌드 준비. BellSoft 지원 포털에서 2026년 10월 Liberica JDK 빌드를 다운로드하여 고객이 다운로드하는 리포지토리에 추가했습니다.
  • 10월 24~25일: Azul 두 번째 업데이트 추적. 10월 21일 빌드를 이미 설치했더라도 업데이트하라는 권고를 포함한 Azul의 10월 24일 공지를 확인했습니다.
  • 10월 27~28일: BellSoft를 통해 Liberica 수정 빌드 확보. 상용 지원 계약을 통해 BellSoft에 최신 빌드를 저희 지원 포털에 제공해 달라고 요청했습니다. BellSoft는 10월 28일 Java 8, 11, 17, 21, 25, 27용 수정 빌드와 최신 Java 6 및 7 빌드를 업로드했습니다. 일부 고객은 여전히 32비트 Java 8이 필요하므로, Windows 및 Linux용 32비트 8u513+9 설치 프로그램도 포털에 추가해 달라고 BellSoft에 요청했습니다. BellSoft는 같은 날 이를 추가했습니다.
  • 10월 28~29일: 리포지토리 및 마이그레이션 매핑 업데이트. 이 빌드들을 고객 다운로드 리포지토리에 추가하고, 이 빌드들을 가리키도록 Oracle JDK에서 Liberica로의 마이그레이션 가이드를 업데이트했으며, 두 번째 엔지니어가 업데이트를 검토했습니다.

Azul Zulu 고객

Azul의 10월 21일 및 10월 24일 빌드는 Azul 구독 고객에게 Azul을 통해 제공됩니다. 적합한 빌드는 Java 버전, CPU 라인과 PSU 라인 중 어느 쪽을 사용하는지, 그리고 어떤 기반(10월 또는 7월)을 사용하는지에 따라 달라집니다. Azul의 릴리스 노트에서 정확한 빌드를 확인하시거나, 저희에게 문의하시면 확인을 도와드리겠습니다.

레거시 Java 6 및 7

일부 고객은 여전히 Java 6 또는 7을 사용하고 있으며, 대개 빠르게 전환할 수 없는 애플리케이션에서 사용합니다. Oracle은 더 이상 이 버전들에 대한 공개 업데이트를 제공하지 않지만, 선택지가 없는 것은 아닙니다. 저희는 고객이 오래된 Oracle JDK 6 및 7 빌드에서 최신 Liberica JDK 6 및 7 빌드로 마이그레이션하도록 지원하며, 두 버전에 대한 BellSoft의 2026년 10월 빌드는 BellSoft 지원 포털을 통해 저희가 확보할 수 있습니다. 이 버전들에 필요한 수정이나 패키지가 없을 경우, 상용 지원 채널을 통해 BellSoft에 에스컬레이션합니다. 이번 사고와 관련해서는 위의 참고 사항을 확인하십시오. 사용 중인 Java 6 또는 7 빌드를 신뢰하기 전에 eMudhra 트러스트 스토어 변경이 포함되어 있는지 확인해야 합니다.

지금 해야 할 일

1. 모든 Java 런타임 찾기

시스템 JDK뿐 아니라 Java가 실행되는 모든 곳을 목록으로 작성하십시오. 여기에는 애플리케이션 서버, 벤더 제품 내부에 번들된 런타임, jlink 이미지, CI 빌드 에이전트, 모든 컨테이너 이미지가 포함됩니다. Linux에서는 다음 명령으로 호스트의 Java 바이너리를 찾을 수 있습니다.

find / -xdev -type f -path "*/bin/java" 2>/dev/null

컨테이너 이미지의 경우 이미지 내부에서 확인을 실행하십시오. 예: docker run --rm --entrypoint java <image> -version

2. 정확한 벤더와 빌드 확인

메이저 버전만으로는 충분하지 않습니다. 벤더의 수정 빌드 목록과 대조하려면 벤더와 전체 빌드 번호가 필요합니다.

java -XshowSettings:properties -version 2>&1 | grep -E "java.vendor =|java.runtime.version|java.home"

간단한 지표로, 런타임의 트러스트 스토어에 있는 eMudhra(emSign) 루트를 나열해 볼 수도 있습니다.

keytool -list -keystore "<java.home>/lib/security/cacerts" -storepass changeit | grep -i emsign

BellSoft의 공개 컨테이너 이미지로 테스트한 결과, 이전 Liberica 21.0.10 빌드에서는 emSign 루트 5개가 나열되었고, 수정된 21.0.13.0.3+5 및 8u513 빌드에서는 하나도 나열되지 않았습니다. 결과가 비어 있다면 좋은 신호이지만 증거는 아닙니다. 예를 들어 Azul의 10월 21일 수정은 루트를 제거하지 않고 중간 인증서를 차단했습니다. 신뢰할 수 있는 확인 방법은 빌드 번호입니다. 더 자세한 확인 방법은 Java 트러스트 스토어 점검에 관한 이전 글을 참고하십시오.

3. 적용 가능한 최신 패치 적용

  • Azul Zulu: 10월 21일 빌드를 설치했거나 해결 방법을 적용했더라도, 사용 중인 라인(CPU 또는 PSU, 10월 또는 7월 기반)에 맞는 10월 24일 정기 일정 외 빌드로 전환하십시오. PSU 빌드를 사용 중이라면 Azul의 후속 PSU 릴리스를 주시하십시오.
  • Liberica JDK: BellSoft가 제시한 수정 빌드(8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5, 27.0.1.0.3+5)로 전환하십시오.
  • 기타 벤더 및 번들 런타임: 해당 벤더의 보안 권고를 확인하십시오. 서드파티 제품 내부의 JDK는 OS 업데이트가 아니라 해당 제품 벤더가 업데이트합니다.
  • 컨테이너: 수정된 베이스 이미지로 이미지를 다시 빌드하고 재배포하십시오. 실행 중인 컨테이너를 패치해도 이미지는 바뀌지 않습니다.

4. 롤아웃 전과 롤아웃 중 TLS 검증

트러스트 스토어에서 루트를 제거하면 정상적인 연결이 끊어질 수 있습니다. 예를 들어 제거된 eMudhra 루트로 체인이 연결되는 인증서를 아직 사용하는 사이트와의 연결이 그렇습니다. eMudhra는 영향을 받은 고객 인증서를 대체 CA 계층에서 재발급하고 있다고 밝혔습니다. 대규모 롤아웃 전에 애플리케이션이 의존하는 외부 TLS 연결을 테스트하십시오. 특히 eMudhra 인증서를 사용할 수 있는 파트너나 서비스와의 연결을 중점적으로 테스트해야 합니다. 단계적으로 롤아웃하고, 새 트러스트 스토어를 로드하도록 Java 프로세스를 재시작한 후, 실행 중인 버전을 확인하십시오.

5. 정기 일정 외 릴리스 주시

이번 사고로 4일 동안 두 번의 긴급 Java 릴리스가 나왔으며, Azul의 PSU 빌드처럼 추가 릴리스가 이어질 수 있습니다. 벤더의 보안 공지를 구독하고, 이메일에만 의존하지 말고 벤더의 릴리스 페이지를 직접 확인하며, 분기 일정 외의 Java 업데이트에도 대비하십시오.

교훈

Firefox 사용자가 몇 시간 만에 보호될 수 있었던 것은 브라우저가 자체 트러스트 스토어와 이를 자동으로 업데이트하는 방법을 갖추고 있기 때문입니다. 엔터프라이즈 Java에는 수많은 트러스트 스토어가 있고, 기본적으로 폐기 여부를 확인하지 않으며, 누군가 설치해야만 업데이트가 적용됩니다. 이 공백을 메우려면 정확한 인벤토리, 정확한 빌드 번호, 벤더 빌드에 대한 신속한 접근, 그리고 다음 분기 패치를 기다리지 않는 프로세스가 필요합니다. 사내 환경의 Java 런타임을 찾거나 업데이트하는 데 도움이 필요하시면 LOGIQ에 문의하십시오.

참고 자료