eMudhra 인증서 사고, 만료일만 보면 놓치는 것들

NETWORK NEWS & OPINION · 2026. 10. 25. 확인 기준

인증서 만료 알림은 없는데, 접속하던 서비스가 갑자기 인증서 오류를 낸다. 이런 상황이라면 만료일 다음으로 볼 것은 인증서가 연결되는 신뢰 체인이다.

이번 주에는 이 문제를 보여주는 사건이 있었다. 인증기관 eMudhra의 중간 CA 개인키 사고가 공개됐고, 주요 브라우저와 운영체제가 차단 조치에 나섰다. eMudhra는 10월 22일 글로벌 SSL/TLS 인증서 사업에서 철수하겠다고 발표했다. 회사 발표

무슨 일이 있었나

문제의 출발점은 인증서에 서명하는 개인키였다. Google은 eMudhra의 중간 CA 8개에 연결된 개인키가 충분한 무작위성 없이 생성돼, 신뢰가 제거되지 않은 클라이언트를 상대로 위조 HTTPS 인증서를 만들 수 있다고 설명했다. 이 가운데 TLS용은 6개, 코드 서명용은 2개다. Google 보안 공지 · Apple의 영향 범위 설명

CA는 Certificate Authority, 인증기관을 뜻한다. 웹사이트가 보내는 인증서를 누가 발급했는지 확인할 때 등장하는 이름이다. 중간 CA의 서명 키에 문제가 생기면, 그 키로 만들어진 인증서를 믿어도 되는지가 문제가 된다.

공개된 위험과 실제 피해는 구분해서 봐야 한다. Mozilla는 공격자가 연결을 가로챌 수 있을 때 위조 인증서로 사이트를 사칭하고 트래픽을 읽거나 바꿀 가능성을 설명했다. Google은 차단 전 해당 TLS 중간 CA에서 발급된 인증서가 공개 CT(인증서 투명성) 로그에 없었으며, CT 검증을 강제하는 클라이언트에 대해서는 이를 이용한 위조 인증서 공격이 성립할 수 없었다고 밝혔다. 이 발표만으로 모든 HTTPS 접속이나 과거 통신이 노출됐다고 확대해석할 수는 없다. Mozilla 설명 · Google의 보호 조건 설명

만료일이 남아도 접속이 막힐 수 있다

보통 인증서 화면에서 먼저 보는 항목은 도메인과 만료일이다. 실제 검증에는 그 인증서가 신뢰할 수 있는 기준까지 이어지는지도 포함된다. 웹사이트 인증서 → 중간 CA → 신뢰하는 루트라는 관계를 생각하면 이해하기 쉽다. 날짜가 유효해도 이 경로를 더 이상 신뢰하지 않으면 접속이 거부될 수 있다. 인증 경로 검증 원리: RFC 5280

이번 사고에서는 이 차이가 중요하다. Google은 emSign ECC Root CA - G3를 신뢰 목록에서 제거하면서, 그 루트에 연결된 정상 인증서 일부도 Chrome에서 동작하지 않게 된다고 안내했다. 해당 루트에 연결되는 웹사이트 운영자는 Chrome이 신뢰하는 다른 인증서 신뢰 체계의 새 인증서를 받아 설치하라는 지침이다.

Chrome Root Store를 사용하는 기기 대상 배포는 2026년 10월 27일 오전, 미국 태평양 일광절약시(PDT) 기준으로 예고됐다. 사전 배포 채널에는 먼저 적용될 수 있다. 인증서가 해당 경로를 사용한다면 만료일까지 기다릴 사안이 아니다. 적용 일정과 교체 안내

브라우저 확인과 서버 확인은 따로 필요하다

브라우저에서 경고가 사라졌다고 점검이 끝나지는 않는다. Mozilla는 Firefox에 OneCRL 차단을 배포했고, Apple도 자사 보안 프레임워크를 사용하는 앱에 자동 차단을 적용했다고 설명했다. Firefox 대응 · Apple 대응

