eMudhra CA 키 손상 사고: 기업이 지금 점검하고 고쳐야 할 것

2026년 10월 17일 토요일, 한 보안 연구자가 인도의 인증 기관 eMudhra가 운영하는 중간 인증 기관(중간 CA) 8개의 개인 키를 공개된 인증서만으로 누구나 알아낼 수 있다고 보고했습니다. 키는 하나같이 256보다 작은 수였습니다. 그중 하나는 숫자 4였습니다. 8개 중 6개는 Apple, Google, Microsoft, Mozilla가 신뢰하는 TLS 인증서를 발급할 수 있었고, 나머지 2개는 Windows 소프트웨어에 서명할 수 있었습니다.

Chrome은 보고 1시간 40분 뒤에 TLS 키 6개를 차단했고, Firefox는 같은 날 저녁에 차단했습니다. 웹을 탐색하는 사람에게 위험은 토요일 밤에 이미 지나갔습니다.

나머지 모든 것에는 아직 끝나지 않았습니다. 서버, 컨테이너, Java 애플리케이션, Python 스크립트, 결제 연동, 커넥티드 기기는 신뢰하는 인증 기관 목록의 자체 사본으로 인증서를 검사하며, 이런 사본은 대부분 누군가 업데이트를 설치해야만 바뀝니다. 그때까지는 이 키 중 하나로 서명된 인증서가 어떤 도메인의 것이든 진짜로 통과하며, 키는 10월 20일부터 공개되어 있습니다.

같은 주에 GoDaddy는 인증서 404,607개의 폐기를 시작했습니다. 인증서에 담긴 정책 정보가 GoDaddy가 직접 공개한 문서와 일치하지 않았기 때문입니다. 고객은 교체 인증서를 직접 내려받아 설치해야 했습니다.

이 가이드는 "우리도 영향을 받나?"에 답해야 하는 사람들을 위한 것입니다. IT 및 운영 책임자, CTO, 그리고 웹사이트, API, 커넥티드 제품으로 사업을 하는 창업자입니다. Mozilla, Google, eMudhra, GoDaddy와 소프트웨어 공급업체가 공개한 사고 기록을 바탕으로 무슨 일이 있었는지 정리하고, 오늘 점검할 것, 이번 주에 업데이트할 것, 그리고 다음에 같은 종류의 사고가 나도 일상 업무로 처리할 수 있도록 갖춰 둘 것을 다룹니다. 모든 내용은 2026년 10월 22일 기준이며, 사고는 아직 종결되지 않았습니다.

무슨 일이 있었나

eMudhra는 2025년 4월 30일 키 세레모니(key ceremony)에서 이 중간 CA 8개를 만들었습니다. eMudhra가 10월 19일 Mozilla의 사고 보고 버그에 올린 경위는 이렇습니다. 평소 절차에서 벗어나는 예외로 승인받은 키 래핑(wrap)과 언래핑(unwrap) 단계의 테스트에 결함이 있었고, 그 때문에 하드웨어 보안 모듈(HSM) 안에서 의도한 키와 나란히 약한 키 세트가 하나 더 만들어졌습니다. 레이블이 비슷했고, 약한 키가 실수로 인증서 요청 생성에 쓰였으며, eMudhra의 루트가 그 요청에 서명했습니다. 같은 요청이 Sectigo에도 전달되었고, Sectigo는 2025년 5월 14일 자사의 AAA Certificate Services 루트로 8개 모두를 교차 서명했습니다. eMudhra는 "정확한 근본 원인을 아직 확인하지 못했다"고 밝혔습니다.

Mozilla는 그 결과를 이렇게 설명했습니다. "P384 개인 키는 1과 군의 위수(group order) 사이에서 무작위로 선택되는 정수다. 영향을 받은 키 8개는 모두 256보다 작은 정수를 사용했다." Mozilla는 20:06(UTC)에 보고를 받았고, 21:48에 "최초 보고자가 사용한 방법을 전혀 모르는 상태에서" 직접 키를 복구했습니다. 연구자는 Google의 오픈소스 라이브러리인 paranoid_crypto를 "별도 설정 없이 그대로" 써서 키를 찾았다고 말합니다. 약한 키는 거의 18개월 동안 공개적으로 신뢰받는 인증서 체인의 일부였습니다.

