비밀키가 몇 번만 찍어도 맞았다, 브라우저가 인증기관 8곳을 막은 이유

Chrome은 사건을 보고받은 지 1시간 40분 만에 문제의 인증기관 키를 차단 목록에 올렸고, Node.js의 수정판은 나흘 뒤인 21일에야 나왔습니다. 같은 위조 인증서를 한쪽은 막고 다른 쪽은 받아 주던 시간대가 있었다는 뜻입니다. 이 글은 그 차이를 하나의 질문으로 따라갑니다. 브라우저는 인증서를 한 장씩 찾아다니지 않고 어떻게 8곳을 한 번에, 그것도 업데이트 없이 막았을까요.

막힌 것은 TLS 인증서를 찍어 내던 중간 인증기관 8곳입니다. 인증서 발급 업체 eMudhra가 2025년 4월 30일에 만든 이 8곳의 비밀키는 모두 256보다 작은 숫자여서, 공개된 인증서만 있으면 0부터 255까지 대입해 보는 것으로 키가 나왔습니다. 이 상태가 17개월 가까이 이어졌고, 10월 17일에야 한 연구자가 발견했습니다. 이 글의 시각은 모두 UTC입니다.

막은 것은 인증서 8장이 아니라 키였다

주소창 자물쇠의 뿌리는 루트 인증기관이지만, 루트의 비밀키는 사고가 나면 모든 것이 무너지므로 평소에 꺼내 쓰지 않습니다. 실제 사이트 인증서를 찍어 내는 일은 루트가 서명해 위임한 중간 인증기관이 맡습니다. 이번에 문제가 된 층이 이 중간 단계이고, 그 키를 아는 사람은 어느 도메인의 인증서든 “내가 발급했다”는 서명을 만들 수 있습니다.

여기에 사정이 하나 더 있었습니다. 2025년 5월에 Sectigo가 8곳 모두에 교차 서명을 해 주었습니다. 교차 서명은 다른 루트에서 출발해도 같은 중간 인증기관으로 이어지는 길을 하나 더 내는 일이라, 인증서는 8장에서 16장이 됩니다. 그러나 16장 안에 든 공개 키는 8개뿐입니다.

그림 1. 점선 안이 같은 공개 키를 담은 인증서들. 초록 상자가 키 하나에 걸리는 차단이고, 노란 상자가 두 번째 벽

Chrome이 쓴 방법이 이 구조에 맞았습니다. 차단 목록(CRLSet)에 인증서가 아닌 공개 키의 해시(SPKI)를 올렸고, 그래서 같은 키를 담은 인증서는 몇 장이든, 어느 루트 밑에 있든 한 줄로 막혔습니다. Google에 따르면 이 방식은 브라우저 업데이트나 재시작도 필요하지 않았습니다. Firefox의 차단 목록(OneCRL)에도 8곳이 올랐습니다.

생성

2025년 4월 30일 키 생성 의식. 같은 의식에서 만든 중간 인증기관 24개 중 8개

용도

웹 TLS 6곳(EM DV·OV·EV TLS CA의 G3B·G3C)과 코드 서명 2곳(EM OV CS CA의 G3B·G3C, Microsoft만 신뢰)

키 종류

P-384 타원곡선 키. RSA 키는 영향이 없다고 eMudhra가 설명

실제 사용

eMudhra에 따르면 운영 환경에 올라간 것은 EM DV TLS CA - G3C 하나뿐이고, 최종 사용자 인증서는 발급한 적이 없음

교차 서명

2025년 5월 Sectigo, 인증서 항목 16개

발견

2026년 10월 17일, 생성 후 약 17개월

정수 하나를 0부터 세어 찾았다

발견은 10월 17일 16:27에 한 연구자가 공개 인증기관 데이터베이스(CCADB)의 시험 자료로 점검을 돌리다 키의 이상을 보면서 시작됐습니다. 연구자는 키가 정말 풀린다는 증거로 서명한 시험 메시지를 만들어 18:05에 Apple, Chrome, Microsoft, Mozilla와 eMudhra에 보냈습니다.

P-384 키라면 약 10의 115제곱 가지 중 하나여야 합니다. 공개 키는 비밀 정수에 기준점을 곱한 결과라서, 키가 큰 무작위 수이면 거꾸로 되짚는 것은 우주의 나이가 걸려도 불가능합니다. 이번 8개 키는 이 전제가 깨져 있었습니다. Mozilla의 분석에 따르면 키는 256보다 작은 정수였고, 48바이트 중 마지막 한 바이트에만 값이 있었습니다. 1, 2, 3 순서로 기준점에 곱해 공개 키와 같은지 비교하면 최대 256번에 끝납니다.

