Haru Utils

보안 취약점 조치 · JAVA RUNTIME

Java JSSE 긴급 보안 취약점(CVE-2026-91403) 패치 및 blocked.certs 완화 가이드

Oracle 및 OpenJDK 긴급 보안 경보(CVSS 9.1 Critical, CVE-2026-91403)에 대응하여 Jenkins CI/CD 서버 및 Java WAS 환경에서 eMudhra 위조 인증서 기반 MITM 공격을 방지하기 위해 최신 보안 패치 빌드(.0.2 이상) 판올림과 폐쇄망 긴급 차단(blocked.certs 교체)을 수행하는 표준 조치 절차입니다.
Java 보안 취약점CVE-2026-91403JSSE 긴급 패치blocked.certs 교체Jenkins Java 보안eMudhra 위조 인증서OpenJDK 긴급 업데이트Red Hat OpenJDK 패치
지원 환경Red Hat Enterprise Linux (RHEL) 8·9 (RHEL 9.4 포함) 및 Rocky Linux 8·9
예상 시간약 45분
난이도중급
검토일2026-10-26

BEFORE YOU START

시작 전에 준비하세요

01

sudo/root 권한을 보유한 운영자 계정 및 SSH 터미널 접속 세션

02

현재 서버에서 구동 중인 Java 프로세스(Jenkins, Tomcat, Spring Boot)의 서비스명 및 $JAVA_HOME 경로

03

현재 설치된 JDK/JRE 버전(java -version) 및 패키지 벤더(Red Hat OpenJDK, Ubuntu OpenJDK, Oracle JDK 등) 확인

04

기존 $JAVA_HOME/lib/security 디렉터리 백업 경로 및 서비스 재시작 허용 작업 시간(점검 창)

권장 대상 Jenkins CI/CD 서버 또는 Java 백엔드 WAS를 운영하며, 긴급 CVSS 9.1 보안 권고에 따라 런타임 업그레이드 또는 폐쇄망 blocked.certs 보안 조치를 안전하게 적용하려는 시스템 관리자·DevOps 엔지니어

FOLLOW THE RECIPE

8단계 구성·점검 레시피

1
확인시스템을 변경하지 않는 점검 단계

현재 Java 버전·벤더 및 영향받는 서비스(Jenkins 등) 진단

현재 구동 중인 Java 런타임 버전이 10월 20일 정기 패치를 포함하여 취약점(CVE-2026-91403) 영향 범위에 속하는지 확인하고, Jenkins 및 WAS 프로세스의 실행 바이너리 및 $JAVA_HOME 경로를 읽기 전용으로 진단합니다.

Java 버전 및 벤더 확인
java -version
javac -version 2>/dev/null || true
버전 끝자리가 .0.2 이상이 아니거나 10월 20일 이전 빌드인 경우 취약 대상입니다.
설치된 Java 패키지 및 바이너리 경로 확인
rpm -qa | grep -E 'java|openjdk' 2>/dev/null || dpkg -l | grep -E 'openjdk|jdk'
readlink -f $(which java)
RHEL/Rocky는 rpm으로, Ubuntu는 dpkg로 설치된 패키지명을 식별합니다.
Jenkins 및 구동 중인 Java 프로세스 상태 확인
sudo systemctl status jenkins --no-pager 2>/dev/null || ps -ef | grep -E 'java|jenkins'
패치 후 재시작 대상이 되는 서비스명과 프로세스 PID를 기록합니다.
  • 현재 Java 메이저 버전(8, 11, 17, 21, 25, 27) 및 빌드 번호 대조 완료
  • 취약 버전(끝자리가 .0.2 미만)임을 확인하고 목표 안전 버전(.0.2 이상) 식별
  • 실행 중인 Java 서비스(Jenkins 등)와 $JAVA_HOME 실제 경로 파악 완료
결과 읽기

10월 20일 정기 패치 버전도 취약하므로 반드시 10월 21일 이후 긴급 배포된 .0.2 빌드 이상이어야 안전합니다.

다음 판단

보안 설정 디렉터리와 blocked.certs 파일 구조 및 백업 경로를 점검합니다.

2
확인시스템을 변경하지 않는 점검 단계

JSSE 보안 디렉터리와 blocked.certs 파일 구조 및 디스크 점검

Java 보안 설정 디렉터리($JAVA_HOME/lib/security) 내 기존 blocked.certs(Java 8은 blacklisted.certs) 파일 존재 여부와 Jenkins 서비스 리스닝 포트를 확인합니다.