인증서 8개는 다음과 같습니다.

각 키는 인증서 두 개에 들어 있습니다. 하나는 eMudhra의 emSign Root TLS CA - G3 또는 emSign Root CS CA - G3가 발급한 것으로, emSign ECC Root CA - G3까지 체인이 이어집니다. 다른 하나는 AAA Certificate Services가 발급한 Sectigo의 교차 인증서입니다. 두 번째 경로가 중요한 이유는, eMudhra 루트를 한 번도 담은 적 없는 일부 신뢰 저장소(trust store)도 이 오래된 Sectigo 루트는 여전히 신뢰하기 때문입니다.

공격은 있었나

보고된 악용 사례는 없으며, 브라우저의 경우에는 악용이 없었다고 볼 타당한 근거가 있습니다. Chrome은 Certificate Transparency(CT, 인증서 투명성)를 강제하는 다른 클라이언트와 마찬가지로, 공개 CT 로그에 기록된 인증서만 받아들입니다. Google에 따르면 차단 전까지 이 중간 CA 6개로 이어지는 TLS 인증서는 로그에 하나도 기록되지 않았으므로, "이 CA들이 발급한 부정 인증서가 CT를 강제하는 클라이언트를 상대로 사용되었을 수는 없다"고 합니다.

브라우저 밖은 사정이 다릅니다. Mozilla의 사고 안내 페이지는 이렇게 말합니다. "브라우저 생태계 밖의 많은 클라이언트는 Certificate Transparency를 강제하지 않는다. 공격자가 결함 있는 키 생성을 악용해 이런 클라이언트를 노렸는지는 알 수 없다." 이 공백은 2025년 봄에 열렸고, 각 클라이언트가 업데이트되어야만 닫힙니다. eMudhra는 공개 이전에 키가 복구되었다는 증거를 알지 못한다고 밝혔고, Cloudflare는 자체 검토에서 자사 서비스에 대한 실제 악용을 발견하지 못했다고 밝혔습니다.

키가 공개된 지금은 인증서 위조에 아무런 기술도 필요하지 않습니다. Mozilla의 사고 안내 페이지에는 손상된 키로 발급된 인증서를 제시하는 테스트 서버 목록이 있어, 누구나 자기 클라이언트를 그 서버로 점검할 수 있습니다(명령은 아래에 있습니다).

위조 인증서로 할 수 있는 일은 이렇습니다. 여러분의 소프트웨어와 그 소프트웨어가 호출하는 서비스 사이의 트래픽을 가로챌 수 있는 사람(공유 네트워크에서, 침해된 라우터를 통해, 또는 오염된 DNS 응답으로)은 그 서비스로 위장해, 소프트웨어가 보내는 내용을 API 키와 개인정보까지 읽고, 소프트웨어가 받는 내용을 바꿀 수 있습니다. 코드 서명 키 2개 중 하나로 서명된 소프트웨어는 Microsoft의 차단이 해당 컴퓨터에 닿기 전까지 Windows 서명 검사를 통과했을 것입니다.

누가 영향을 받나

서로 다른 문제가 세 가지 있고, 한 회사가 세 가지를 모두 안고 있을 수도 있습니다.

1. 손상된 키를 아직 신뢰하는 소프트웨어

거의 모든 회사에 해당하는 문제입니다. 신뢰 저장소에 아직 emSign ECC Root CA - G3나 AAA Certificate Services가 들어 있고, 키 8개에 대한 차단을 받지 않은 채 HTTPS 호출을 하는 모든 프로그램이 대상입니다. 흔히 있는 곳은 다음과 같습니다.

