이 글의 목적은 루트 인증서 만료로 인해 발생하는 서명 검증 실패를 원인별로 진단하고, 운영체제와 환경별로 재현 가능한 해결 절차를 제공하여 업무 중단을 최소화하는 데 있다.
1. 루트 인증서 만료가 “서명 검증 실패”로 이어지는 구조
디지털 서명 검증은 “서명된 객체(파일, 드라이버, 업데이트 패키지, 스크립트, TLS 통신)”가 신뢰할 수 있는 인증서 체인으로 연결되는지 확인하는 과정이다.
일반적으로 서명 인증서(End-Entity)와 중간 인증서(Intermediate), 루트 인증서(Root)로 체인이 구성되며, 클라이언트 장비는 로컬의 신뢰 저장소에 있는 루트 인증서를 기준으로 신뢰 여부를 결정한다.
루트 인증서가 만료되거나, 해당 루트가 더 이상 신뢰 저장소에 없거나, 중간 인증서가 바뀌었는데 클라이언트가 오래되어 새 체인을 구축하지 못하면 서명 검증이 실패하는 구조이다.
1-1. 자주 나타나는 증상
| 증상 | 대표 메시지 예시 | 의미 | 우선 점검 |
|---|---|---|---|
| 실행 파일 서명 검증 실패 | Signature verification failed, A certificate chain could not be built | 신뢰 체인 구성 실패 또는 루트 신뢰 부족이다. | 시스템 시간, 루트 저장소, 중간 인증서이다. |
| 드라이버/커널 모듈 설치 실패 | Windows cannot verify the digital signature, module verification failed | 코드 서명 검증이 실패하여 로딩이 차단되는 상황이다. | 신뢰 루트 업데이트, 정책, 타임스탬프이다. |
| 패키지 매니저 업데이트 실패 | certificate verify failed, x509: certificate has expired or is not yet valid | HTTPS 또는 저장소 서명 검증이 실패하는 상황이다. | ca-certificates/CA 번들, 시스템 시간이다. |
| TLS 통신 연결 실패 | SSL certificate problem: certificate has expired | 서버 인증서가 아니라 “클라이언트 신뢰 루트” 문제일 수 있다. | 클라이언트 루트/중간 인증서, 체인 선택이다. |
1-2. “루트 만료”처럼 보이지만 실제 원인이 다른 경우
실무에서는 루트 만료로 보이는 오류의 상당수가 시간 불일치, 프록시/보안장비의 SSL 가로채기, 내부 사설 CA 배포 누락, 손상된 CA 번들 파일 권한 문제로 발생하기도 하다.
따라서 해결 절차는 “시간 확인 → 체인 확인 → 신뢰 저장소 갱신 → 애플리케이션별 신뢰 저장소 점검” 순서로 진행하는 것이 안전하다.
주의 : 오류를 우회하려고 “서명 검증 비활성화”, “TLS 검증 끄기”, “무작정 신뢰 추가”를 적용하면 악성 코드 실행과 중간자 공격에 노출될 수 있다. 운영 환경에서는 우회가 아니라 신뢰 저장소 정상화와 체인 정리를 우선해야 한다.
2. 공통 진단 절차(운영체제 무관)
2-1. 시스템 시간과 표준 시간 동기화 확인
인증서 검증은 유효 기간을 절대적으로 사용하므로 시스템 시간이 틀리면 “만료됨” 또는 “아직 유효하지 않음”으로 즉시 실패한다.
가장 먼저 현재 시간이 표준 시간과 일치하는지 확인해야 하며, 특히 가상화 환경, 듀얼 부팅, CMOS 배터리 이슈, 도메인 시간 정책 충돌을 점검해야 한다.
2-2. “어떤 체인”이 문제인지 식별하기
오류 메시지가 “루트 만료”로 보이더라도 실제로는 중간 인증서가 교체되었거나, 서버가 오래된 체인을 우선 제공하여 클라이언트가 잘못된 경로로 체인을 구축하는 경우가 많다.
따라서 검증 실패 대상(실행 파일, 드라이버, 업데이트 패키지, HTTPS 대상)의 인증서 체인을 확인하여 “만료된 루트/중간”의 주체를 특정해야 한다.
이 단계에서 “대상이 사용하는 타임스탬프 서명” 존재 여부도 같이 확인해야 하며, 타임스탬프가 없으면 서명 시점과 관계없이 현재 시점 유효성만으로 실패할 수 있다.
2-3. 조직 환경에서 반드시 확인해야 하는 요소
사내 프록시나 보안 게이트웨이가 SSL 검사 기능으로 트래픽을 복호화하는 경우, 사내 장비가 발급한 사설 루트가 클라이언트에 배포되지 않으면 모든 HTTPS 검증이 실패한다.
또한 격리망 장비는 루트 업데이트가 누락되기 쉬우므로 “루트 목록 갱신 절차”를 운영 문서로 고정해야 한다.
3. Windows 해결 방법(서명 검증 실패, 드라이버, 설치 패키지)
3-1. 증상별 우선 처방
Windows에서 루트 인증서 신뢰는 기본적으로 시스템 저장소에서 이루어지며, 일반적인 인터넷 연결 환경에서는 Windows Update를 통해 신뢰 루트가 갱신되는 구조이다.
따라서 가장 먼저 Windows Update가 정상 동작하는지 확인하고, 업데이트가 차단된 환경이면 오프라인 루트 갱신 절차를 적용해야 한다.
3-2. PowerShell로 서명 상태 빠르게 확인
# 1) 파일 서명 상태 확인이다. # 경로는 실제 파일로 변경해야 한다. Get-AuthenticodeSignature -FilePath "C:\Path\app.exe" | Format-List
2) 서명 체인, 상태 코드, 타임스탬프 유무를 함께 확인하는 방식이다.
$sig = Get-AuthenticodeSignature -FilePath "C:\Path\app.exe"
$sig.Status
$sig.StatusMessage
$sig.SignerCertificate | Format-List Subject,Issuer,NotBefore,NotAfter,Thumbprint3-3. Windows Update 기반으로 루트 갱신하기
일반 사무 환경에서는 Windows Update를 최신 상태로 맞추는 것이 가장 빠른 해결이다.
특히 오래된 Windows 빌드에서 루트 저장소가 장기간 업데이트되지 않으면 새로운 공개 CA 체인에서 실패가 증가한다.
3-4. 격리망·오프라인 환경에서 루트 갱신하기(roots.sst 활용)
인터넷이 차단된 서버나 제조설비 PC에서는 루트 업데이트가 자동으로 이루어지지 않으므로, 온라인 장비에서 루트 목록 파일을 생성하여 오프라인 장비에 가져오는 방식이 실무에서 많이 사용된다.
# [온라인 장비] Windows Update 기반으로 루트 목록 파일(roots.sst)을 생성하는 방식이다. certutil -generateSSTFromWU roots.sst # roots.sst를 오프라인 장비로 이동해야 한다.# [오프라인 장비] roots.sst를 신뢰할 수 있는 루트 인증 기관 저장소로 가져오는 방식이다. # 관리자 권한 CMD에서 실행해야 한다. certutil -addstore -f root roots.sst주의 : 오프라인 장비에 루트를 추가할 때는 파일의 출처와 무결성을 내부 절차로 보장해야 한다. 임의 출처의 루트 파일을 가져오면 신뢰 기반이 붕괴될 수 있다.
3-5. 도메인 환경에서 표준 배포하기(GPO)
다수 PC에서 같은 오류가 반복되면 개별 수동 조치 대신 그룹 정책으로 루트 또는 사설 CA를 배포하는 것이 운영 효율이 높다.
특히 사내 프록시가 SSL 검사를 수행한다면, 해당 장비의 사설 루트를 “신뢰할 수 있는 루트 인증 기관”에 일괄 배포해야 한다.
3-6. Windows에서 자주 놓치는 원인
첫째, TLS 통신은 브라우저가 최신이어도 OS 루트 저장소가 오래되면 실패할 수 있다.
둘째, 일부 보안 제품이 루트 저장소 변경을 차단하거나, 인증서 저장소 접근을 후킹하여 오류를 만들 수 있다.
셋째, 시스템 시간이 정상처럼 보여도 도메인 동기화가 미세하게 어긋나거나, 시간대 설정이 잘못되어 유효 기간 판단이 틀릴 수 있다.
4. macOS 해결 방법(앱 설치, 개발 도구, HTTPS 검증 실패)
4-1. macOS의 신뢰 저장소 특성
macOS는 키체인 기반으로 신뢰 루트를 관리하며, 일반적으로 시스템 업데이트를 통해 루트 신뢰가 갱신되는 구조이다.
구형 macOS는 최신 루트 갱신이 제한될 수 있으며, 이 경우 최신 CA 체인을 사용하는 서비스에서 오류가 늘어날 수 있다.
4-2. 시스템 업데이트로 신뢰 루트 갱신하기
# 소프트웨어 업데이트 확인 방식이다. softwareupdate -l
업데이트 적용 방식이다.
환경에 따라 재부팅이 필요할 수 있다.
sudo softwareupdate -ia4-3. 키체인에서 만료/충돌 요소 점검하기
키체인 접근 도구에서 “System”과 “System Roots” 위치에 있는 인증서를 확인하여 만료된 동일 주체 인증서가 중복되어 있거나, 신뢰 설정이 비정상으로 변경되어 있는지 점검해야 한다.
기업 환경에서 MDM으로 루트 신뢰를 강제하는 경우, 로컬 수동 변경이 정책에 의해 다시 덮어써질 수 있으므로 정책 측 조치가 우선이다.
주의 : macOS에서 “System Roots” 영역은 임의로 수정하려고 하면 실패하거나 예상치 못한 보안 부작용이 발생할 수 있다. 운영 환경에서는 OS 업데이트 또는 관리 정책을 통한 정상 갱신이 우선이다.
5. Linux 해결 방법(apt, yum/dnf, curl, git, 컨테이너 환경)
5-1. Debian/Ubuntu 계열(apt) CA 번들 갱신
Debian/Ubuntu는 보통 ca-certificates 패키지와 /etc/ssl/certs 번들을 사용하며, 이 번들이 오래되면 HTTPS 및 패키지 다운로드가 실패한다.
# 패키지 목록과 CA 패키지 갱신 방식이다. sudo apt-get update sudo apt-get install --reinstall ca-certificates
CA 링크/번들을 재구성하는 방식이다.
sudo update-ca-certificates5-2. RHEL/CentOS/Fedora 계열(update-ca-trust) 갱신
RHEL 계열은 update-ca-trust 또는 p11-kit 기반 신뢰 데이터베이스를 사용한다.
# CA 신뢰 DB를 재구성하는 방식이다. sudo update-ca-trust5-3. 내부 사설 CA를 시스템에 추가하는 표준 절차
사내 프록시, 사설 저장소, 사내 Git 서버를 사용할 때 사설 CA를 시스템 신뢰에 추가해야 정상 동작한다.
# Debian/Ubuntu 계열에서 사설 CA를 추가하는 예시이다. # 1) PEM 형식 인증서를 .crt로 저장해야 한다. sudo cp company-root-ca.crt /usr/local/share/ca-certificates/company-root-ca.crt # 2) 신뢰 번들을 갱신해야 한다. sudo update-ca-certificates# RHEL 계열에서 사설 CA를 추가하는 예시이다. sudo cp company-root-ca.crt /etc/pki/ca-trust/source/anchors/company-root-ca.crt sudo chmod 644 /etc/pki/ca-trust/source/anchors/company-root-ca.crt sudo update-ca-trust5-4. CA 번들이 “있는데도” 실패하는 특수 케이스
첫째, /etc/ssl/certs 또는 ca-certificates.crt의 권한이 비정상인 경우 TLS 라이브러리가 번들을 읽지 못해 실패할 수 있다.
둘째, 컨테이너 이미지는 CA 번들이 매우 오래된 상태로 배포되는 경우가 있어 이미지 리빌드나 패키지 갱신이 필요하다.
셋째, 애플리케이션이 시스템 CA가 아니라 자체 번들을 내장한 경우가 있어 애플리케이션별 갱신이 필요하다.
6. 애플리케이션별 신뢰 저장소 점검(운영체제 업데이트로 안 끝나는 경우)
6-1. Java(JRE/JDK) cacerts 갱신
Java는 운영체제 저장소와 별개로 JRE/JDK의 cacerts를 사용하도록 구성된 경우가 많다.
운영체제 루트를 갱신해도 Java 애플리케이션이 계속 실패한다면 Java 런타임을 최신으로 교체하는 것이 가장 안정적인 해결이다.
# cacerts 위치는 배포판과 설치 방식에 따라 다르며, 아래는 대표적인 keytool 조회 예시이다. # 실제 경로는 JAVA_HOME에 맞게 변경해야 한다. keytool -list -keystore "%JAVA_HOME%\lib\security\cacerts" -storepass changeit주의 : cacerts에 수동으로 루트를 추가하는 방식은 운영 표준화가 어렵고, 추후 만료나 교체 시 관리 부담이 커진다. 가능하면 공식 배포판 업데이트로 해결하는 것이 바람직하다.
6-2. Git과 curl의 CA 파일 경로 문제
Git, curl은 시스템 기본 번들을 쓰기도 하지만, 설정으로 별도 CA 파일을 지정한 경우 그 파일이 오래되어 실패하는 사례가 많다.
# Git이 별도 CA 파일을 강제하는지 확인하는 방식이다. git config --system --get http.sslCAInfo git config --global --get http.sslCAInfo
curl이 참조하는 CA 번들을 확인하는 방식이다.
curl -v https://example.com 2>&1 | findstr /i "CAfile"6-3. Node.js 및 Electron 앱(내장 CA 번들 이슈)
Electron 기반 앱이나 Node.js는 버전에 따라 시스템 저장소 대신 내장 번들을 사용하거나, 특정 체인 처리 방식이 달라 검증 실패가 지속될 수 있다.
이 경우 앱 업데이트 또는 런타임 업데이트가 정석이며, 기업 환경에서는 표준 버전 정책이 필요하다.
6-4. 서버 운영자가 같이 점검해야 하는 요소(체인 제공 방식)
클라이언트가 오래된 경우, 서버가 제공하는 인증서 체인 선택이 실패를 유발할 수 있다.
예를 들어 일부 CA는 동일한 서버 인증서가 서로 다른 루트 경로로 이어질 수 있으며, 서버가 오래된 루트로 연결되는 체인을 우선 제공하면 구형 클라이언트에서 “만료된 루트”로 잘못 연결되어 실패할 수 있다.
이 경우 서버 측에서 “신규 루트로 연결되는 체인”을 우선 제공하도록 설정하거나, ACME 클라이언트에서 체인 선택 옵션을 조정하는 방식이 필요하다.
7. 재발 방지 운영 체크리스트
7-1. 업데이트 및 모니터링 기준 수립
루트 신뢰 문제는 특정 날짜에 갑자기 폭발하는 경향이 있으므로, 운영 장비의 OS 업데이트 정책과 CA 번들 업데이트 정책을 분리하여 명문화하는 것이 중요하다.
특히 격리망 장비는 “정기 루트 갱신”을 유지보수 항목에 포함해야 하며, 장비 반입 시점 루트 상태를 그대로 두면 몇 년 뒤 대규모 장애로 이어질 수 있다.
7-2. 표준 점검표
| 점검 항목 | 권장 주기 | 점검 방법 | 비고 |
|---|---|---|---|
| 시스템 시간 동기화 | 매일 | NTP 동기화 상태 확인 및 표준 시간대 확인이다. | 가상화/도메인 환경에서 중요하다. |
| Windows 루트 갱신 상태 | 매월 | Windows Update 정책 확인 또는 roots.sst 절차 이행이다. | 격리망 장비는 수동 절차가 필요하다. |
| Linux CA 번들 최신화 | 매월 | ca-certificates 업데이트 및 재구성 실행이다. | 컨테이너 이미지는 별도 점검이 필요하다. |
| Java/Node 런타임 버전 | 분기 | 표준 런타임 버전 점검 및 취약/구버전 교체이다. | 앱 내장 번들 사용 여부 확인이 중요하다. |
| 사설 CA 배포(GPO/MDM) | 변경 시 | 프록시/보안장비 변경 시 루트 배포 동기화 확인이다. | 배포 누락 시 전체 서비스 장애로 이어진다. |
FAQ
루트 인증서가 만료되었는데 서버 인증서는 아직 유효하다고 나오는 이유는 무엇인가?
서버 인증서의 만료일이 남아 있어도, 클라이언트가 신뢰 체인을 구축할 때 연결되는 루트가 만료되면 검증이 실패할 수 있다. 서버 인증서는 “서명 대상”이고, 루트는 “신뢰 기준”이므로 만료 판단이 서로 다른 위치에서 발생하는 구조이다.
오류가 특정 PC에서만 발생하는 이유는 무엇인가?
같은 네트워크라도 PC마다 OS 빌드, 업데이트 적용 상태, 보안 제품, 애플리케이션 버전, 자체 번들 사용 여부가 다르기 때문이다. 특히 격리망 PC는 루트 갱신이 누락되는 경우가 많아 동일 업무에서 특정 장비만 실패하는 패턴이 자주 나타난다.
임시로 “검증 끄기”를 해도 되는가?
테스트 환경에서 원인 분리를 위해 제한적으로 사용할 수는 있지만, 운영 환경에서는 권장되지 않는다. 검증을 끄면 악성 코드 실행, 업데이트 변조, 자격 증명 탈취 같은 위험이 현실화될 수 있으므로, 신뢰 저장소 정상화로 복구하는 것이 원칙이다.
격리망에서 가장 안전하게 해결하는 표준 절차는 무엇인가?
온라인 검증된 관리 PC에서 roots.sst를 생성하고, 내부 반입 절차로 무결성을 확인한 뒤, 오프라인 장비에 관리자 권한으로 루트 저장소에 추가하는 방식이 실무 표준으로 쓰인다. 동시에 OS 업데이트 정책과 루트 갱신 주기를 운영 문서로 고정해야 재발을 줄일 수 있다.
Linux에서 ca-certificates를 업데이트했는데도 계속 실패하면 무엇을 봐야 하는가?
애플리케이션이 시스템 번들이 아니라 자체 번들을 참조하는지 확인해야 한다. 또한 /etc/ssl/certs 및 번들 파일 권한 문제, 프록시 SSL 검사로 인한 사설 CA 누락, 컨테이너 이미지의 구버전 번들이 원인일 수 있으므로 런타임과 실행 환경을 함께 점검해야 한다.