브라우저에 내장된 인증기관 목록은 무엇일까 — Root Store와 HTTPS 신뢰 구조 이해하기

웹사이트에 접속하면 주소창에 자물쇠 모양이 표시됩니다. 브라우저는 서버가 보낸 인증서를 확인한 뒤 연결할 도메인이 맞는지, 인증서가 유효한지, 신뢰할 수 있는 인증기관이 발급했는지를 판단합니다.

 

여기서 한 가지 궁금증이 생깁니다.

브라우저는 어떤 인증기관을 믿어야 하는지 어떻게 알고 있을까?

그 기준이 되는 것이 Root Store, 즉 신뢰할 수 있는 루트 인증기관의 목록입니다. 흔히 “브라우저에 인증기관 목록이 내장되어 있다”고 표현하지만 실제 구조는 조금 더 복잡합니다. 브라우저가 자체 목록을 사용할 수도 있고, 운영체제 목록을 사용할 수도 있으며, 회사 관리자가 별도의 사설 인증기관을 추가할 수도 있습니다.

 

이 글에서는 브라우저와 운영체제에 등록된 인증기관 목록이 무엇인지, Chrome·Firefox·Safari는 서로 어떻게 다른지, 인증기관이 목록에 포함되거나 제거되면 어떤 일이 생기는지를 살펴봅니다.

브라우저가 인증서 체인을 따라 루트 인증기관의 신뢰를 확인하는 구조

---

먼저 구분해야 할 세 종류의 인증서

HTTPS 인증서를 이해하려면 서버 인증서, 중간 인증서, 루트 인증서를 구분해야 합니다.

구분	역할	일반적인 위치
서버 인증서	접속한 도메인과 공개키를 연결	웹 서버가 브라우저에 전달
중간 인증서	루트 CA를 대신해 서버 인증서를 발급	웹 서버가 체인의 일부로 전달
루트 인증서	인증서 체인의 최종 신뢰 기준	브라우저 또는 운영체제의 Root Store

예를 들어 www.example.com의 서버 인증서가 중간 CA에 의해 서명되고, 그 중간 CA 인증서가 루트 CA로 이어진다고 가정해 보겠습니다.

신뢰된 루트 CA
    └── 중간 CA
          └── www.example.com 서버 인증서

브라우저는 서버가 보내온 인증서 체인을 검증해 자신이 신뢰하는 루트까지 연결되는지 확인합니다. 이를 인증 경로 검증 또는 Chain of Trust 검증이라고 합니다.

 

중요한 점은 루트 인증서 목록에 인증기관의 공개키와 신원 정보가 들어 있다는 것입니다. 인증기관의 개인키가 브라우저에 들어 있는 것은 아닙니다. 루트 CA의 개인키는 인증기관이 별도로 보호하며, 브라우저는 공개키로 서명의 유효성을 검증합니다.

Root Store는 단순한 인증서 파일 모음이 아니다

Root Store는 기본적으로 신뢰 앵커로 사용할 루트 인증서의 집합입니다. 그러나 실제 제품에서는 인증서 외에도 여러 정책이 함께 적용됩니다.

• 특정 루트 CA의 신뢰 여부
• TLS 서버 인증에 사용할 수 있는지
• 인증서가 적용되는 DNS 이름이나 발급 시점의 제약
• 차단된 CA와 인증서
• Certificate Transparency 요구사항
• 허용되는 키 크기와 서명 알고리즘
• 서버 인증서의 최대 유효기간
• 인증서 폐기 정보

따라서 같은 루트 인증서를 가지고 있다고 해서 모든 브라우저가 완전히 같은 결과를 내는 것은 아닙니다. 인증 경로를 만드는 방식, 중간 인증서 선택, 폐기 확인, 로컬 정책과 브라우저별 추가 보안 규칙이 다를 수 있기 때문입니다.

 

Root Store를 다음처럼 이해하면 편합니다.

Root Store는 “이 인증기관을 무조건 믿는다”는 명단이 아니라, 인증서 검증을 시작할 수 있는 신뢰 앵커와 그 신뢰에 적용할 정책의 집합이다.

Chrome은 이제 자체 Root Store를 사용한다

과거의 Chrome은 Windows와 macOS 같은 운영체제의 인증서 저장소와 검증 기능에 크게 의존했습니다. 이 방식에서는 같은 Chrome 버전이라도 운영체제에 따라 인증서 검증 결과가 달라질 수 있었습니다.

 

현재 Chrome은 지원되는 주요 플랫폼에서 Chrome Root Store와 Chrome Certificate Verifier를 사용합니다. Google이 공개적으로 운영하는 루트 프로그램을 기준으로 공개 CA 목록을 관리하고, Chrome이 공통된 방식으로 인증서 경로를 검증합니다.

 