• 10월 20일 또는 21일 이전에 빌드한 Linux 서버와 컨테이너 이미지. 예를 들어 패치하지 않은 Debian 12는 두 체인을 모두 신뢰합니다.
• 자체 목록을 함께 배포하는 언어 런타임: Node.js, Python의 certifi, Java의 cacerts, PHP의 Composer 번들, Rust의 webpki-roots.
• macOS 명령줄 도구. Mozilla의 사고 안내 페이지에 따르면 기본 내장된 curl, git, python3, perl, ruby, openssl은 폐기 여부를 확인하지 않고 /etc/ssl/cert.pem으로 인증서를 검사하며, Apple은 이 파일을 업데이트하지 않았습니다.
• Microsoft의 허용되지 않는 인증서 목록 자동 업데이트를 받지 못하는 Windows 컴퓨터. 대개 그룹 정책으로 자동 업데이트를 꺼 두었거나 네트워크가 오프라인인 경우입니다.
• 로드 밸런서, VPN 게이트웨이, SDK, 임베디드 컨트롤러처럼 자체 CA 파일을 내장한 어플라이언스, 기기, 서드파티 소프트웨어.

런타임마다 따로 점검해야 합니다. 우리가 10월 22일에 실시한 테스트에서 Node.js 24.18이 설치된 패치 안 된 Debian 12 컴퓨터는 eMudhra 루트로 끝나는 체인은 받아들이고 Sectigo 루트로 끝나는 체인은 거부했지만, 같은 컴퓨터의 Python은 둘 다 받아들였습니다.

2. 자사 인증서가 제거된 루트로 이어지는 회사

Mozilla와 Linux 배포판은 emSign ECC Root CA - G3를 제거했고, Chrome도 10월 27일에 뒤따릅니다. 이 루트 아래의 유효한 인증서는 각 클라이언트가 업데이트되는 대로 그 클라이언트에서 작동하지 않게 됩니다. Google은 이런 인증서를 가진 웹사이트 운영자가 "Chrome Root Store에 포함된 다른 PKI 계층에서 새 TLS 인증서를 즉시 발급받아 설치해야 한다"고 안내합니다.

Chrome은 10월 21일 CT에서 이 루트 아래의 만료되지 않은 인증서를 약 30,800개로 집계했습니다. 그중 30,791개는 InCommon의 중간 CA 2개에서 나왔습니다. InCommon은 Internet2가 미국 대학과 연구 기관을 위해 운영하는 인증서 서비스로, eMudhra의 플랫폼인 CERTInext를 통해 ECC 인증서를 발급합니다. 18개는 eMudhra 자체 중간 CA에서 나왔습니다. eMudhra는 약 30,000개의 인증서를 이전해야 하며 그중 약 97%가 ACME로 발급되었고, 다른 계층에서 교체 인증서를 발급하고 있다고 밝혔습니다.

사이트가 Full (strict) 모드의 Cloudflare 뒤에 있고 오리진이 이 루트 아래의 인증서를 제시한다면, Cloudflare는 이번 신뢰 철회가 "장애를 일으킬 것"이라고 말하며 고객에게 "사용자 지정 오리진 인증서와 서버 구성을 검토하라"고 요청합니다.

eMudhra의 다른 루트인 emSign Root CA - G1의 RSA 인증서는 지금까지는 영향을 받지 않았습니다. Mozilla는 이 루트를 "현재로서는" 제거하지 않는다고 밝혔고, Chrome은 "eMudhra의 나머지 CA 인증서를 계속 포함할지 면밀히 조사하고 있다"고 합니다. 종류를 불문하고 eMudhra나 CERTInext 인증서에 의존하고 있다면 지금 두 번째 인증 기관을 확보해 두세요.

3. GoDaddy 고객