그림 2. 위는 Kudelski Security가 정리한 8개 값의 위치. 아래 막대에서 이 값들이 차지하는 폭은 실제로는 보이지 않을 만큼 작아서 5px로 과장해 그렸다

수직선에서 볼 것은 값 8개 전부가 정상 키 공간의 맨 끝, 점 하나나 다름없는 구간 안에 들어 있다는 사실입니다. 어느 인증서가 어느 값인지는 공개 표에 없고, 연구자 Flüpke가 GitHub에 올린 값 하나(EM OV TLS CA - G3C의 4)를 BleepingComputer가 폐기된 인증서와 맞춰 확인했습니다.

숫자를 읽을 때 구분할 것이 있습니다. “256번”은 키가 256 미만이라는 사실에서 나오는 계산상의 상한이고, “1초 미만”은 보안 연구자 Scott Helme가 공개 인증서만으로 노트북에서 키를 되찾았다고 밝힌 실측입니다. Mozilla는 보고 접수 20:06부터 1시간 42분 뒤인 21:48에 키를 독립적으로 복원했고, 다른 여러 사람도 각자 복원했으며 보고서에는 일부가 AI 에이전트의 도움을 받았다고 적혀 있습니다. 풀린 것은 P-384라는 알고리즘이 아니라 키를 만드는 과정입니다. 서명 방식 자체는 그대로입니다.

장비 안에 약한 키 한 벌이 더 생긴 경위

eMudhra의 설명(Mozilla 보고서)을 따라가면, 키를 다른 장비로 옮길 때 쓰는 포장·해제(wrap/unwrap) 단계를 시험하려고 키 생성 의식에 승인된 절차 일탈이 끼어 있었습니다. 이 시험에 쓴 스크립트에 결함이 있어서, 원래 의도한 강한 키 쌍 외에 약한 두 번째 키 쌍이 장비 안에 함께 만들어졌습니다. 이름표가 비슷해서 사람이 약한 쪽으로 인증서 발급 요청을 만들었고, 루트가 서명했고, Sectigo가 교차 서명을 얹었습니다. 24개 중 8개가 이 경로를 탔고, 장비 자체는 설계대로 동작했다는 것이 회사의 입장입니다. 영향이 없는 것으로 설명된 키는 RSA 계열과 다른 장비에서 만든 A 시리즈입니다.

회사는 이 계층이 감사를 두 차례 거치는 동안에도 발견되지 않았다고 밝혔고, 자사가 치른 모든 키 생성 의식을 다시 검증하겠다고 했습니다. “여러 단계에서 사람의 실수가 있었다”는 인정도 했습니다.

이 사건에는 사고 전의 신호도 남아 있습니다. 2025년 6월 Mozilla 추적 시스템에 eMudhra가 낸 폐기 목록(CRL)의 서명이 검증에 실패한다는 건이 올라왔고(Bug 1970728), 이는 원래 키로 서명한 목록이 검증되지 않아서 약한 쪽 키로 다시 서명하는 방식으로 해결됐다고 합니다. 약한 쌍으로 서명하면 풀리는 문제였다는 점이 지금 보면 단서였습니다. Mozilla와 Chrome은 이 건을 그렇게 푼 이유와 이번 보고서에 그 내용이 빠진 이유를 eMudhra에 묻고 있습니다. 같은 질문 목록에는 장비가 FIPS 모드로 동작했는지, RSA 키도 정말 영향이 없는지, 교차 서명을 한 Sectigo에 키가 잘못됐음을 알렸는지가 들어 있습니다.

키를 알아도 위조가 쓰이지 못한 두 번째 벽

키가 풀렸다고 곧바로 피해가 난 것은 아닙니다. 위조 인증서를 쓰려면 공격자가 사용자와 서버 사이의 경로에 끼어들어야 합니다. 공용 와이파이, 장악된 라우터, 사내 프록시가 그런 자리입니다. 그 자리에서 사용자를 가짜 서버로 데려가면 자물쇠 표시까지 정상으로 보이게 만들 수 있습니다. CDN 업체 Cloudflare는 이 문제가 TLS의 암호화가 아니라 “상대가 진짜인가”를 따지는 인증에 관한 것이라고 정리했습니다.

