eMudhra 인증서 사고: 브라우저 차단 뒤에도 앱 점검이 필요한 이유

먼저 나누어야 할 두 가지 작업

이번 사고를 대응하는 팀에는 서로 다른 질문이 있다. 외부 HTTPS 서버에 연결하는 앱은 어떤 인증기관을 계속 신뢰하는지 확인해야 한다. HTTPS를 제공하는 서버는 현재 인증서가 앞으로도 클라이언트의 신뢰 경로를 만들 수 있는지 확인해야 한다. 브라우저를 업데이트하는 일 하나로 두 질문이 모두 닫히지는 않는다.

2026년 10월 20일 Mozilla와 Google은 eMudhra 중간 인증기관 8개의 개인키가 손상된 사건에 대한 대응을 공개했다. Google은 키 생성에 충분한 무작위성이 없었다고 설명한다. 공격자는 그 키로 자신이 소유하지 않은 사이트의 인증서를 위조할 수 있다. 실제 연결을 가로채는 등의 조건도 필요하므로, 이 사실만으로 모든 과거 HTTPS 통신이 유출됐다고 결론 내릴 수는 없다. Mozilla 사고 공지, Google 사고 공지

10월 25일 확인한 Google 공지는 10월 27일 오전 PDT에 Chrome Root Store를 사용하는 기기로 emSign ECC Root CA - G3 제거가 배포될 예정이라고 적는다. 한국시간으로는 27일 밤부터 28일 새벽에 걸칠 수 있는 표현이며, 정확한 완료 시각을 제시한 것은 아니다. 일부 정당한 인증서도 연결 실패를 겪을 수 있어, 해당 루트로 이어지는 서버는 다른 신뢰 계층의 새 인증서를 받아 설치하라는 안내다. 이 글의 확인 시점에는 예정이며 배포 완료로 기록하지 않는다. 제거 일정과 서버 운영자 조치

이 글은 공식 대응을 바탕으로 한 분석과 자체 시험용 인증서의 로컬 대조를 함께 사용한다. 실제 eMudhra 인증서·키를 사용하지 않았고, 독자의 브라우저나 서버가 안전한지 검사한 결과도 아니다.

HTTPS는 무엇을 믿고 연결하는가

웹 서버의 인증서는 서버 이름과 공개키 등을 담고, 인증기관이 그 내용을 서명한다. 클라이언트는 그 서명을 따라 중간 인증기관을 거쳐 자신이 신뢰하도록 설정된 지점에 도달하는지 확인한다. 흔한 구성에서는 그 끝에 루트 인증기관이 있다. 인증서의 유효기간, 용도, 제약과 폐기 상태 등도 판단에 들어간다. RFC 5280의 인증 경로와 폐기

여기서 중간 인증기관은 단순한 전달 서버가 아니다. 다른 인증서를 발급할 수 있는 권한을 가진 서명자다. 그 개인키가 노출되면 공격자가 만든 인증서도 수학적으로 올바른 서명을 가질 수 있다. 서명이 맞는다는 검사와 그 서명자를 지금도 믿어야 한다는 판단이 분리되는 이유다.

예를 들어 거래처 도메인의 인증서를 확인할 때, 도메인 이름이 맞고 기간이 남아 있다는 것만으로 충분하지 않다. 서명자가 더 이상 신뢰할 수 없는 기관이라면 그 경로를 거절해야 한다. 반대로 루트를 신뢰 목록에서 제거하면, 그 루트로만 검증되던 정상 서버의 인증서도 신뢰 경로를 잃을 수 있다. 사고 대응에는 위조 경로를 막는 일과 정상 서비스의 인증서를 이전하는 일이 함께 생긴다.

브라우저는 무엇을 바꿨고, 앱에는 무엇이 남는가

Mozilla는 Firefox의 중앙 폐기 목록인 OneCRL로 해당 인증서를 차단했다고 밝혔다. 표준 설정을 사용하는 Firefox에는 브라우저 업데이트나 재시작 없이 보호가 전달됐다는 설명이다. 별도 설정 때문에 목록을 받지 못한 사용자를 위한 Firefox 릴리스와, OneCRL을 받지 않는 다른 앱을 위한 NSS 루트 목록 변경도 구분했다. Mozilla의 배포 경로 설명