Chrome Root Store의 특징은 다음과 같습니다.

• Chrome이 기본 신뢰하는 공개 루트 CA를 Google이 관리합니다.
• Root Store는 Chrome 바이너리에 포함됩니다.
• 변경된 목록은 Component Updater를 통해 브라우저 전체 업데이트와 별도로 배포될 수 있습니다.
• 일반적인 Root Store 업데이트는 대략 분기 단위로 이루어질 수 있습니다.
• 긴급한 보안 문제가 있으면 정기 주기와 별도로 변경될 수 있습니다.
• Chrome은 RFC 5280 기반 검증 외에도 Certificate Transparency와 인증서 유효기간 같은 추가 정책을 적용합니다.

Chrome Root Program은 CA가 공개 루트 목록에 포함되기 위한 최소 요건을 정합니다. CA/Browser Forum의 Baseline Requirements 준수, CCADB 정보 공개, 정기 감사와 사고 대응 등이 중요한 심사 요소입니다.

자체 Root Store를 쓰면 회사의 사설 CA는 무시될까?

그렇지 않습니다.

 

Chrome Certificate Verifier는 공개 웹을 위한 Chrome Root Store와 별도로 사용자가 또는 조직 관리자가 로컬에서 설정한 신뢰 결정도 고려합니다. 예를 들어 회사가 Windows 그룹 정책이나 macOS 관리 프로파일로 사내 루트 CA를 배포했다면 Chrome은 내부 사이트의 인증서를 검증할 때 이를 사용할 수 있습니다.

 

다만 공개 루트와 로컬 루트는 같은 의미가 아닙니다.

항목	공개 루트 CA	로컬·사설 루트 CA
주요 용도	공개 인터넷 사이트	사내 시스템, 개발 환경, 보안 프록시
포함 주체	브라우저·OS의 Root Program	사용자 또는 조직 관리자
적용 범위	해당 Root Store를 쓰는 다수 사용자	인증서가 설치된 장비와 계정
검증 기준	공개 정책, 감사, CCADB, 업계 요구사항	조직 내부 정책
잘못 신뢰했을 때 영향	전 세계적인 인증서 오발급 위험	관리 범위 안의 HTTPS 가로채기 위험

Chrome 공식 문서에는 로컬 신뢰 결정이 TCP 기반 TLS 연결에서는 신뢰의 추가와 제거에 고려되고, QUIC 연결에서는 로컬 결정 중 신뢰 제거만 고려된다는 세부 차이도 설명되어 있습니다. 따라서 사설 PKI를 사용하는 환경에서는 TCP와 QUIC 동작, 브라우저 정책과 실제 배포 방식을 함께 시험해야 합니다.

Chrome에서 목록을 확인하는 방법

Chrome이 실제로 사용하는 Chrome Root Store의 내용을 확인하려면 다음 내부 페이지를 사용할 수 있습니다.

chrome://system

페이지에서 chrome_root_store 항목을 펼치면 현재 Chrome이 인식하는 Root Store 정보를 확인할 수 있습니다.

 

인증서 관리는 다음 페이지에서 접근할 수 있습니다.

chrome://certificate-manager

Chrome 버전과 운영체제에 따라 화면 구성과 제공 기능은 다를 수 있습니다. 공개 루트 목록, 로컬에서 추가된 인증서와 운영체제가 관리하는 인증서를 같은 것으로 해석하지 않는 것이 중요합니다.

Firefox는 Mozilla Root Store를 중심으로 동작한다

Firefox는 오랫동안 Mozilla가 관리하는 자체 루트 인증서 목록을 사용해 왔습니다. Mozilla Root Store에 들어갈 CA는 Mozilla Root Store Policy와 CA Certificate Program의 요구사항을 따라야 합니다.

 

이 때문에 같은 컴퓨터에서 Chrome은 정상인데 Firefox에서 SEC_ERROR_UNKNOWN_ISSUER가 발생하는 사례가 있었습니다. 운영체제에는 회사의 사설 CA가 등록되어 있지만 Firefox가 이를 사용하지 않는 환경이 대표적입니다.

 

최근 Firefox는 Windows, macOS와 Android에서 운영체제에 추가된 제3자 루트 인증서를 자동으로 찾아 신뢰할 수 있는 기능을 기본 제공하고 있습니다. Firefox 120부터 관련 동작이 일반 사용자에게도 기본 활성화되었습니다.

 

설정에서는 다음 항목으로 관리할 수 있습니다.