다만 브라우저에는 키만으로는 넘을 수 없는 벽이 하나 더 있었습니다. 인증서 투명성(CT)은 발급된 인증서를 공개 장부에 기록하게 하는 제도이고, Chrome은 장부에 기록되지 않은 공개 신뢰 인증서를 기본으로 받아 주지 않습니다. Google은 차단 전까지 문제의 TLS 중간 인증기관 6곳 아래에서 발급돼 CT에 기록된 인증서가 하나도 없었다고 밝혔습니다. 위조 인증서는 장부에 올릴 수 없고, 올리지 않으면 Chrome이 거부합니다. Google은 여기에 더해 CT 로그가 문제의 체인을 아예 거부하도록 갱신했다고 설명했습니다.

Google이 같은 글에서 덧붙인 것은 다른 루트 저장소의 키도 점검했고 같은 결함은 찾지 못했다는 것입니다.

보고 1시간 40분 뒤 Chrome, 나흘 뒤 Node.js

누가 언제 막았는지를 날짜 칸에 놓으면 반응 속도가 두 무리로 갈립니다. 아래 격자에서 색이 진한 칸이 반영된 날이고, 숫자는 17일 18:05 보고 이후 걸린 시간입니다. 시각이 공개된 것만 숫자를 적었습니다.

그림 3. 날짜별 반영 격자. 브라우저의 차단 목록은 17일, 개발 도구의 수정은 20~21일 칸에 있고 Chrome의 G3 루트 제거는 오늘(27일) 칸에 예정으로 있다

왼쪽 위의 두 칸이 가장 빠릅니다. Chrome은 보고를 받은 18:05의 1시간 40분 뒤인 19:45에 차단 목록을 냈고, Mozilla는 22:59에 Firefox의 차단 목록 반영을 마쳤습니다. 다음 날 아침 09시대에는 eMudhra가 8개 인증서를 “인증기관 키 노출” 사유로 폐기했고, 19일 14:55에는 Sectigo가 교차 서명을 폐기했습니다. Android도 19일 22시쯤 Google Play 서비스로 같은 차단을 받았습니다.

개발 도구 쪽은 한 칸씩 오른쪽에 있습니다. Python의 인증서 번들 certifi가 20일 02:24, Go의 수정이 20일, Node.js의 보안 릴리스가 21일입니다. 브라우저는 차단 목록이 자동으로 도착하고, 도구는 새 버전이 나와야 하고 그 버전을 사용자가 깔아야 합니다. 이 차이가 시간 차이의 거의 전부입니다.

그 사이에 일어난 일은 더 있습니다. Mozilla의 Dennis Jackson이 20일 개발자 정책 포럼에 사건을 공개했고, Mozilla는 같은 날 emSign ECC Root CA - G3를 신뢰 목록에서 뺐습니다(NSS 3.131.1, Firefox 158.0.1). Cloudflare는 인지한 19일 17시경부터 이어 온 대응의 서버 쪽을 20일 19:20에 마쳤습니다. Firefox Android에서는 차단 목록이 적용되지 않는 구성이 발견되어 21일에 158.0.2로 고쳤습니다. 브라우저의 자동 갱신도 구성에 따라 빠지는 곳이 있었던 것입니다. 코드 서명용 2곳은 브라우저가 쓰지 않는 인증서라 Chrome 차단 대상이 아니었고, Microsoft가 20일에 플랫폼에서 막았습니다.

같은 위조 인증서를 curl은 받아 줬다

브라우저에는 키 차단 목록과 CT라는 두 개의 확인이 있고, 서버와 개발 도구는 보통 둘 다 없습니다. 아래 그림은 같은 위조 체인이 두 종류의 클라이언트에 닿을 때의 순서입니다.

그림 4. 수정 전 상태에서 같은 위조 체인을 대하는 두 방식. 도구는 자기 안의 인증서 번들 하나만 믿는다

Scott Helme의 시험에서 Linux와 macOS의 curl, Python, Node.js는 EM DV TLS CA - G3B 아래서 만든 위조 인증서를 정상으로 받아 들였습니다. macOS에 기본 포함된 /usr/bin/curl은 /etc/ssl/cert.pem이라는 인증서 번들을 읽고, 이 파일을 갱신하지 않으면 폐기된 사슬도 통과시킵니다. 개인 연구자의 시험이고 환경에 따라 다를 수 있습니다.