하지만 Apple은 일부 macOS 명령줄 도구가 별도의 /etc/ssl/cert.pem을 사용해, 같은 차단을 아직 적용받지 않을 수 있다고 안내했다. 자체 루트 목록을 포함하는 앱도 있다. 같은 컴퓨터에서 같은 주소에 접속해도, 프로그램이 쓰는 신뢰 저장소에 따라 결과가 달라질 수 있다는 뜻이다. 명령줄 도구·자체 저장소 관련 안내

그래서 점검 대상을 사용자 PC에만 한정하지 않는 편이 좋다. API를 호출하는 서버, 컨테이너, 자동화 도구를 함께 살펴보자. 프록시나 보안 장비에서 외부 TLS 연결을 검증하는 기능을 쓴다면, 그 기능의 CA 저장소와 제조사 공지도 확인할 대상이다. 이는 운영상 권하는 점검 범위이며, 특정 장비의 취약 여부를 확정한 목록은 아니다.

오늘 점검한다면, 이 순서로

먼저 내보내는 인증서와 검증하는 쪽을 나눠보자. 서비스 운영자는 자신이 제공하는 인증서 체인을, 접속하는 쪽의 관리자는 클라이언트의 신뢰 저장소를 확인해야 한다. 다음 네 항목을 점검표로 남겨두면 담당자를 정하기도 쉽다.

점검 위치	확인할 내용
웹·API 서비스	서버 인증서의 발급자와 전체 체인이 어느 루트에 연결되는지 확인한다. 영향받는 경로라면 공급자의 교체 안내에 따라 새 인증서와 중간 체인을 준비한다.
서버·컨테이너·자동화	실제로 실행 중인 프로그램이 어떤 CA 저장소를 쓰는지 찾고, 배포판·런타임·앱의 공식 업데이트와 적용 상태를 확인한다.
프록시·보안 장비	외부 TLS 검증 기능의 사용 여부와 해당 기능이 참조하는 신뢰 목록을 확인한다. 설정 변경 전에는 제조사 지원 지침과 영향 범위를 대조한다.
변경 후 확인	브라우저뿐 아니라 실제 API 호출과 예약 작업도 시험한다. 적용한 인증서·체인·업데이트 버전과 결과를 함께 기록한다.

인증서 오류를 없애려고 검증을 끄거나, CA 이름만 보고 루트를 일괄 삭제하는 방식은 피해야 한다. Apple도 수동으로 루트를 제거하면 사고와 직접 관련 없는 다른 인증서의 검증까지 실패할 수 있다고 명시했다. 직접 조치가 필요한 환경이라면 해당 공급자의 현재 지침과 서비스 영향을 먼저 확인하자. Apple이 설명한 수동 변경의 영향

엔지니어 관점: 인증서 대장에 한 칸을 더

이번 일을 보며 인증서 관리표에 추가할 항목은 비교적 명확해 보인다. 만료일 옆에 연결되는 루트 CA, 실제 사용하는 신뢰 저장소, 교체 담당자를 적어두는 것이다.

인증서는 설치하고 나면 한동안 손댈 일이 없어 보이는 항목이다. 그만큼 웹 서버, 로드밸런서, 보안 장비, 오래된 자동화 작업에 흩어져 있기 쉽다. 다음 점검 때 “곧 만료되는 인증서가 있나”에 더해 “신뢰 정책이 바뀌면 어디부터 바꿔야 하나”까지 물어보면, 사고가 난 뒤의 대응 순서를 미리 정리할 수 있다.

이 글은 2026년 10월 25일 확인한 공개 공지를 바탕으로 정리했습니다. 차단 범위와 배포 일정은 달라질 수 있으므로 작업 시점의 공식 안내를 다시 확인해주세요.

더 읽어볼 자료

독립 보도: The Hacker News의 사건·사업 철수 정리. 이 글의 기술적 사실은 위에 연결한 Google·Mozilla·Apple 원문과 인증 경로 표준을 기준으로 확인했습니다.