기존 blocked.certs / blacklisted.certs 파일 확인
JAVA_DIR=$(dirname $(dirname $(readlink -f $(which java))))
ls -ld $JAVA_DIR/lib/security/blocked.certs $JAVA_DIR/jre/lib/security/blacklisted.certs 2>/dev/null || ls -ld $JAVA_DIR/lib/security
Java 11/17/21 이상은 blocked.certs, Java 8은 blacklisted.certs 파일명을 사용합니다.
서비스 리스닝 포트(Jenkins 8080 등) 확인
sudo ss -tulpn | grep -E ':(8080|8443|8009)\b'
작업 중 포트 충돌 방지 및 정상 리스닝 상태를 대조합니다.
디스크 여유 공간 확인
df -h / /var /usr /tmp
새 JDK 패키지 설치를 위한 최소 2GB 이상의 디스크 여유 공간을 확보합니다.
  • JAVA_HOME 하위 security 디렉터리 경로 식별 완료
  • Jenkins 웹 서비스 리스닝 포트(8080 등) 정상 바인딩 확인
  • 폐쇄망 패키지 반입 및 백업을 위한 디스크 공간 확보 확인
결과 읽기

폐쇄망 환경에서 즉시 전체 JDK를 업그레이드하기 어려운 경우, 3단계의 방법 B(blocked.certs 파일 교체)를 통해 신속한 긴급 완화가 가능합니다.

다음 판단

긴급 패치 JDK 설치(방법 A) 또는 blocked.certs 반입(방법 B)을 진행합니다.

3
변경패키지·설정·서비스 상태가 달라지는 단계

최신 보안 패치 JDK 설치(방법 A) 또는 blocked.certs 반입(방법 B)

운영 환경에 따라 최신 보안 패치 JDK(.0.2 빌드 이상)로 패키지를 업그레이드하거나(방법 A - 권장), 폐쇄망 긴급 완화용 최신 blocked.certs 파일을 반입합니다(방법 B).

변경 단계입니다. 대상 서버, 백업 파일, 서비스 중단 영향과 바로 이전 상태로 돌아가는 방법을 다시 확인하세요.
[방법 A 권장] RHEL 9.4·Rocky Linux DNF 패키지 업그레이드
sudo dnf upgrade -y java-21-openjdk java-21-openjdk-devel || sudo dnf upgrade -y java-17-openjdk java-17-openjdk-devel
RHEL/Rocky 폐쇄망인 경우 사전 반입된 최신 OpenJDK RPM 패키지를 dnf localinstall로 설치합니다.
[방법 A 권장] Ubuntu APT 패키지 업그레이드
sudo apt-get update && sudo apt-get install --only-upgrade -y openjdk-21-jdk openjdk-21-jre-headless || sudo apt-get install --only-upgrade -y openjdk-17-jdk openjdk-17-jre-headless
배포판 보안 저장소에서 10월 21일 긴급 패치가 반영된 최신 패키지를 설치합니다.
[방법 B 폐쇄망 완화] OpenJDK 권고 blocked.certs 파일 무결성 검증
test -f /tmp/blocked.certs && sha256sum /tmp/blocked.certs || echo '신규 차단 파일 반입 필요'
외부에서 OpenJDK 권고안(CVE-2026-91403)에서 다운로드한 8개 인증서 차단 목록 파일의 체크섬을 확인합니다.
설치된 Java 버전 확인
java -version
방법 A 적용 시 버전 문자열에 .0.2 이상 빌드가 표시되는지 확인합니다.
  • 방법 A: 패키지 업그레이드 후 java -version에서 .0.2 이상 빌드 확인
  • 방법 B: 반입된 blocked.certs 파일의 SHA256 체크섬 대조 완료
결과 읽기

방법 A로 JDK가 판올림된 경우 자체 신뢰 저장소에 이미 차단 목록이 내장되어 있습니다. 방법 B는 파일 교체 단계(4단계)로 이어집니다.

다음 판단

기존 보안 설정 백업 및 차단 파일 교체/설정을 구성합니다.

4
주의권한·연결·중단 영향을 확인할 단계

기존 보안 설정 백업 및 blocked.certs 교체 / java.security 점검

보안 디렉터리의 원본 파일들을 사전에 백업하고, 방법 B 적용 시 최신 blocked.certs 파일을 배치하며 java.security 설정 내 차단 목록 활성화 상태를 점검합니다.