Cloudflare는 두 가지를 더 안내했습니다. 고객이 직접 운영하는 서버, 상호 TLS(mTLS) 설정, 컨테이너 이미지는 고객 쪽에서 신뢰 목록을 고쳐야 한다는 것, 그리고 SDK 하나를 올리는 것만으로는 부족할 수 있다는 것입니다. SDK가 인증서 검증을 다른 HTTP 라이브러리나 런타임, OS 설정에 맡기는 경우가 많기 때문입니다. 브라우저나 curl로 시험해서 통과했다는 사실이 백그라운드로 도는 서비스의 안전을 보증하지 않으므로, 그 서비스가 실제로 쓰는 TLS 경로로 확인해야 합니다.

인증서 번들은 생각보다 여러 층에 숨어 있습니다. 한 층을 고쳐도 아래 층이 낡았다면 그 길로 샙니다.

• 운영체제 번들: /etc/ssl/cert.pem, ca-certificates 패키지. 시스템 curl이 읽는 곳입니다.
• 언어 런타임과 패키지 번들: Python certifi, Node.js에 든 루트 목록, Rust webpki-roots.
• 실행 파일 안에 굳은 목록: Go 프로그램, 단일 실행 파일, 스냅샷. 다시 빌드하기 전에는 그대로입니다.
• 컨테이너 이미지: 베이스 이미지 안의 번들. 새로 받아 다시 배포해야 반영됩니다.
• 임베디드·VPN 기기: 펌웨어에 박힌 목록. 제조사 업데이트가 있어야 반영됩니다.

도구별로 고쳐진 버전과 아직 대기 중인 곳

경로는 도구마다 다릅니다. 특히 다시 빌드하거나 재시작해야 하는 두 가지를 먼저 짚습니다.

• Go: 1.26.10과 1.27.3은 표준 라이브러리(crypto/x509)가 8곳의 키 지문이 든 체인을 거부하도록 고쳤습니다(CVE-2026-111943). 사용자가 지정한 루트 목록을 쓰는 경우에도 적용됩니다. Go는 폐기 정보를 확인하지 않으므로 이미 만들어 둔 실행 파일은 새 Go로 다시 빌드해야 고쳐지고, 1.25 이하에는 수정이 없습니다.
• Node.js: 21일 보안 릴리스(22.23.4, 24.22.1, 26.12.1)가 해당 키가 든 체인을 거부하고 번들 루트를 NSS 3.131.1로 올렸습니다. 업그레이드 전에 이미 이어진 TLS 세션은 다시 검증되지 않으므로 서비스를 재시작해야 하고, 지원이 끝난 20 이하 라인에는 수정이 없습니다.
• Python과 Rust: certifi 2026.10.19가 G3 루트를 뺐고 pip와 uv가 따라 갱신됐습니다. Rust 쪽은 rustls-webpki 0.103.16과 webpki-roots 1.0.10이 같은 대응을 담았습니다.
• Firefox: 158.0.1(CVE-2026-113470)과 ESR 153.5.1이 G3 루트를 뺀 버전입니다.

아래 표는 각 프로젝트의 릴리스와 연구자가 운영하는 커뮤니티 추적표를 맞춰 본 것으로, 26일 시점 기준입니다. 같은 줄에 두 버전이 있으면 쓰는 라인에 맞는 쪽을 고르세요.

환경	고쳐진 버전	메모
Go	1.26.10 · 1.27.3	다시 빌드해야 반영, 1.25 이하 수정 없음
Node.js	22.23.4 · 24.22.1 · 26.12.1	업그레이드 후 서비스 재시작
Python	certifi 2026.10.19, pip 26.2.2, uv 0.13.5	CPython 3.9·3.10으로 만든 가상 환경은 안에서 pip를 올려야 함
Debian	ca-certificates 20250419~deb12u2 · 20250419+deb13u1
Ubuntu	ca-certificates 20260816ubuntu0.22.04.1 이상	24.04는 0.24.04.1
Alpine	ca-certificates 20261020-r0
개발 도구	Docker Engine 29.9.2, VS Code 1.143.1, Electron 44.9.1 · 43.8.1 · 42.11.16	각자 내장한 번들을 갱신한 버전. Electron 앱(Slack, Discord 등)은 새 Electron으로 업데이트돼야 반영
Cloudflare	WARP Android 2.5.7, iOS 1.12.7, 데스크톱 2026.8.2115.0, cloudflared 2026.10.2	컨테이너는 이미지 재배포

