광고
2026년 10월 21일, Veeam에서 eMudhra 중간 인증기관(CA) 인증서 문제에 대한 지원 안내를 공개했습니다. 이번 건은 Veeam 프로그램 자체의 취약점이나 일반적인 VBR Hotfix 문제가 아닙니다. 백업 인프라가 외부 서버의 TLS 인증서를 신뢰하는 방식에 관한 이슈입니다.
Backup Server가 Windows인지, Veeam Software Appliance인지, Linux Repository를 쓰는지에 따라 대응 위치가 달라집니다. 실제 운영에서는 VBR 한 대만 볼 게 아니라 Proxy, Repository, Gateway와 외부 스토리지 연결까지 함께 확인하는 게 좋겠습니다.
핵심 요약 — VSA/VIA는 Veeam Updater, Windows는 Disallowed CTL, Linux는 배포판의 ca-certificates 보안 업데이트가 기본 대응입니다. Kasten은 컨테이너 내부 Trust Store를 사용하므로 9.0.9 이상 업그레이드가 별도로 필요합니다.
Veeam eMudhra 인증서 이슈 — 운영 환경별 대응 경로
이번 eMudhra 인증서 이슈는 무엇인가요?
2026년 10월, eMudhra는 개인키가 복구될 수 있을 만큼 약하게 생성된 중간 CA 인증서 8개를 폐기했습니다. 공격자가 이 키를 확보하고 네트워크 통신을 가로챌 위치에 있다면, 위조된 TLS 인증서를 정상 인증서처럼 제시할 위험이 있습니다.
Veeam 구성요소는 운영체제의 인증서 신뢰 저장소를 통해 HTTPS/TLS 연결을 검사합니다. 그래서 신뢰 목록이 갱신되지 않은 시스템은 외부 Endpoint를 잘못 신뢰할 여지가 있습니다.
여기서 한 가지 구분해야 합니다. 취약한 CA 키가 발견됐다고 해서 Veeam 서버가 침해됐다는 뜻은 아닙니다. eMudhra는 공개 당시 해당 중간 CA가 최종 사용자 인증서를 발급한 기록과 사전 악용 증거를 확인하지 못했다고 설명했습니다. 다만 잠재적인 인증서 위조 경로를 제거하기 위해 Trust Store 업데이트가 필요합니다.
관련 위험이 있는 연결은 다음과 같습니다.
Object Storage Repository와 클라우드 스토리지 API
Microsoft 365 및 클라우드 서비스 Endpoint
Veeam License / Update Service
SMTP 및 기타 HTTPS/TLS 외부 서비스
영향 제품과 구성요소
Veeam KB4952에는 Veeam Backup & Replication 외에도 Veeam Backup for Microsoft 365, Veeam ONE, Veeam Service Provider Console, Veeam Recovery Orchestrator, Veeam Management Pack for Microsoft System Center가 영향 제품으로 안내되어 있습니다.
이 제품이 설치된 서버만 확인하면 되는 것은 아닙니다. 같은 Trust Store를 사용하는 Windows/Linux Proxy, Repository, Gateway, Backup Infrastructure 서버, 그리고 운영체제의 신뢰 저장소를 사용하는 Veeam Agent와 Enterprise Application Plug-in도 함께 살펴봐야 합니다.
구성 | 확인할 위치 | 대응 |
|---|---|---|
VSA / Veeam Infrastructure Appliance | Host Management Console | Veeam Updater 적용 |
Windows VBR·Proxy·Repository 등 | Windows Disallowed CTL | 자동 갱신 여부 확인 또는 수동 반영 |
Linux Proxy·Repository·Gateway 등 | 배포판 CA 패키지 | ca-certificates 보안 업데이트 |
Veeam Agent / Enterprise Plug-in | 설치 OS Trust Store | OS 갱신 후 추가 제품 패치 불필요 |
Kasten for Kubernetes | Kasten 컨테이너 이미지 | 9.0.9 이상 업그레이드 |
1. Veeam Software Appliance / Infrastructure Appliance
VSA와 Veeam Infrastructure Appliance는 운영체제까지 Veeam이 관리하는 Appliance 형태입니다. 이 환경은 일반 Linux 서버처럼 Trust Store 파일을 직접 수정하지 않고, Veeam Updater를 이용해 공식 업데이트를 적용합니다.
Veeam Host Management Console에 로그인합니다.
Updates → Check for updates 메뉴를 선택합니다.
제공된 업데이트를 확인합니다.
Install Updates Now를 선택해 설치합니다.
구성요소별 Custom Update Configuration을 적용했다면 해당 Appliance에서도 별도로 확인합니다.
VSA/VIA의 Trust Store를 수동으로 편집하는 방식은 권장되지 않습니다. 공식 업데이트로 차단 목록을 반영하는 것이 맞습니다.
2. Windows 기반 Veeam 서버
Windows는 2026년 10월 20일부터 문제 중간 인증서를 차단하는 업데이트를 제공하고 있습니다. 인터넷에 연결되어 있고 자동 Certificate Trust List 갱신이 정상이라면 별도 수동 작업은 필요하지 않습니다.
Disallowed CTL 갱신 시간 확인
관리자 권한 PowerShell에서 아래 명령어를 실행합니다.
certutil -verifyctl Disallowed | findstr /i "lastsynctime"LastSyncTime이 2026년 10월 20일 이후인지 확인합니다. 날짜만 확인하는 데서 끝내지 말고, 실제 운영 서버가 중앙 정책이나 보안 솔루션에 의해 자동 Root Certificate 업데이트를 차단하고 있지 않은지도 같이 보는 편이 좋습니다.
망분리·오프라인 Windows 서버
광고
인터넷 접근이 없거나 Group Policy로 자동 신뢰 목록 갱신을 막아둔 서버는 별도 반영이 필요합니다.
① 인터넷 가능한 Windows 시스템에서 관리자 권한으로 최신 CTL 파일을 내려받습니다.
certutil -syncWithWU C:\CTL② 생성된 disallowedcert.sst를 오프라인 서버로 안전하게 전달합니다. 오프라인 서버에서도 아래 예시처럼 동일한 위치에 파일이 있다고 가정합니다.
Import-Certificate -FilePath C:\CTL\disallowedcert.sst -CertStoreLocation Cert:\LocalMachine\Disallowed③ 적용 후 Veeam 서비스를 재시작하거나 서버를 재부팅합니다. 작업 전에는 백업·복구 Job 실행 시간과 서비스 재시작 영향을 확인해야 합니다.
관련 GPO 경로는 다음과 같습니다.
Computer Configuration
> Administrative Templates
> System
> Internet Communication Management
> Internet Communication settings
> Turn off Automatic Root Certificates Update3. Linux Proxy / Repository / Gateway
Linux에서는 Veeam 제품 파일을 수동 교체하는 것이 아니라 배포판에서 제공하는 CA 신뢰 저장소 보안 업데이트를 적용합니다.
Ubuntu
현재 버전과 설치된 패키지를 먼저 확인합니다.
cat /etc/os-release
dpkg -l ca-certificates 'libnss3*' | grep ^iiUbuntu 22.04 LTS와 24.04 LTS의 ca-certificates 수정 패키지 기준은 아래와 같습니다.
Ubuntu | ca-certificates 수정 버전 |
|---|---|
22.04 LTS | 20260816ubuntu0.22.04.1 |
24.04 LTS | 20260816ubuntu0.24.04.1 |
전체 운영체제 업데이트를 허용할 수 있다면:
sudo apt update
sudo apt upgrade인증서 관련 패키지만 우선 반영한다면:
sudo apt update
sudo apt install --only-upgrade ca-certificates 'libnss3*'Ubuntu 보안 안내는 CA 저장소 외에도 NSS(libnss3) 업데이트를 다루고 있습니다. Java 애플리케이션은 Java Root CA Store 동기화 문제가 별도로 있을 수 있으므로, Java를 사용하는 서버라면 Ubuntu 공식 안내의 해당 절차까지 확인하는 것이 좋습니다.
RHEL / Rocky Linux / AlmaLinux
Red Hat은 RHSB-2026-012를 통해 대응 상황을 안내하고 있습니다. 설치된 패키지 버전은 아래처럼 확인할 수 있습니다.
cat /etc/redhat-release
rpm -q ca-certificatesRed Hat의 관련 보안 업데이트 번호는 다음과 같습니다.
RHEL 10: RHSA-2026:88455
RHEL 9: RHSA-2026:88459
RHEL 8: RHSA-2026:88550
실제 적용 전에는 OS Major Version과 Repository 상태를 확인하고, 해당 배포판에서 제공하는 수정 패키지가 반영됐는지 확인합니다. Rocky Linux와 AlmaLinux 역시 각 배포판 보안 Repository 기준으로 적용 여부를 판단해야 합니다.
sudo dnf check-update ca-certificates
sudo dnf update ca-certificates위 명령은 해당 배포판에서 수정 패키지가 제공되는지 확인한 뒤 실행하는 일반적인 DNF 업데이트 예시입니다. 패키지 버전이 최신이라는 사실만으로 모든 TLS 클라이언트의 신뢰 경로가 동일하게 보호된다고 단정하지는 않습니다.
Debian
Debian은 DSA-6572-1에서 ca-certificates 업데이트를 안내했습니다. Debian 13(trixie)은 20250419+deb13u1부터 수정 사항이 반영됐습니다.
dpkg -l ca-certificates | grep ^ii
sudo apt update
sudo apt install --only-upgrade ca-certificates4. 업데이트 후 TLS 연결 오류가 발생한다면
이번 대응은 문제가 된 인증서 체인을 더 이상 신뢰하지 않도록 만드는 조치입니다. 따라서 과거에 해당 체인을 통해 정상적으로 접속하던 일부 Endpoint에서는 업데이트 후 TLS/Certificate Trust Error가 발생할 수 있습니다.
특히 emSign ECC Root CA - G3 또는 AAA Certificate Services / Comodo AAA Services 계열 Root CA에 연결된 인증서 체인을 사용하는 서비스는 주의해야 합니다.
이럴 때는 Trust Store에서 차단한 인증서를 다시 허용하기보다 연결 대상 서비스의 인증서 체인을 확인하고, 신뢰 가능한 다른 CA로 발급된 인증서로 교체하는 것이 권장 방향입니다.
운영 환경에서는 Object Storage, 외부 Cloud API, SMTP, Microsoft 365 관련 연결, License/Update Service가 정상인지 점검해두면 좋겠습니다.
5. Kasten은 Node OS 업데이트만으로 해결되지 않습니다
Kasten도 같은 eMudhra 인증서 이슈와 관련이 있지만 대응 구조는 다릅니다. Kasten 9.0.8 이하는 영향을 받을 수 있으며, Kasten 구성요소는 컨테이너 이미지 내부의 Trust Store를 사용합니다.
따라서 Kubernetes Node의 ca-certificates를 업데이트해도 Kasten 컨테이너에 들어 있는 신뢰 저장소는 변경되지 않습니다. Veeam은 Kasten 9.0.9 이상 업그레이드를 안내하고 있으며, 이전 버전에 대한 우회 조치나 컨테이너 Trust Store 수동 편집은 권장하지 않습니다.
9.0.9는 Go 기반 서비스의 Go 1.27.3과 컨테이너 신뢰 저장소 차단 목록을 반영했습니다. 구체적인 Kasten 업그레이드 및 확인 명령은 KB4954를 참고하는 것이 좋습니다.
운영 환경에서 확인할 체크리스트
Veeam eMudhra 인증서 이슈 — 적용 전·중·후 운영 점검 흐름
- ☐
VBR/Proxy/Repository/Gateway의 OS와 구성 유형을 구분했습니다.
- ☐
VSA/VIA의 Veeam Updater 적용 상태를 확인했습니다.
- ☐
Windows Disallowed CTL 갱신 시각을 확인했습니다.
- ☐
오프라인 Windows 서버의 수동 CTL 적용 여부를 확인했습니다.
- ☐
Linux 배포판별 ca-certificates 수정 패키지를 확인했습니다.
- ☐
Object Storage, Cloud API, SMTP 등 TLS 외부 연결을 점검했습니다.
- ☐
Kasten을 사용하는 경우 9.0.9 이상 여부를 별도로 확인했습니다.
- ☐
업데이트 전후 백업 및 복구 Job 상태를 확인했습니다.
정리
이번 건에서 중요한 건 VBR 패치 파일 하나를 설치하는 게 아닙니다. 외부 서비스의 TLS 인증서를 어떤 신뢰 저장소로 검사하는지부터 구분해야 합니다.
Windows 기반 Veeam 서버라면 Disallowed CTL을, Linux Proxy나 Repository라면 배포판의 인증서 패키지를, VSA라면 Veeam Updater를 확인하면 됩니다. Kasten은 컨테이너 내부 Trust Store가 별도로 움직이기 때문에 버전 업그레이드가 필요합니다.
특히 망분리 환경이나 Hardened Repository처럼 OS 업데이트가 자주 지연되는 구성은 별도 점검 목록으로 관리해두는 편이 좋겠습니다.
공식 참고자료
작성 기준: 2026년 10월 25일 · 보안 업데이트 적용 여부는 실제 제품 버전과 배포판 보안 공지 기준으로 판단해주세요.
광고