설정
  └── 개인정보 및 보안
        └── 인증서
              └── 설치한 제3자 루트 인증서를 Firefox가 자동으로 신뢰하도록 허용

기업 환경에서는 security.enterprise_roots.enabled 설정이나 Firefox Enterprise Policy를 사용할 수 있습니다. Linux에서는 배포판의 PKI 구조와 p11-kit 연동 여부를 별도로 확인해야 합니다.

 

Firefox의 동작을 정리하면 다음과 같습니다.

• 공개 웹의 기본 신뢰 기준은 Mozilla Root Store입니다.
• 운영체제나 조직이 추가한 제3자 CA도 설정과 플랫폼에 따라 사용할 수 있습니다.
• Firefox의 인증서 관리자에서 별도 CA를 가져올 수도 있습니다.
• 공개 Root Store와 조직의 사설 CA는 서로 다른 신뢰 출처입니다.

Safari는 Apple 운영체제의 신뢰 저장소를 사용한다

Safari는 Apple 플랫폼의 Root Store와 인증서 검증 체계를 사용합니다. Apple은 iOS, iPadOS, macOS, tvOS, visionOS와 watchOS에서 사용할 루트 인증서 목록을 관리하고 공개합니다.

 

Apple 운영체제는 공유 Root Store를 사용하며, Apple 지원 문서에서 운영체제 버전별 신뢰 루트와 차단된 인증서를 확인할 수 있습니다.

 

macOS에서는 키체인 접근 또는 시스템 설정을 통해 인증서를 볼 수 있습니다.

응용 프로그램
  └── 유틸리티
        └── 키체인 접근
              └── 시스템 루트 / 시스템 / 로그인

세 키체인은 의미가 다릅니다.

• 시스템 루트: Apple이 기본 제공하는 루트 인증서
• 시스템: 장비 전체에 설치된 조직·관리자 인증서
• 로그인: 현재 사용자에게 설치된 인증서

조직은 MDM 구성 프로파일을 통해 사설 루트 CA를 배포할 수 있습니다. 사용자가 수동으로 설치한 인증서는 플랫폼 정책에 따라 추가 신뢰 설정이 필요할 수 있습니다.

 

Chrome for iOS도 예외가 아닙니다. Apple의 플랫폼 정책 때문에 iOS용 Chrome은 Chrome Root Store와 Chrome Certificate Verifier를 사용하지 못하며 Apple의 인증서 검증 체계에 의존합니다. 따라서 이름은 Chrome이지만 데스크톱 Chrome과 Root Store 동작이 같다고 보면 안 됩니다.

Windows Root Store와 Edge는 어떻게 다를까?

Windows는 Microsoft Trusted Root Certificate Program을 통해 신뢰 루트와 신뢰하지 않는 인증서 목록을 배포합니다. Windows와 응용 프로그램은 Certificate Trust List, 즉 CTL을 인증서 신뢰 판단에 활용합니다.

 

Windows에는 대략 다음과 같은 인증서 저장 범위가 있습니다.

• 로컬 컴퓨터
• 현재 사용자
• 그룹 정책
• 엔터프라이즈
• 신뢰할 수 있는 루트 인증 기관
• 신뢰할 수 없는 인증서

관리 도구는 다음처럼 나뉩니다.

certmgr.msc   # 현재 사용자 인증서
certlm.msc    # 로컬 컴퓨터 인증서

Windows는 Windows Update 기반 자동 메커니즘으로 Trusted CTL과 Untrusted CTL을 갱신할 수 있습니다. Microsoft 문서에 따르면 자동 업데이트를 비활성화할 수도 있지만 보안상 권장되지 않습니다.

 

주의할 점은 Windows 인증서 관리 화면에 보이는 모든 공개 루트가 반드시 파일 형태로 미리 설치되어 있다는 뜻은 아니라는 것입니다. CTL과 자동 루트 업데이트 메커니즘을 통해 필요할 때 신뢰 정보와 인증서가 공급될 수 있습니다.

 

Edge 역시 Chromium 기반이지만 제품 정책과 플랫폼 통합 지점까지 Chrome과 완전히 동일하다고 단정해서는 안 됩니다. 특히 기업 환경에서는 Edge 정책, Windows 인증서 저장소, 공개 Root Store와 로컬 CA 적용 여부를 실제 대상 버전에서 확인해야 합니다.

브라우저마다 신뢰 결과가 달라지는 이유

같은 사이트인데 어떤 브라우저에서는 정상이고 다른 브라우저에서는 경고가 발생할 수 있습니다.