GoDaddy 건은 eMudhra와 아무 관련이 없지만, 같은 주에 터졌고 훨씬 많은 사이트에 영향을 주었습니다. 10월 15일 GoDaddy는 GoDaddy와 Starfield 계층의 인증서에 담긴 인증서 정책 정보(정책 OID와 CPS 링크)가 자사 CP/CPS의 프로파일과 일치하지 않는다고 Mozilla에 보고했습니다. CP/CPS는 인증 기관이 무엇을 발급하는지 밝히는 문서입니다. 이것은 인증서의 보안 결함이 아닙니다. 그래도 모든 공개 인증 기관이 따르는 규칙인 Baseline Requirements에 따르면 5일 안에 폐기해야 하는 사유입니다.

영향을 받은 인증서는 404,607개였고, 그중 396,055개는 도메인 검증(DV) 인증서였습니다. GoDaddy는 기한인 10월 18일 23:45(UTC)까지 170,566개를 폐기했고, 다음 날 아침까지 227,422개를 폐기했습니다. GoDaddy의 고객 공지에 따르면 나머지는 10월 21일에 폐기되었습니다. GoDaddy가 인증서를 재발급하지만 설치는 고객 몫입니다. GoDaddy는 "새 인증서가 설치될 때까지 웹사이트 방문자에게 보안 경고가 표시될 수 있고, 사이트에 접속할 수 없게 될 수도 있다"고 안내합니다.

오늘 점검할 것

1. 자사 서버는 무엇을 보내고 있나? 공개 호스트 이름마다 그 호스트가 제시하는 체인의 발급자를 나열하세요.

h=www.example.com
openssl s_client -connect "$h:443" -servername "$h" -showcerts </dev/null 2>/dev/null | grep -E '^ +i:'

eMudhra, emSign, EM ... G3B나 G3C 인증 기관 중 하나, 또는 InCommon Intermediate CA - DVG3C, OVG3C, EVG3C를 가리키는 줄이 있다면 10월 27일 전에 인증서를 교체해야 합니다. AAA Certificate Services만 있는 것은 정상입니다. 평범한 Sectigo 체인 상당수에 아직 포함되어 있기 때문입니다. 메일과 디렉터리 서비스에는 -starttls smtp(또는 imap, ldap)와 알맞은 포트를 추가하세요. 내부 호스트, 로드 밸런서, CDN 뒤의 오리진도 포함하세요.

2. 자사 도메인으로 무엇이 발급되었나? CT에는 공개 인증 기관이 자사 도메인 이름으로 발급한 모든 인증서가 나옵니다. 회사 안에서 아무도 주문한 기억이 없는 인증서까지 포함됩니다.

curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired' | jq -r '.[].issuer_name' | sort | uniq -c

출력을 보면 회사가 실제로 어떤 인증 기관을 쓰고 있는지도 알 수 있으며, 이것이 아래에서 설명할 인벤토리의 출발점입니다.

3. 자사 클라이언트는 손상된 키를 신뢰하나? Mozilla의 테스트 서버는 손상된 키로 발급된 인증서를 제시하므로, 인증서 오류가 나는 것이 좋은 결과입니다. 두 계열을 모두 테스트하세요. 첫 번째 호스트는 eMudhra의 루트로, 두 번째 호스트는 Sectigo의 루트로 이어지며, 신뢰 저장소에 따라 한쪽 테스트는 실패하고 다른 쪽은 통과할 수 있습니다.

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"

curl의 결과는 curl에만 해당합니다. 같은 요청을 각 애플리케이션이 실제로 실행되는 환경에서, 그 애플리케이션의 TLS 스택으로 보내 보세요.

node -e "require('https').get('https://dv-g3b-emudhra.we-have-a-problem.com/', () => console.log('TRUSTED')).on('error', e => console.log('rejected:', e.code))"
python3 -c "import urllib.request; urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"
python3 -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"

Python 두 줄은 중복이 아닙니다. urllib은 운영체제의 신뢰 저장소를 쓰고, requests는 certifi를 씁니다. 각 줄을 dv-g3b-aaa-emudhra 호스트로도 반복하세요. Java라면 해당 JVM에서 테스트 서버로 아무 HTTPS 호출이나 해 보고, 그 신뢰 저장소에 두 루트 중 하나라도 들어 있는지 확인하세요(Java 9 이상. Java 8에서는 -keystore $JAVA_HOME/jre/lib/security/cacerts 사용).