여기에는 후속 정정이 있다. 10월 21일 추가 내용은 Android용 Firefox 158.0.2에서, 일부 클라이언트가 시작 직후 내장 OneCRL 변경을 적용하지 않던 문제를 고쳤다고 적는다. 따라서 20일 공지의 158.0.1만 보고 Android 조치를 끝냈다고 판단하면 최신 수정 내용을 놓친다. 이 버전은 이번 사건의 수정 이력이며, 이후에도 계속 최신 버전이라는 뜻은 아니다. 같은 공지의 10월 21일 추가 내용

Chrome은 CRLSet에서 문제 중간 인증기관의 SPKI(Subject Public Key Info) 해시를 차단했다. SPKI는 공개키와 그 알고리즘 정보를 담는 부분이다. 인증서 파일 전체가 달라도 같은 공개키를 쓰면 이 식별자로 함께 차단할 수 있다. 이어서 CRLSet을 받지 않는 다른 소비자를 위한 루트 제거를 따로 추진했다. Chrome의 키 단위 차단과 루트 제거

이 차이를 제품 이름보다 무엇을 갱신하는가로 정리하면 다음과 같다.

갱신 대상	바꾸는 판단	그것만으로 알 수 없는 것
브라우저의 긴급 차단 목록	특정 인증서·키를 포함한 경로의 허용 여부	다른 프로그램이 같은 목록을 받았는가
앱의 루트 인증서 목록	경로의 끝에서 신뢰하는 기관	검증기가 별도 차단·폐기 정책을 적용하는가
인증서 검증기	경로 검사와 특정 키의 거절 규칙	새 코드로 앱을 다시 빌드·배포했는가
서버가 제공하는 인증서 체인	클라이언트가 구성할 수 있는 경로	모든 클라이언트가 그 경로를 신뢰하는가

위 표는 공식 구성요소를 운영 판단으로 연결한 분석이다. 같은 PC에 있다는 이유로 모든 프로그램이 브라우저의 신뢰 판단을 공유하지는 않는다.

루트 하나를 빼면 같은 키의 경로가 모두 사라질까

루트 A와 루트 B가 같은 중간 인증기관의 공개키를 각각 인증할 수 있다. 이를 교차 서명 상황으로 생각해 보자. 중간 인증기관의 키는 같지만, 누가 서명했는지에 따라 서로 다른 인증서가 된다. 클라이언트가 B를 여전히 신뢰하고 B 쪽 인증서로 경로를 만들 수 있다면, A가 목록에 없다는 것만으로 그 중간키의 사용이 모두 차단되었다고 말할 수 없다.

원리를 설명하려고 직접 그린 가상 구조다. 실제 eMudhra 계층 전체를 그린 도표나 브라우저 화면이 아니다.

이 때문에 루트 제거와 중간키 차단은 적용 범위가 다른 수단이다. 특정 중간키를 경로 안에서 거절하는 정책은 그 키를 공유하는 인증서에 대응할 수 있다. 루트 제거는 해당 신뢰점에 기대는 다른 경로까지 영향을 줄 수 있다. 어느 하나가 늘 더 좋다는 순위보다, 공급자가 이번 사건에 어떤 조합을 적용했는지 확인하는 편이 정확하다.

반대 조건도 있다. 교차 서명이 없거나, B가 이미 신뢰되지 않거나, 경로 제약에 맞지 않는다면 B 쪽 경로는 성립하지 않는다. 실제 클라이언트의 경로 구성 방식도 다를 수 있다. 아래 실험은 각 경로를 명시적으로 제공하며, 프로그램이 대체 경로를 자동으로 찾아낸다는 것을 시험하지 않는다.

자체 인증서로 확인한 다섯 조건

로컬에서 루트 A·B와 중간키 하나, service.test 서버 인증서를 생성했다. A가 서명한 중간 인증서와 B가 서명한 중간 인증서는 서로 다른 인증서이면서 SPKI는 같다는 것도 확인했다. 실제 공개 인증기관의 키는 사용하지 않았으며 생성한 개인키도 파일에 저장하지 않았다.