원인	설명
Root Store 차이	한 프로그램에는 루트 CA가 있고 다른 프로그램에는 없을 수 있음
중간 인증서 누락	서버가 완전한 체인을 보내지 않아 브라우저별 보완 결과가 달라짐
경로 구성 차이	교차 서명 인증서가 여러 개일 때 선택한 경로가 다름
로컬 CA 연동 차이	운영체제에 추가된 사설 CA를 읽는 방식이 다름
폐기 정보 차이	CRL, OCSP, 브라우저별 차단 목록 적용 방식이 다름
추가 보안 정책	CT, 알고리즘, 인증서 수명과 이름 제약 적용이 다름
제품·OS 버전	Root Store와 검증 로직의 갱신 시점이 다름

오류가 발생했을 때 루트 인증서를 바로 설치하는 것은 좋은 첫 대응이 아닙니다. 먼저 서버가 올바른 인증서 체인을 제공하는지 확인해야 합니다.

 

다음 순서로 조사하는 편이 안전합니다.

1. 접속한 호스트 이름과 인증서의 SAN이 일치하는지 확인합니다.
2. 서버 인증서의 유효기간을 확인합니다.
3. 서버가 필요한 중간 인증서를 모두 보내는지 확인합니다.
4. 체인이 어떤 루트 CA로 연결되는지 확인합니다.
5. 해당 루트가 브라우저의 공개 Root Store 또는 승인된 로컬 저장소에 있는지 확인합니다.
6. 보안 프록시나 백신이 HTTPS를 중간에서 재서명하는지 확인합니다.
7. 브라우저·운영체제·Root Store 업데이트 상태를 확인합니다.

회사 PC에 사설 루트 CA가 추가되는 이유

기업 환경에서는 공개 CA만으로 해결하기 어려운 경우가 있습니다.

• 사내 도메인과 내부 서비스에 인증서 발급
• 개발·테스트 환경의 TLS 적용
• 장비 인증과 상호 TLS
• 보안 프록시의 HTTPS 검사
• DLP, 악성코드 분석과 접근 통제

특히 HTTPS 검사 장비는 클라이언트와 외부 사이트 사이에서 TLS 연결을 두 개로 나눕니다.

브라우저 ← TLS 1 → 보안 프록시 ← TLS 2 → 외부 웹사이트

보안 프록시는 외부 사이트 인증서를 확인한 뒤, 접속 도메인에 대한 새 인증서를 실시간으로 만들어 브라우저에 제공합니다. 브라우저가 이 인증서를 경고 없이 받아들이려면 보안 프록시의 루트 CA가 클라이언트의 신뢰 저장소에 설치되어 있어야 합니다.

 

이는 운영상 필요한 통제가 될 수 있지만 매우 강한 권한입니다. 해당 루트 CA의 개인키를 가진 시스템은 관리 대상 장비에서 다양한 HTTPS 사이트의 인증서를 만들어낼 수 있기 때문입니다.

 

사설 루트 CA를 배포할 때는 최소한 다음 통제가 필요합니다.

• 루트 CA 개인키를 HSM이나 오프라인 환경에서 보호
• 실제 발급은 제한된 중간 CA가 수행
• 인증서 발급과 관리자 작업 감사
• 대상 장비와 사용 목적을 최소화
• 퇴사자·분실 장비·폐기 장비의 인증서와 정책 회수
• 만료와 교체 계획 수립
• TLS 검사 제외 대상과 개인정보 처리 기준 정의
• 장애 시 Root Store와 프록시 정책을 함께 점검

루트 CA가 목록에 들어가는 과정

공개 CA가 인증서 하나를 브라우저 회사에 보내면 바로 신뢰되는 것은 아닙니다.

 

일반적으로 다음과 같은 절차와 지속적인 의무가 필요합니다.

1. Root Program의 포함 요건을 충족합니다.
2. 인증서 정책인 CP와 인증 업무 준칙인 CPS를 공개합니다.
3. WebTrust 또는 ETSI 계열의 독립 감사를 받습니다.
4. 루트와 중간 CA 정보를 CCADB에 공개합니다.
5. 공개 검토와 질의에 대응합니다.
6. CA/Browser Forum Baseline Requirements를 준수합니다.
7. 인증서 오발급과 보안 사고를 보고하고 대응합니다.
8. 포함 이후에도 정기 감사와 정책 준수를 계속합니다.

신뢰는 영구적인 권리가 아닙니다. 정책 위반, 인증서 오발급, 감사 실패, 개인키 침해나 불충분한 사고 대응이 발생하면 루트가 제한되거나 제거될 수 있습니다.

 

루트 CA가 제거되어도 이미 발급된 모든 인증서가 같은 순간에 똑같이 실패하는 것은 아닙니다. 브라우저 버전, Root Store 업데이트 상태, 교차 서명 경로, 인증서 발급 시점 제약과 로컬 정책에 따라 결과가 달라질 수 있습니다.