keytool -list -v -cacerts -storepass changeit | grep -E 'Owner: .*(emSign ECC Root CA - G3|AAA Certificate Services)'

신뢰 저장소에 루트가 있다는 것만으로 노출이 증명되지는 않습니다. Go, Node.js, Deno, Rust의 rustls-webpki는 이제 신뢰 저장소의 내용과 상관없이 키 8개를 차단하기 때문입니다. 결론은 테스트 서버가 내려 줍니다.

4. 사내 Windows 컴퓨터. Microsoft는 이번 사고에 대해 아무것도 발표하지 않았지만, Windows가 자동으로 내려받는 허용되지 않는 인증서 목록은 10월 20일부터 키 8개를 모두 차단하고 있습니다. 예외는 그룹 정책으로 루트 인증서 자동 업데이트를 꺼 둔 컴퓨터와 Windows Update로 가는 경로가 없는 네트워크이며, 이런 곳에는 다른 방법으로 목록을 전달해야 합니다. certutil -verifyCTL Disallowed를 실행하면 컴퓨터에 캐시된 사본을 볼 수 있습니다. Mozilla의 사고 안내 페이지는 개별 컴퓨터용 스크립트를 제공하면서, 이 스크립트는 "기업이 관리하는 기기에는 권장하지 않는다"고 밝힙니다.

5. GoDaddy 인증서. 각 서버가 실제로 어떤 인증서를 제시하는지 확인하세요.

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer -serial -startdate

발급자가 GoDaddy나 Starfield라면 일련번호를 GoDaddy 계정에 있는 인증서와 비교하세요. GoDaddy에 "Install your new certificate"(새 인증서 설치)라고 표시된다면 서버에는 아직 폐기된 인증서가 설치되어 있습니다.

처음부터 끝까지 지킬 원칙: 인증서 검증을 꺼서 오류를 없애지 마세요. Cloudflare는 "검증을 비활성화하는 방식으로 이 오류를 해결하지 않는 것이 중요하다"고 말합니다. 검증하지 않는 클라이언트는 이번 인증서만이 아니라 모든 위조 인증서를 신뢰합니다.

이번 주에 업데이트할 것

수정 방식은 두 가지입니다. 두 루트를 제거하면 그 신뢰 저장소를 쓰는 클라이언트의 모든 경로가 막히지만, 그 아래의 유효한 인증서도 함께 깨집니다. Go, Node.js, Deno, Electron, rustls-webpki, Composer, Windows처럼 키 8개를 공개 키 해시로 차단하면 구멍은 막히고 다른 것은 깨지지 않습니다. 플랫폼이 두 번째 방식을 지원한다면 그쪽을 택하세요.

"아직"은 10월 22일까지 아무것도 공개되지 않았다는 뜻입니다. 이를 전제로 계획을 세우기 전에 다시 확인하세요.

팀들이 자주 놓치는 것이 네 가지 있습니다.

• 컨테이너 이미지는 예전 목록을 그대로 가지고 있습니다. 10월 20일 또는 21일 이전에 빌드한 이미지는 업데이트된 베이스 이미지 위에서 다시 빌드될 때까지 이 키를 신뢰하며, 같은 태그를 다시 pull해도 베이스 이미지가 재빌드된 뒤에야 효과가 있습니다. 다시 빌드하고, 다시 배포하고, 사용 중인 이미지의 공급업체에도 문의하세요.
• 프로세스는 한 번 읽어 들인 것을 계속 씁니다. 프로그램은 시작할 때 신뢰 저장소를 읽으므로, 업데이트한 뒤에는 오래 실행되는 서비스를 재시작하세요. Node.js는 여기에 더해, 업그레이드 이전의 세션에서 재개된 TLS 세션은 다시 검사되지 않는다고 밝혔습니다.
• 애플리케이션은 자체 CA 파일을 가지고 다닙니다. SDK와 애플리케이션은 자체 cacert.pem이나 ca-bundle.crt를 함께 배포하는 경우가 많습니다. 예를 들어 find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null로 리포지토리와 이미지에서 찾아보고, 하나만 나오지는 않으리라 예상하세요. pip만 해도 certifi 사본을 따로 가지고 있습니다.
• 기기는 공급업체를 기다려야 합니다. 공급업체마다 제품이 어떤 신뢰 저장소를 쓰는지, 업데이트가 언제 나오는지 서면으로 문의하세요. 업데이트가 나올 때까지 그 기기는 자신이 호출하는 모든 서비스에 대해 위조 인증서를 신뢰하므로, 기기가 접근할 수 있는 범위를 제한하세요.