환경은 macOS arm64, Python 3.14.5, cryptography 48.0.0, OpenSSL 4.0.3이다. 검증 시각은 2026년 10월 25일 00:00 UTC로 고정했다. 시스템 신뢰 목록을 바꾸지 않고 명시한 시험용 CA 파일만 사용했다.

조건	실제 관측	이 결과로 읽을 수 있는 것
A만 신뢰하고 A 서명의 중간 인증서 제공	OK	A 경로가 성립
B만 신뢰하고 B 서명의 중간 인증서 제공	OK	A가 없어도 같은 중간키의 B 경로가 성립
B 경로에 폐기 항목 없는 CRL과 전체 폐기 검사 적용	OK	정상 CRL 대조군에서도 경로가 통과
중간 인증서를 폐기한 CRL 파일만 제공	OK	이 명령에서는 파일 제공만으로 폐기 검사가 켜지지 않음
같은 CRL에 -crl_check_all 추가	certificate revoked, 종료 코드 2	중간 인증서 깊이 1에서 거절

CRL은 인증서 폐기 목록이다. 실험의 CRL에는 B가 발급한 중간 인증서의 일련번호를 넣었다. 이는 Chrome이나 rustls의 SPKI 차단 알고리즘을 재현한 것이 아니다. 서로 다른 수단을 같은 이름으로 부르지 않기 위해, 실험 결과와 실제 제품 공지를 구분한다.

마지막 두 행이 실무에 주는 질문은 “폐기 정보 파일이 있는가”를 넘어 그 정보가 해당 연결의 검증에 사용되는가다. OpenSSL의 -crl_check_all은 체인의 모든 인증서에 대한 CRL 검사를 요청하는 옵션이다. 이 CLI 대조를 모든 앱의 기본 동작으로 일반화해서는 안 된다. OpenSSL 4.0 검증 옵션

오프라인 인증 경로 예제 ZIP에는 자체 스크립트·설명·실행 결과를 담았다. 압축을 푼 폴더에서 다음처럼 재현할 수 있다. OpenSSL은 PATH에 있어야 하며, 아래 Python 환경 설치에는 패키지 다운로드가 필요하지만 인증서 대조 자체는 네트워크를 사용하지 않는다.

python3 -m venv .venv
.venv/bin/python -m pip install cryptography==48.0.0
.venv/bin/python check-paths.py > result.json

결과의 passed가 5이고 마지막 조건이 폐기로 거절됐는지 읽는다. 임시 폴더에는 시험용 공개 인증서·CRL만 쓰고 종료 후 정리한다. 운영 인증서를 검사하거나 OS 신뢰 설정을 바꾸는 도구가 아니다. 브라우저, rustls, CT, 온라인 TLS 연결과 실제 공격은 시험하지 않았다.

Rust 앱 사례: 신뢰 목록과 검증기가 따로 바뀐다

공식 rustls-webpki 0.103.16 릴리스는 특정 중간 인증기관의 SPKI가 든 경로를 거절하는 변경을 담는다. 한편 webpki-roots 1.0.10의 조치는 문제 루트를 신뢰 목록에서 제거하는 것이다. 이름이 비슷해도 전자는 검증 동작, 후자는 신뢰 데이터다. rustls-webpki 릴리스, RustSec의 webpki-roots 공지

webpki-roots의 해당 버전 소스는 Mozilla 루트 목록을 컴파일해 앱에 포함하는 방식이라고 설명한다. 따라서 그 목록을 사용해 빌드한 기존 실행 파일의 내용이 OS 인증서 패키지 업데이트만으로 바뀌지는 않는다. 의존성을 갱신하고 앱을 다시 빌드·배포하는 경로를 확인해야 한다. 다만 모든 Rust 앱이 이 방식을 쓰는 것은 아니다. 플랫폼의 검증기를 사용하는 구성도 있으므로 실제 사용 경로부터 확인한다. webpki-roots 1.0.10 소스 설명

RustSec 공지에는 작은 함정도 있다. webpki-roots 0.26.11은 별도 루트 목록을 담지 않고, 따로 해석된 1.x 의존성의 목록을 다시 내보내는 호환 패키지다. 이때 실제 1.x 의존성이 1.0.10 이상인지 봐야 한다. “0.26.11이 보인다”는 한 줄만으로 완료를 판정할 수 없는 이유다. 호환 패키지와 부모 의존성 조건