같은 추적표에서 언어 런타임 8개와 루트 번들 12개는 전부 반영으로 표시되고 운영체제와 응용도 대부분 반영돼 있습니다. 대기 표시가 남은 곳은 RHEL 7, Bottlerocket, OpenHarmony, Godot, LibreOffice, certbot, containerd입니다. 쓰는 곳이 있다면 공급처 공지를 확인해 두세요.

내 환경에서 읽기 전용으로 확인하는 네 가지

점검은 읽기만 하는 명령으로 끝납니다. 순서는 사슬, 번들, 버전, 시험 호스트입니다.

1. 서버 인증서 사슬을 본다. 자기 도메인이 어떤 인증기관의 사슬을 내보내는지 확인합니다.
2. 신뢰 목록에서 G3 루트가 남았는지 본다. 서버와 개발 PC의 인증서 번들을 확인합니다.
3. 런타임·도구 버전을 본다. 위 표의 고쳐진 버전보다 낮으면 올립니다.
4. 시험 호스트로 직접 시험한다. 이 클라이언트가 약한 키로 만든 사슬을 받아 주는지 확인합니다.

첫째, 서버가 내보내는 사슬의 발급자를 봅니다.

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E '^ *([0-9]+ s|i):'

사슬 단계마다 주체(s:)와 발급자(i:) 줄이 한 쌍씩 나옵니다. 어느 줄에든 EM … TLS CA - G3B·G3C나 emSign ECC Root CA - G3처럼 G3가 붙은 eMudhra 이름이 보이면 교체 계획을 세워야 합니다. 8곳이 직접 서명한 사이트 인증서는 eMudhra의 설명상 없지만, G3 루트에 이어진 다른 중간 인증기관의 인증서는 Chrome에서 동작하지 않을 수 있기 때문입니다. emSign Root CA - G1 계열 이름은 Mozilla가 신뢰를 유지하고 있어 이 점검의 대상이 아닙니다.

둘째, 신뢰 목록 파일에 G3 루트가 남았는지 셉니다. macOS의 기본 curl이 읽는 파일은 /etc/ssl/cert.pem, Debian·Ubuntu 계열은 /etc/ssl/certs/ca-certificates.crt입니다.

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -c "emSign ECC Root CA - G3"

0이 나오면 이미 빠진 것입니다. 2가 나오면(주체 줄과 발급자 줄 한 쌍) 이 번들에 G3 루트가 아직 남아 있으니 번들을 갱신하세요.

셋째, 도구 버전을 확인합니다. 아래는 모두 버전만 출력합니다.

go version                # 도구가 Go라면: go version -m ./내프로그램 으로 빌드에 쓴 Go 버전 확인
node -v
python3 -c "import certifi; print(certifi.__version__)"

넷째, 연구자가 운영하는 시험 호스트에 요청 한 번을 보냅니다. 이 호스트는 CT에 기록되지 않은 인증서를 내므로, CT를 확인하지 않는 도구가 약한 키의 사슬을 받아 주는지 가려 줍니다.

curl -sS -o /dev/null -w '%{http_code}\n' https://dv-g3b-noct-emudhra.we-have-a-problem.com/

연결이 성공해 200 같은 상태 코드가 나오면 이 클라이언트가 약한 키로 만든 사슬을 받아 주는 것이니 갱신이 필요합니다. 인증서 오류(curl이라면 종료 코드 60)가 나면 거부하는 것이므로 안전합니다. 연결 실패 같은 다른 오류는 거부가 아니라 네트워크 문제일 수 있으니 종료 코드를 확인하세요. 이 시험은 curl 자신의 신뢰 목록만 확인합니다. 앱이 쓰는 HTTP 라이브러리로 같은 요청을 보내 봐야 앱 자체가 안전한지 알 수 있습니다. 사내망 정책이 외부 접속을 막는다면 이 단계는 건너뛰고 앞의 세 단계로 판단하세요.

오늘 도착하는 G3 루트 제거와 운영자의 교체

가장 시급한 쪽은 자기 사이트 인증서를 eMudhra에서 받은 운영자입니다. Google은 emSign ECC Root CA - G3를 Chrome 루트 저장소에서 빼는 변경이 27일 오전(오늘) 모든 기기에 도달한다고 예고했고, 이 루트에 이어진 합법적인 인증서도 Chrome에서 동작을 멈출 수 있다고 경고했습니다. Chrome이 뺀 이유는 차단 목록을 받지 않는 다른 루트 저장소 사용자들을 지키기 위해서입니다. 운영자가 할 일은 Chrome 루트 저장소에 든 다른 인증기관 계층에서 새 TLS 인증서를 받아 설치하는 것입니다.