Debian, Ubuntu ESM, Fedora, 그리고 Red Hat의 우회 방법처럼 AAA Certificate Services를 수동으로 제거한다면, 그 뒤에 Sectigo 인증서를 쓰는 서비스로의 연결을 테스트하세요. 일부 오래된 서버는 아직 이 루트로 끝나는 체인을 보내기 때문입니다.

다음 사고 전에 갖춰 둘 것

인증 기관이 이렇게 약한 키를 남기는 일은 드뭅니다. 대량 폐기는 드물지 않습니다. 다음은 Mozilla의 버그 트래커에 기록된 2026년의 대규모 폐기입니다.

이 다섯 건 중 보안 실패는 하나도 없었습니다. 모두 인증서가 인증 기관 자신의 문서와 맞지 않았던 경우이고, 그래도 Baseline Requirements(4.9.1.1절)는 5일 안에 폐기하도록 요구합니다. 키가 손상되었거나 도메인 검증을 신뢰할 수 없는 경우 기한은 24시간입니다. 누구도 이 기한을 대신 연장해 줄 수 없습니다. 2024년 DigiCert가 인증서 83,267개를 폐기했을 때 Chrome Root Program은 자신에게 "예외를 허용할 권한이 없다"고 밝혔습니다. 한 고객은 자사 인증서의 폐기를 막는 법원 명령을 받아 냈지만, 그 명령은 4일 뒤 취소되었습니다.

교체가 어떻게 진행됐는지를 보면 많은 것을 알 수 있습니다. 7월에 HARICA는 ACME Renewal Information(ARI)을 이용해 고객의 ACME 클라이언트에 조기 갱신을 지시했고, 그 밖의 인증서는 직접 재발급했습니다. 두 건의 폐기 중 큰 쪽에서는 기한이 되었을 때 영향받은 이름의 87%가 이미 교체되어 있었습니다. 고객이 교체 인증서를 하나하나 직접 내려받아 설치해야 하는 GoDaddy는 기한까지 영향받은 인증서의 42%를 폐기했습니다.

어쨌든 갱신 주기는 짧아지고 있습니다.

• CA/Browser Forum의 투표안 SC-081에 따라 공개 TLS 인증서의 유효기간은 2026년 3월 15일부터 200일로 제한되어 있습니다. 이 한도는 2027년 3월 15일에 100일로, 2029년 3월 15일에 47일로 줄어들며, 그때부터는 도메인 검증 결과를 10일 동안만 재사용할 수 있습니다.
• Let's Encrypt는 2027년 2월 10일에 기본 인증서를 64일짜리로 바꾸고, 1년 뒤에는 45일로 바꿉니다.
• 공개 TLS 인증서에서 클라이언트 인증 용도가 사라지고 있습니다. Let's Encrypt는 2026년 7월 8일에 이 용도의 발급을 중단했고, Chrome Root Program은 2027년 3월 15일부터 발급되는 인증서를 서버 인증 전용으로 하도록 요구합니다. B2B API 연동에서 흔히 그렇듯 공개 인증서를 상호 TLS(mutual TLS)의 클라이언트 인증서로 쓰고 있다면, 그 연결에는 사설 인증 기관이 필요합니다.

