- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 루트 인증서 만료 또는 신뢰 저장소 불일치로 발생하는 서명 검증 실패를 원인별로 진단하고, Windows/서버/개발환경에서 재발 없이 복구하는 절차를 실무 수준으로 정리하는 것이다.
1. 루트 인증서 만료로 서명 검증이 실패하는 구조 이해
1) “루트 만료”는 보통 두 가지 상황으로 나타나는 것이다
첫째는 실제로 루트 또는 중간 인증서가 만료되어 체인이 정상적으로 완성되지 않는 상황이다. 둘째는 루트는 최신인데도, 클라이언트가 오래된(만료된) 루트를 신뢰 앵커로 선택하거나, 자동 갱신이 막혀 최신 루트를 받지 못해 검증이 실패하는 상황이다.
2) 서명 검증 실패가 의미하는 범위를 먼저 구분하는 것이 핵심이다
서명 검증 실패는 웹사이트(SSL/TLS) 접속 오류일 수도 있고, 코드 서명(EXE/MSI/드라이버) 검증 실패일 수도 있으며, 패키지 매니저(apt/yum) 또는 Java JAR 서명 검증 실패일 수도 있다. 같은 “인증서” 문제처럼 보이지만, 신뢰 저장소 위치와 갱신 경로가 서로 달라 해결법이 달라지는 것이다.
주의 : 시간 동기화가 어긋나면 “만료”처럼 보이는 오탐이 발생하기 쉽다. 조치 전후로 시스템 시간이 정확한지 먼저 확인하는 것이 우선이다.
2. 증상별 빠른 분류 체크리스트
| 증상 | 대표 에러/현상 | 가능성이 큰 원인 | 우선 조치 |
|---|---|---|---|
| 웹사이트 접속 시 인증서 오류 | 연결이 비공개가 아님, SEC_E_UNTRUSTED_ROOT | 클라이언트 루트 저장소 오래됨, 프록시/SSL 가로채기 | OS 루트 업데이트, 프록시 루트 배포 여부 확인 |
| EXE/MSI 실행 시 게시자 확인 불가 | 서명을 확인할 수 없음, 0x800B0109 | 루트/중간 누락, 자동 루트 업데이트 차단, 타임스탬프 부재 | 인증서 체인 확인 후 루트 갱신, 타임스탬프 검증 |
| 드라이버/커널 모드 서명 문제 | 드라이버 로드 실패, 서명 강제 관련 메시지 | 루트/중간 누락, 정책/부팅 옵션, 오래된 OS | Windows 업데이트 및 신뢰 저장소 갱신, 정책 점검 |
| apt/yum 업데이트 실패 | certificate verification failed, x509: certificate signed by unknown authority | ca-certificates 패키지 오래됨, 신뢰 번들 손상 | ca-certificates 업데이트/재설치 |
| Java 통신/서명 검증 실패 | PKIX path building failed, unable to find valid certification path | JRE cacerts 오래됨, 사내 프록시 루트 미등록 | JRE cacerts 갱신 또는 사내 루트 import |
3. Windows에서 가장 확실한 복구 절차(클라이언트/서버 공통)
1) 시스템 시간 동기화 확인이 1순위이다
인증서 검증은 “현재 시간”을 기준으로 수행되므로 시간이 틀리면 만료로 판단될 수 있다. 특히 도메인 환경, 가상화 호스트/게스트, CMOS 배터리 문제에서 빈발하는 것이다.
w32tm /query /status w32tm /resync2) 자동 루트 업데이트가 차단되어 있지 않은지 확인하는 것이 핵심이다
Windows는 필요한 루트를 주문형으로 내려받는 동작이 가능하며, 정책으로 차단된 환경에서는 루트 저장소가 장기간 정체될 수 있다. 보안 기준 때문에 차단한 조직도 있으므로, 원복 전에는 내부 정책과 충돌 여부를 검토해야 하는 것이다.
로컬 정책에서 다음 항목이 “사용”으로 되어 있으면 자동 루트 갱신이 꺼질 수 있다.
gpedit.msc 컴퓨터 구성 → 관리 템플릿 → 시스템 → 인터넷 통신 관리 → 인터넷 통신 설정 “자동 루트 인증서 업데이트 끄기”주의 : 보안 장비(프록시/SSL 검사)가 사내 루트를 강제로 배포하는 환경에서는, 자동 루트 갱신을 무조건 켜는 것이 정답이 아닐 수 있다. 사내 표준 배포 방식(GPO/MDM/패키지)을 우선 적용하는 것이 안전하다.
3) Windows Update 기반으로 신뢰 루트 저장소를 갱신하는 실무 명령이다
오프라인/제한망에서도 활용이 쉬운 방식은 Windows Update에서 신뢰 루트 목록을 SST로 생성한 뒤 로컬 저장소에 추가하는 방법이다. 인터넷이 가능한 PC에서 SST를 만들고 제한망으로 옮기는 운영도 가능한 것이다.
certutil -generateSSTFromWU roots.sst certutil -addstore -f root roots.sst중간 인증서(Intermediate) 문제로 보이면 CA 저장소도 함께 확인하는 것이 실무적이다.
certmgr.msc 신뢰할 수 있는 루트 인증 기관(Root) 중간 인증 기관(CA)4) 문제의 인증서 체인을 눈으로 확인하고 “어디서 끊기는지”를 잡는 방법이다
파일(서명된 EXE/MSI/CAT)을 대상으로 검증하면, 신뢰가 끊기는 지점이 루트인지 중간인지 구분이 쉬워진다. 운영에서는 GUI보다 명령이 일관성이 높다.
signtool verify /pa /v "C:\path\app.exe"인증서 파일 자체(P7B/CER)를 점검하는 경우에는 다음이 유용하다.
certutil -verify "C:\path\cert.cer"4. 코드 서명에서 “만료”처럼 보이지만 실제 원인이 다른 경우
1) 타임스탬프가 없으면 서명 인증서 만료 후 신뢰가 깨질 수 있다
코드 서명은 일반적으로 “서명 시점”을 타임스탬프로 남겨두면, 서명 인증서가 나중에 만료되어도 당시 유효한 서명으로 인정될 수 있다. 반대로 타임스탬프가 없으면 배포 후 일정 시점에 갑자기 실행 경고가 늘어날 수 있는 것이다.
검증 결과에서 “Timestamp” 관련 정보가 비어 있거나, 타임스탬프 서버 체인이 깨져 있으면 루트 갱신만으로는 해결되지 않을 수 있다.
signtool verify /pa /all /v "C:\path\app.exe"주의 : 배포물 재서명이 가능한 환경이라면, 원인 복구 후 “타임스탬프 포함 재서명”이 재발 방지에 가장 효과적이다.
2) SHA-1, 구형 OS, 구형 암호 정책 문제를 같이 점검해야 한다
오래된 OS나 레거시 장비는 최신 체인이나 알고리즘을 제대로 처리하지 못해 “루트 만료”처럼 보일 수 있다. 특히 구형 Windows/임베디드/장비형 OS는 신뢰 저장소 갱신 경로가 제한되는 경우가 흔한 것이다.
5. 서버 환경에서 자주 발생하는 원인과 해결(Windows Server 포함)
1) 신규 설치 서버에서 루트가 비어 보이는 현상은 “주문형 설치”일 수 있다
일부 Windows Server는 초기 상태에서 모든 루트가 목록에 보이지 않고, 접속/검증 과정에서 필요한 루트를 내려받아 채우는 형태로 동작할 수 있다. 그런데 방화벽, WSUS 정책, 인터넷 통신 제한으로 이 동작이 실패하면 루트가 영구히 비어 보이는 것이다.
2) WSUS/프록시 환경에서는 “루트 갱신 트래픽”이 허용되어야 한다
루트 갱신은 Windows Update 계열 통신을 필요로 할 수 있으므로, 보안 정책상 완전 차단된 서버는 수동 배포 체계를 마련해야 한다. 운영 표준은 “인터넷 가능 관리 단말에서 SST 생성 → 내부 배포”가 되는 것이다.
3) 내부 PKI(사내 CA)와 충돌하는 케이스를 분리해야 한다
사내 프록시가 SSL을 가로채는 구성에서는, 외부 사이트 인증서 대신 사내 루트로 재서명된 인증서가 내려오므로 사내 루트가 각 단말의 신뢰 저장소에 없으면 전면 장애가 된다. 이 경우는 ‘외부 루트 갱신’이 아니라 ‘사내 루트 배포 누락’이 원인인 것이다.
6. Linux에서 CA 번들 갱신으로 해결하는 방법(apt/yum 공통)
1) Debian/Ubuntu 계열
sudo apt-get update sudo apt-get install --reinstall -y ca-certificates sudo update-ca-certificates2) RHEL/CentOS/Rocky/Alma 계열
sudo yum update -y ca-certificates sudo update-ca-trust3) 컨테이너/경량 이미지에서 자주 놓치는 포인트이다
컨테이너 이미지는 CA 번들이 매우 오래된 상태로 고정되어 있는 경우가 흔하다. 애플리케이션만 업데이트하고 베이스 이미지를 갱신하지 않으면 특정 날짜를 기점으로 동시다발 장애가 날 수 있는 구조인 것이다.
주의 : 운영 컨테이너는 “베이스 이미지 주기적 리빌드 + ca-certificates 갱신”을 릴리스 체크리스트에 포함해야 한다.
7. Java(JRE)에서 PKIX 실패를 확실히 잡는 방법
1) OS 신뢰 저장소와 Java cacerts는 별개일 수 있다
Java는 자체 신뢰 저장소(cacerts)를 사용하므로 OS를 업데이트해도 Java 오류가 남을 수 있다. 특히 오래된 JRE를 장기간 유지한 서버에서 빈발하는 것이다.
2) cacerts 위치 확인 후 갱신 또는 사내 루트 import가 필요하다
JRE 버전과 배포 방식에 따라 경로가 다르므로, 현재 실행 중인 Java가 참조하는 cacerts를 먼저 확정하는 것이 우선이다.
java -XshowSettings:properties -version사내 루트를 추가해야 하는 경우 keytool을 사용한다.
keytool -importcert -alias corp-root -file corp-root.cer -keystore "%JAVA_HOME%\lib\security\cacerts" -storepass changeit주의 : 운영 환경에서 cacerts를 직접 수정하면 배포/패치 시 원복될 수 있다. 사내 표준 배포 절차(패키지/구성관리/이미지 빌드)에 포함시키는 것이 재발 방지에 유리하다.
8. 재발 방지 운영 체크리스트
| 항목 | 권장 기준 | 점검 주기 | 비고 |
|---|---|---|---|
| 시스템 시간/동기화 | NTP 동기화 정상, 오차 최소화 | 상시/월 1회 점검 | 가상화/배터리 이슈 확인 |
| 루트 저장소 갱신 경로 | 자동 갱신 또는 표준 수동 배포 체계 확보 | 분기 1회 | 정책(GPO/MDM/WSUS) 포함 |
| 보안 장비(프록시/SSL 검사) | 사내 루트 배포 누락 없음 | 변경 시 | 신규 단말/VDI 즉시 적용 |
| 컨테이너 베이스 이미지 | 정기 리빌드 및 ca-certificates 최신화 | 월 1회 또는 릴리스마다 | 레지스트리 정책과 연동 |
| 코드 서명 정책 | 타임스탬프 포함 서명 표준화 | 릴리스마다 | 서명 검증 자동화 권장 |
| Java 런타임 | LTS 버전 유지, cacerts 갱신 체계화 | 분기 1회 | 레거시 JRE 고정 금지 |
FAQ
루트 인증서를 “삭제”하는 것이 안전한 해결인가?
무작정 삭제는 권장되지 않는다. 만료된 루트가 단순히 목록에 남아 있는 것만으로 즉시 문제가 되지 않는 경우도 있으며, 특정 체인 구성에서 예기치 않은 영향을 줄 수 있다. 원칙은 “신뢰 저장소를 최신 상태로 갱신”하고, 체인 선택 오류나 충돌이 확인된 경우에만 제한적으로 정리하는 방식이 안전하다.
Windows 업데이트가 불가능한 제한망에서는 어떻게 처리하는가?
인터넷이 되는 관리 단말에서 SST를 생성한 뒤( certutil -generateSSTFromWU ), 제한망 서버/PC로 파일을 이관하여 로컬 루트 저장소에 추가하는 방식이 실무적으로 안정적이다. 조직 표준 배포(GPO/배포툴/이미지)에 포함하면 반복 작업을 줄일 수 있다.
특정 사이트만 접속이 안 되고 다른 사이트는 정상인 이유는 무엇인가?
해당 사이트가 사용하는 인증서 체인이 특정 루트/중간에 의존하는데, 클라이언트 신뢰 저장소에 그 경로가 없거나 오래된 경우에 그렇게 보일 수 있다. 또한 프록시/SSL 검사 장비가 예외 도메인만 다르게 처리해 체인이 달라지는 경우도 있다. 브라우저에서 인증서 체인을 열어 “어디서 끊기는지”를 확인하는 것이 빠르다.
코드 서명 검증 실패가 특정 날짜 이후로 급증하는데 루트 갱신만 하면 되는가?
루트 갱신으로 해결되는 경우가 많지만, 타임스탬프가 없는 서명이라면 인증서 만료 시점 이후 신뢰가 깨질 수 있다. 이 경우는 루트 갱신과 별개로 “타임스탬프 포함 재서명”이 근본 대책이 된다.
Java에서만 PKIX 오류가 나고 OS/브라우저는 정상인 경우는 무엇을 봐야 하는가?
Java의 cacerts가 OS와 별도로 오래된 경우가 대표 원인이다. Java가 참조하는 cacerts 경로를 확정한 뒤, JRE를 최신으로 올리거나 필요한 루트(사내 루트 포함)를 cacerts에 반영해야 한다.