Root Store 업데이트가 보안 업데이트인 이유

Root Store 변경은 단순한 인증서 목록 정리가 아닙니다.

 

새로운 CA를 추가하면 그 CA가 발급한 인증서가 기본적으로 신뢰될 수 있습니다. 반대로 문제가 있는 CA를 제거하면 공격자가 잘못 발급받은 인증서를 사용하더라도 브라우저가 신뢰하지 않게 만들 수 있습니다.

 

업데이트가 중단된 브라우저나 운영체제에는 다음 문제가 생길 수 있습니다.

• 새 루트 CA를 사용하는 정상 사이트 접속 실패
• 제거된 CA를 계속 신뢰
• 새로운 인증서 제약과 차단 정책 미적용
• 오래된 알고리즘과 검증 로직 사용
• 사설 PKI 변경 사항과의 불일치

폐쇄망에서는 브라우저 자동 업데이트와 Windows CTL 업데이트가 차단되기 쉽습니다. 이때는 브라우저 실행 파일만 배포하는 것으로 충분한지, Root Store 컴포넌트와 신뢰하지 않는 인증서 목록까지 갱신되는지를 별도로 확인해야 합니다.

운영자가 확인해야 할 핵심 질문

Root Store 문제를 다룰 때는 “인증서가 설치되어 있는가?”라는 질문만으로 부족합니다.

확인할 질문	이유
이 브라우저의 공개 신뢰 목록은 누가 관리하는가?	Chrome, Mozilla, Apple, Microsoft의 프로그램이 다름
현재 플랫폼에서 자체 Store와 OS Store 중 무엇을 쓰는가?	같은 브라우저도 플랫폼별 차이가 존재
조직이 추가한 로컬 CA가 어느 범위에 설치되었는가?	사용자, 장비, 그룹 정책 적용 범위가 다름
해당 CA는 TLS 서버 인증 용도로 신뢰되는가?	인증서가 있어도 용도 제한으로 실패할 수 있음
Root Store와 차단 목록은 어떻게 갱신되는가?	폐쇄망과 업데이트 차단 환경에서 중요
서버가 중간 인증서를 올바르게 보내는가?	가장 흔한 체인 오류 중 하나
HTTPS 검사 장비가 인증서를 재서명하는가?	브라우저가 보는 발급자가 원래 CA와 달라질 수 있음
루트 CA 개인키와 발급 시스템은 안전한가?	사설 CA 침해는 조직 전체 TLS 신뢰에 영향

결론: 브라우저의 자물쇠는 신뢰 목록과 정책의 결과다

브라우저는 전 세계 모든 인증서를 미리 알고 있는 것이 아닙니다. 신뢰할 수 있다고 판단한 루트 CA를 시작점으로 서버 인증서까지 이어지는 체인을 검증합니다.

 

Chrome은 자체 Chrome Root Store와 인증서 검증기를 사용하면서 조직이 배포한 로컬 신뢰도 고려합니다. Firefox는 Mozilla Root Store를 중심으로 동작하지만 운영체제에 추가된 제3자 루트도 활용할 수 있습니다. Safari와 iOS용 Chrome은 Apple 플랫폼의 신뢰 저장소와 검증 체계에 의존합니다. Windows는 Microsoft Root Certificate Program과 CTL 업데이트 메커니즘으로 시스템의 신뢰 정보를 관리합니다.

 

결국 HTTPS의 자물쇠는 암호화 알고리즘 하나만으로 만들어지는 것이 아닙니다.

어떤 인증기관을 신뢰할지 정하는 Root Program, 장비에 배포된 Root Store, 서버가 제공한 인증서 체인, 브라우저의 검증 정책과 조직의 로컬 신뢰 결정이 함께 만든 결과다.

인증서 오류를 해결할 때 무작정 루트 인증서를 설치하기보다, 어느 Root Store가 사용되고 있는지와 체인이 왜 신뢰되지 않는지를 먼저 확인해야 합니다. 특히 사설 CA와 HTTPS 검사 환경에서는 편의성을 위해 추가한 신뢰가 어느 범위까지 권한을 갖는지 함께 관리해야 합니다.

---

참고한 공식 자료

• Chrome Root Store FAQ
• Chrome Root Program Policy
• Mozilla: Automatically trust third-party root certificates
• Mozilla: Set up Certificate Authorities in Firefox
• Apple: Available root certificates for Apple operating systems
• Microsoft: Certificates and Trust Management in Windows
• Microsoft Root Certificate Program