유효기간이 100일, 그다음 47일이 되면 인증서를 손으로 설치하는 것은 더 이상 현실적인 선택지가 아닙니다. 이 일정에 맞춰 자동화한 회사는 다음 대량 폐기에도 대비가 된 셈입니다. 필요한 것은 다음과 같습니다.

1. 가진 것을 양방향으로 파악하세요. 첫째 목록에는 자사가 제공하는 모든 인증서를 호스트 이름, 발급자, 만료일, 갱신 방식, 담당자와 함께 담습니다. 둘째 목록에는 소프트웨어가 의존하는 모든 신뢰 저장소를 담습니다. 운영체제 패키지, 각 언어의 번들, 애플리케이션이나 기기 안의 각 CA 파일입니다. 첫째 목록은 앞의 CT 검색으로, 둘째 목록은 소프트웨어 자재 명세서(SBOM)나 의존성 인벤토리로 시작할 수 있습니다.
2. 발급과 설치를 자동화하세요. ACME를 실행할 수 있는 곳에는 모두 ACME를 쓰고, 인증 기관이 클라이언트에 조기 갱신을 알릴 수 있도록 ARI(RFC 9773)도 함께 적용하세요. ACME를 실행할 수 없는 기기라면 공급업체의 자동화 기능을 쓰거나, ACME를 실행할 수 있는 장비를 기기 앞에 두고 거기서 TLS를 종료하세요.
3. 두 번째 인증 기관을 준비해 두세요. 두 번째 인증 기관에 실제로 작동하고 테스트까지 마친 ACME 계정을 두고, DNS의 CAA 레코드에서 두 곳을 모두 허용하세요. 한 인증 기관이 신뢰를 잃거나 대량 폐기를 하더라도 전환은 설정 변경으로 끝납니다.
4. 자사 도메인의 CT를 모니터링하세요. 자사 도메인 이름으로 새 인증서가 발급될 때마다 알림을 받으세요. 예상치 못한 발급을 그날 바로 알게 됩니다.
5. 신뢰 저장소를 의존성으로 취급하세요. 일반적인 패치 과정으로 업데이트하고, 코드가 바뀔 때만이 아니라 정해진 일정에 따라 이미지를 다시 빌드하세요.
6. 두 개의 시계에 맞춰 런북을 작성하세요. 24시간과 5일입니다. 누가 결정하는지, 각 시스템에 누가 접근할 수 있는지, 어느 시스템에 수동 작업이 필요한지, 각 공급업체에 어떻게 연락하는지를 적어 두세요. 실수해도 감당할 수 있는 서비스에서 인증서를 교체해 보는 방식으로 1년에 한 번 연습하세요. 공개 인증 기관은 2025년부터 자체 대량 폐기 계획을 세우고 테스트해야 했습니다. 그 고객에게는 나머지 절반이 필요합니다.

다른 회사가 운영하는 제품을 만든다면

제품에 신뢰 저장소가 들어 있다면(기기, 설치형 애플리케이션, SDK), 고객은 여러분의 업데이트가 도달해야만 보호받습니다. 업데이트를 배포하고, 어느 버전에서 수정되었는지 고객에게 알리세요. Mozilla는 신뢰 저장소 운영자에게, 소프트웨어가 지원한다면 중간 CA 8개를 차단하고 그렇지 않다면 "이 중간 CA에 서명한 루트에 대한 신뢰를 제거하는 것이 적절한지 검토하라"고 권고합니다.

사이버 복원력법은 여기에 두 가지로 적용됩니다. 2026년 9월 11일부터 시행 중인 통보 의무는 실제로 악용되는 취약점을 대상으로 하는데, 이번 건에서는 악용이 보고되지 않았습니다. 2027년 12월 11일부터 적용되는 필수 요건에는 보안 업데이트로 취약점을 해결할 수 있어야 한다는 내용이 들어 있습니다. 신뢰 목록을 업데이트할 수 없는 제품은 이 요건을 충족하지 못할 것입니다. NIS2의 적용을 받는 고객은 공급업체에 이번 일을 얼마나 빨리 처리했는지 물을 것이고, 그 답을 문서로 남겨 두면 도움이 됩니다.