이 글에서는 Rust 앱을 빌드하거나 해당 수정의 동작을 재실행하지 않았다. 위 버전은 공식 수정 근거이며 모든 앱의 공통 설치 명령이 아니다. 여러 버전이 함께 들어간 의존성 트리, 실제 TLS 백엔드, 실행 중인 바이너리까지 연결해 기록해야 한다. 실행 적용 자체의 확인 절차는 PHP 패치와 실행 워커를 구분한 글에서 다른 환경의 사례로 이어 볼 수 있다.

거래처 포털을 운영한다면, 송신과 수신을 분리한다

가상의 발주 포털을 생각해 보자. 직원은 브라우저로 포털에 접속하고, 별도 배치 프로그램은 거래처 API에서 발주서를 가져온다. 포털의 서버 인증서가 제거 예정 루트로 이어진다고 가정하고, 배치 프로그램은 컴파일된 루트 목록을 쓴다고 가정한다. 실제 기업의 장애나 사용 결과가 아닌 업무 설계 사례다.

담당할 경로	우선 확보할 정보	다음 행동
직원 브라우저 → 포털	서버가 제공하는 전체 체인, 지원 대상 클라이언트	제거 예정 루트에 의존하면 새 인증서·체인을 준비하고 대상 클라이언트에서 연결 확인
배치 프로그램 → 거래처 API	실행 바이너리, TLS 검증기, 실제 루트 목록 출처	해당 공급자 수정 공지에 맞춰 의존성·신뢰 데이터를 갱신하고 수정본 배포
새로 뜨는 배치 복제본	빌드 입력과 배포 이미지의 연결	자동 확장·재시작이 옛 신뢰 목록의 실행 파일을 되살리지 않도록 확인
장애 대응	실패한 연결의 방향, 인증서 오류, 변경 전후 체인	클라이언트 신뢰 갱신 문제인지 서버 인증서 이전 문제인지 나누어 처리

첫 행에서 서버 인증서를 교체해도 배치 프로그램의 외부 신뢰 판단은 그대로일 수 있다. 둘째 행에서 배치 앱을 갱신해도 직원에게 제공하는 서버 체인이 바뀌지는 않는다. 두 작업의 완료 증거를 서로 대신 쓰지 않는 것이 핵심이다.

서버의 새 인증서는 최종 서버 인증서만이 아니라 제공하는 중간 체인까지 함께 확인한다. 인증서에 적힌 발급자 이름 한 줄은 실제 클라이언트가 구성한 경로 전체의 증거가 아니다. 중간 인증서 누락, 다른 체인 제공, 클라이언트별 신뢰 차이가 있으면 결과가 달라질 수 있다. 이는 인증 경로 구조에서 나온 운영 점검이며 모든 환경의 자동 해결책은 아니다.

연결 오류가 났다고 인증서 검증을 끄면, 앞서 제거하려던 신뢰 문제를 다시 열게 된다. 서버 쪽은 지원되는 새 체인을, 클라이언트 쪽은 공급자가 수정한 검증기·신뢰 데이터를 적용하는 방향으로 복구한다. 실제 실패 원인이 다른지 확인하려면 호스트 이름·시간·체인·오류를 함께 봐야 한다.

이번 작업의 기록은 다음처럼 두 줄로 시작할 수 있다.

수신: 서비스 호스트 / 제공 체인 / 새 인증 경로 / 대상 클라이언트 확인
송신: 앱·바이너리 / TLS 검증기 / 루트 목록 출처 / 수정본 실행 확인
남은 항목: 담당자 / 공식 공지 확인일 / 적용 예정일 / 다음 확인

부품 목록과 실제 빌드의 연결을 더 살펴보려면 SBOM·Provenance·VEX의 역할을 이어 읽을 수 있다. 다음 인증기관 변경 때 이 구분을 다시 쓰려면 글 위의 저장 기능을 이용하자. 보안 주제 모음과 RSS에서도 후속 분석을 찾을 수 있다.