eMudhra는 약 3만 건의 인증서를 옮겨야 하고 그중 97%가 자동 갱신(ACME)으로 발급됐다고 밝혔습니다. 구독자는 RSA 계열 G1 계층으로 옮기고 있고, Sectigo가 발급하는 대체 인증서도 무료로 제공한다고 안내했습니다. ACME로 갱신 중이라면 클라이언트 설정에서 발급받을 인증기관을 바꾸는 방법이 있습니다. 위 점검 첫째 단계에서 G3 이름이 나왔다면 바로 이 경우입니다.

CI 서버나 컨테이너에서 외부 서비스를 호출한다면 웹훅, 패키지 저장소, 업데이트 서버처럼 비밀값을 들고 나가는 호출이 가장 위험한 경로입니다. 베이스 이미지를 새로 받아 다시 빌드하고, Go로 만든 도구는 새 Go로 빌드된 릴리스를 받고, Node 서비스는 업그레이드 뒤 재시작합니다. Cloudflare Containers 환경이라면 HTTPS 송신 검증을 Cloudflare에 맡기는 방법도 안내됐습니다.

개인 맥에서 터미널로 스크립트를 받아 설치한다면 브라우저는 안전하지만 터미널의 curl은 다릅니다. 넷째 점검에서 200이 나오는 curl이라면, 공용 와이파이처럼 경로가 믿기 어려운 곳에서는 curl … | sh 형태의 설치를 미루세요. 업데이트가 오기 전의 응급 수단으로 연구자 사이트는 번들에서 영향받는 루트를 직접 빼는 방법을 안내하지만, macOS 업데이트 때마다 다시 해야 합니다.

서버에 올라간 실행 파일 안에 런타임이 들어 있는 경우(단일 실행 파일, 스냅샷)는 번들도 함께 굳어 있으므로, 빌드 파이프라인에서 어떤 런타임 버전을 쓰는지 한 번 확인해 두세요.

철수하는 eMudhra와 남은 G1 루트

사건이 알려진 뒤 eMudhra는 21일 거래소 공시로 입장을 냈습니다. 자국 안의 전자서명 서비스는 별도 장비에서 돌아 영향이 없고, 인프라가 뚫리거나 정보가 새지 않았다는 내용이었고, 보도에 따르면 그날 주가는 하루 하락 제한폭인 20%를 기록했습니다. 22일에는 글로벌 TLS 인증서 사업에서 철수하겠다고 발표했고, 이 사업이 회사 전체 매출에서 차지하는 비중은 약 1%라고 설명했습니다. Mozilla 보고서에서 회사는 오류를 전적으로 인정하면서도, 18일 폐기를 근거로 영향이 넓지 않았다고 주장했습니다.

앞으로의 날짜는 몇 개가 잡혀 있습니다. 근본 원인 보고서는 CCADB 규정의 14일 안에 제출될 예정이고, Chrome이 낸 12개 질문과 Mozilla가 20일에 보낸 질문의 답변은 CCADB의 7일 지침으로 계산하면 28일 무렵이 기한이라고 Bugzilla 댓글이 짚었습니다. 그 질문에는 폐기 목록(CRL) 서명 문제도 들어 있는데, Mozilla 보고서에서는 emSign Root CA - G1 쪽 CRL 하나가 CA 키가 아닌 OCSP 키로 서명됐다는 지적이 따로 올라와 있습니다. Mozilla는 지금 G1 루트의 신뢰를 유지한다고 밝혔고, Google은 eMudhra의 남은 CA 인증서를 Chrome 루트 저장소에 둘지 평가하는 중이며 결과를 CCADB 공개 목록으로 알리겠다고 했습니다. G1 계층으로 옮긴 구독자에게는 이 결정이 곧바로 닿습니다.

신뢰 목록은 한 번 깔고 잊는 설정이 아니라 정기적으로 갱신해야 하는 의존성입니다. 이번에 브라우저가 몇 시간에 끝낸 일을 도구와 서버는 일 단위로 따라갔고, 27일의 G3 루트 제거와 28일 무렵의 답변 기한 뒤에 이어질 Chrome의 결정도 같은 길로 흘러옵니다. 자기 번들과 베이스 이미지의 갱신 주기를 달력에 적어 두는 것이 이번 사건에서 가장 값싼 대비입니다.