아직 해결되지 않은 것

• eMudhra의 남은 루트. Chrome은 10월 21일 eMudhra에 질문 12개를 게시했으며, emSign Root CA - G1에 대해서는 아무 결정도 발표하지 않았습니다. Mozilla는 이 루트를 "현재로서는" 제거하지 않습니다.
• eMudhra의 이전 경로. eMudhra는 Mozilla에 고객을 G1(RSA) 계층으로 옮기겠다고 말했지만, 상태 페이지에서는 "독립적으로 운영되고 공개적으로 신뢰받는 다른 CA 계층"을 언급합니다. Chrome은 어느 쪽인지 물었습니다.
• Microsoft와 Apple. 두 회사 모두 성명을 내지 않았고, 자사 신뢰 저장소에서 두 루트 중 어느 것도 제거하지 않았습니다.
• 아직 나오지 않은 수정. Red Hat, Amazon Linux, Temurin, Corretto는 10월 22일까지 아무것도 내놓지 않았습니다. Bun의 수정은 병합되었지만 릴리스되지 않았습니다.
• 근본 원인. eMudhra는 근본 원인을 확정하지 않았으며, 지금까지 진행한 모든 키 세레모니를 다시 검증하겠다고 밝혔습니다.
• Sectigo. 9월 5일부터 진행 중인 별개의 건에서 Sectigo는 확장 키 사용(extended key usage)이 자사 CPS의 한 문장과 맞지 않는 인증서의 폐기를 거부하고 있으며, 그 문장이 모호했다고 주장합니다. Sectigo가 10월 18일에 집계한 바로는 이런 인증서 약 7,200만 개가 아직 유효합니다. 공개 논의에 참여한 일부는 신뢰 철회를 요구했지만, 결정을 발표한 루트 프로그램은 없습니다. Sectigo 인증서를 쓰는 회사는 이 건을 지켜봐야 합니다.

도움을 얻으려면

인증서 문제는 좀처럼 인증서 문제처럼 보이지 않습니다. 결제 페이지가 열리지 않거나, 연동이 동기화를 멈추거나, 기기가 보고를 멈추는 모습으로 나타나고, 대개 주말에 일어납니다. 우리는 기업이 이번 같은 주를 장애 없이 넘기고, 다음번은 일상 업무로 처리할 수 있도록 준비하는 일을 돕습니다.

• 노출 점검. 시스템이 어디에서 TLS 연결을 맺거나 받는지, 각각 어떤 신뢰 저장소를 쓰는지, 어떤 인증서를 제공하는지 찾아냅니다. 컨테이너, Java 서비스, 은행·결제·물류 업체와의 연동, 기기까지 포함합니다.
• 수정. 업데이트, 이미지 재빌드, 키 차단, 인증서 교체를 회사의 변경 관리 절차에 따라 진행하고, Mozilla의 테스트 서버로 결과를 확인합니다.
• 2027년에 대비한 자동화. 서버, 로드 밸런서, 어플라이언스 전반에 ARI를 적용한 ACME, 두 번째 인증 기관, CAA 레코드, CT 모니터링, 런북까지 갖춰 2027년 3월 15일부터 시작되는 100일 인증서에 대비합니다.
• 아무도 손대고 싶어 하지 않는 시스템. 자체 신뢰 저장소를 가진 오래된 Java 애플리케이션, 어플라이언스, 임베디드 클라이언트는 바로 우리의 레거시 시스템 및 코드 유지보수 서비스가 맡는 영역입니다.

영향을 받는지 확실하지 않다면 운영 중인 도메인과 플랫폼을 적어 office@c9group.dev로 메일을 보내 주시거나 통화를 예약해 주세요. 무엇부터 점검해야 할지 알려 드리겠습니다.