기존 보안 디렉터리 및 차단 파일 백업
JAVA_DIR=$(dirname $(dirname $(readlink -f $(which java))))
sudo cp -p $JAVA_DIR/lib/security/blocked.certs $JAVA_DIR/lib/security/blocked.certs.bak 2>/dev/null || sudo cp -p $JAVA_DIR/jre/lib/security/blacklisted.certs $JAVA_DIR/jre/lib/security/blacklisted.certs.bak 2>/dev/null || true
sudo cp -p $JAVA_DIR/conf/security/java.security $JAVA_DIR/conf/security/java.security.bak 2>/dev/null || sudo cp -p $JAVA_DIR/lib/security/java.security $JAVA_DIR/lib/security/java.security.bak 2>/dev/null || true
롤백을 대비하여 기존 설정과 차단 파일을 .bak으로 백업합니다.
[방법 B 적용 시] 신규 blocked.certs 파일 배치 및 권한 부여
JAVA_DIR=$(dirname $(dirname $(readlink -f $(which java))))
test -f /tmp/blocked.certs && sudo cp -p /tmp/blocked.certs $JAVA_DIR/lib/security/blocked.certs && sudo chmod 644 $JAVA_DIR/lib/security/blocked.certs || true
Java 8인 경우 파일을 $JAVA_DIR/jre/lib/security/blacklisted.certs로 복사합니다.
java.security 설정 확인 및 필요시 편집
JAVA_DIR=$(dirname $(dirname $(readlink -f $(which java))))
sudoedit /usr/lib/jvm/default-jvm/conf/security/java.security
jdk.certpath.disabledAlgorithms 설정에 취약 알고리즘 및 인증서 차단 옵션이 활성화되어 있는지 확인합니다.
설정 예시 · /usr/lib/jvm/default-jvm/conf/security/java.security
java.security 인증서 및 알고리즘 차단 보안 설정 권고
jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \
    RSA keySize < 2048, DSA keySize < 2048, EC keySize < 224, \
    include jdk.disabled.namedCurves\n\njdk.security.ca.distrustPolicies=SYMANTEC_TLS
  • 기존 blocked.certs 및 java.security 파일 백업(.bak) 생성 확인
  • 신규 blocked.certs 파일 권한이 644(읽기 전용)로 올바르게 설정됨 확인
  • java.security 파일에서 인증서 체인 검증 옵션 활성화 확인
결과 읽기

설정 파일 준비가 완료되면 Java 런타임이 새 인증서 차단 정책을 적용하도록 프로세스를 재시작합니다.

다음 판단

Jenkins 및 Java 기반 서비스(WAS)를 재시작합니다.

5
변경패키지·설정·서비스 상태가 달라지는 단계

Java 서비스(Jenkins 등) 재기동 및 런타임 적용

긴급 패치된 JDK 바이너리 또는 교체된 blocked.certs 정책을 메모리에 적재하기 위해 Jenkins 및 WAS 서비스를 재시작하고 자동 시작 상태를 유지합니다.

변경 단계입니다. 대상 서버, 백업 파일, 서비스 중단 영향과 바로 이전 상태로 돌아가는 방법을 다시 확인하세요.
Jenkins 서비스 재기동
sudo systemctl restart jenkins
WAS나 독립형 애플리케이션의 경우 해당 서비스명(예: tomcat, myapp)을 재시작합니다.
서비스 기동 상태 및 활성화 확인
sudo systemctl status jenkins --no-pager -l
서비스가 active (running) 상태로 정상 기동되었는지 확인합니다.
신규 Java 프로세스 메모리 적재 확인
ps -ef | grep jenkins | grep java
PID가 갱신되어 새 Java 런타임에서 실행 중인지 대조합니다.
  • Jenkins 서비스가 오류 없이 active (running) 상태로 재시작됨을 확인
  • 새 프로세스가 정상적인 JVM 옵션과 함께 기동되었음을 확인
결과 읽기

서비스가 정상 재기동되면 JSSE 모듈이 문제의 eMudhra 중간 인증서 8개를 신뢰 목록에서 배제하고 통신을 차단합니다.

다음 판단

Jenkins 웹 콘솔 접속 및 TLS 연결 정상 동작을 검증합니다.

6
확인시스템을 변경하지 않는 점검 단계

JSSE 인증서 검증 및 Jenkins 웹 접속·빌드 테스트

Jenkins 웹 인터페이스가 정상 응답하는지 확인하고, GitLab 연동 파이프라인 또는 외부/사내 TLS 통신이 문제없이 동작하는지 검증합니다.

Jenkins 로컬 웹 포트 응답 확인
curl -s -I http://127.0.0.1:8080/login | grep -E '(HTTP/|Server)'
HTTP 200 정상 응답이 반환되는지 확인합니다.
Jenkins 서비스 최근 에러 로그 모니터링
sudo journalctl -u jenkins -n 40 --no-pager | grep -iE 'error|exception|certificate' || echo 'No critical certificate errors'
TLS 핸드셰이크 예외나 인증서 체인 오류가 없는지 대조합니다.
Java 보안 버전 대조 검증
java -version 2>&1 | head -n 3
방법 A 패치 적용 시 .0.2 이상 안전 버전이 표시되는지 최종 확인합니다.
  • Jenkins 웹 UI(HTTP 8080) 정상 접속 및 로그인 가능 확인
  • 시스템 로그에 CertificateException 또는 SSLHandshakeException 부재 확인
  • GitLab 연동 빌드 테스트가 정상 수행됨을 확인
결과 읽기

정상 응답과 빌드가 확인되면 위조 인증서 악용 위험이 차단된 안전한 상태입니다.

다음 판단

cacerts 신뢰 저장소 무결성 및 폐쇄망 보안 조치를 점검합니다.

7
주의권한·연결·중단 영향을 확인할 단계

신뢰 저장소(cacerts) 무결성 및 폐쇄망 보안 정책 점검

Java 자체 신뢰 저장소(cacerts)의 파일 변조 방지 권한을 설정하고, 폐쇄망 내부 프록시 및 Jenkins 전용 서비스 계정의 최소 권한 원칙을 검토합니다.

신뢰 저장소(cacerts) 파일 권한 및 소유권 제한
JAVA_DIR=$(dirname $(dirname $(readlink -f $(which java))))
sudo chmod 644 $JAVA_DIR/lib/security/cacerts 2>/dev/null || sudo chmod 644 $JAVA_DIR/jre/lib/security/cacerts 2>/dev/null || true
cacerts 파일에 일반 계정의 임의 쓰기 권한이 부여되지 않도록 644로 제한합니다.
Jenkins 서비스 실행 계정 권한 확인
id jenkins 2>/dev/null || ps -o user,comm -p $(pgrep -f jenkins | head -n 1)
Jenkins가 root 권한이 아닌 전용 jenkins 계정으로 격리 구동되는지 점검합니다.
폐쇄망 내부 프록시 TLS 통신 점검
sudo ss -lntp | grep -E ':(8080|8443)\b'
인가되지 않은 외부 네트워크 인터페이스로의 바인딩 여부를 확인합니다.
  • cacerts 파일 권한이 644(root 쓰기 전용)로 설정됨 확인
  • Jenkins가 root가 아닌 전용 서비스 계정으로 안전하게 구동됨 확인
  • 폐쇄망 내부망 정책에 따른 신뢰 인증기관 목록 정합성 확인
결과 읽기

자체 신뢰 저장소 권한이 안전하게 잠기면 비인가된 중간자 인증서 삽입이 방지됩니다.

다음 판단

장애 발생 시 백업 파일 복원 및 롤백 절차를 숙지합니다.

8
주의권한·연결·중단 영향을 확인할 단계

장애 발생 시 백업 파일 복원 또는 이전 JDK 버전 롤백

신규 JDK 패치 후 레거시 플러그인 충돌이나 인증서 검증 실패로 Jenkins가 기동되지 않는 경우, 백업된 security 설정을 복원하거나 이전 패키지로 롤백합니다.

백업된 blocked.certs 및 java.security 파일 복원
JAVA_DIR=$(dirname $(dirname $(readlink -f $(which java))))
sudo cp -p $JAVA_DIR/lib/security/blocked.certs.bak $JAVA_DIR/lib/security/blocked.certs 2>/dev/null || sudo cp -p $JAVA_DIR/jre/lib/security/blacklisted.certs.bak $JAVA_DIR/jre/lib/security/blacklisted.certs 2>/dev/null || true
sudo cp -p $JAVA_DIR/conf/security/java.security.bak $JAVA_DIR/conf/security/java.security 2>/dev/null || sudo cp -p $JAVA_DIR/lib/security/java.security.bak $JAVA_DIR/lib/security/java.security 2>/dev/null || true
작업 4단계에서 생성한 .bak 백업 파일로 원복합니다.
[방법 A 롤백 시] 이전 Java 버전 alternatives 선택 또는 다운그레이드
sudo alternatives --config java 2>/dev/null || sudo update-alternatives --config java 2>/dev/null || true
이전 안정화 JDK 버전 심볼릭 링크를 선택하거나 패키지를 롤백합니다.
Jenkins 서비스 재기동 및 복구 검증
sudo systemctl restart jenkins
sudo systemctl status jenkins --no-pager
서비스가 이전 정상 상태로 복구되었는지 확인합니다.
  • 백업된 blocked.certs 및 java.security 파일 복원 완료
  • Jenkins 서비스 재기동 후 active 상태 확인
  • 기존 빌드 및 웹 서비스 기능 정상 복구 확인
결과 읽기

롤백 후 장애를 유발한 플러그인 또는 자체 서명 사내 인증서 호환성을 분석한 후 재적용 일정을 수립합니다.

다음 판단

서비스 정상 복구 확인 후 작업 일지를 기록합니다.

SECURITY CHECK

운영 전 마지막 보안 점검

  • JDK/JRE 버전이 10월 21일 긴급 배포된 .0.2 이상 안전 빌드로 업데이트되었는지 확인
  • 폐쇄망 완화 조치 시 blocked.certs(Java 8은 blacklisted.certs) 파일이 정상 배치되었는지 확인
  • Java 신뢰 저장소(cacerts) 파일의 권한이 644로 제한되어 임의 변조가 차단되었는지 확인
  • Jenkins CI/CD 서버 및 WAS 프로세스가 root가 아닌 전용 서비스 계정으로 구동되는지 확인

COMMON ERRORS

자주 막히는 지점

패치 후 사내 사설 인증서(Private CA) 통신 실패

증상
사내 GitLab 또는 내부 Maven 저장소 접속 시 PKIX path building failed 에러 발생
가능한 원인
새 JDK 설치 시 이전 JDK의 cacerts에 수동 등록했던 사내 사설 Root CA가 기본 cacerts로 덮어씌워짐
확인 순서
이전 cacerts 백업에서 사내 인증서를 추출하여 keytool -importcert -keystore $JAVA_HOME/lib/security/cacerts -alias internal-ca -file internal.crt로 재등록합니다.
트러블슈팅으로 이어보기

Java 8 환경에서 blocked.certs 교체 후 차단 미반영

증상
파일을 교체했는데도 차단 대상 인증서가 계속 신뢰되거나 로그에 반영되지 않음
가능한 원인
Java 8은 blocked.certs가 아닌 $JAVA_HOME/jre/lib/security/blacklisted.certs 파일명을 요구함
확인 순서
파일명을 blacklisted.certs로 변경하여 $JAVA_HOME/jre/lib/security/ 경로에 배치하고 서비스를 재시작합니다.
트러블슈팅으로 이어보기

Jenkins 서비스 재시작 후 기동 실패 (Failed to start)

증상
systemctl restart jenkins 실행 시 Job for jenkins.service failed 오류 발생
가능한 원인
JDK 메이저 버전이 변경되어 기존 JVM 옵션(예: MaxPermSize 등) 비호환 또는 파일 권한 불일치
확인 순서
journalctl -u jenkins -e 로그에서 원인 예외를 확인하고, /etc/default/jenkins 또는 systemd override 옵션을 점검합니다.
트러블슈팅으로 이어보기

PRIMARY REFERENCES

공식 문서

설치 저장소와 지원 버전은 바뀔 수 있습니다. 검토일 이후에는 링크된 공식 문서와 현재 서버의 패키지 후보 버전을 함께 확인하세요.

TROUBLESHOOT NEXT

설치 후 문제라면 여기서 이어가세요

트러블슈팅 · TLS HANDSHAKETLS 인증서 만료·체인·SNI·프로토콜 장애진단 순서 보기 →트러블슈팅 · SYSTEMD서비스가 시작되지 않거나 failed일 때진단 순서 보기 →트러블슈팅 · WEB GATEWAYNGINX 502·504 오류를 진단할 때진단 순서 보기 →트러블슈팅 · PERMISSIONSPermission denied 원인을 찾을 때진단 순서 보기 →

NEXT RECIPE

함께 볼 구성 레시피

CI/CD CONTROLLERJenkins LTS 설치와 초기 보안 설정8단계로 보기 →GITLAB SECURITY PATCHGitLab 보안 취약점 조치 폐쇄망 인플레이스 버전 업그레이드 (Rocky Linux · Red Hat Enterprise Linux 9.4/el8·el9)8단계로 보기 →JAVA APPLICATIONJava 21·Spring Boot·NGINX 운영 구성8단계로 보기 →

도구 빠른 검색

최근 사용한 도구를 다시 열거나, 이름과 기능으로 검색하세요.

검색어와 도구의 입력·결과는 저장하지 않습니다.

↑↓ 이동 · Enter 열기 · Esc 닫기