본문으로 건너뛰기

Root 인증서와 신뢰 체인

I. 3단계 계층​

인증서는 보통 3계층 체인으로 발급됩니다.

[Root CA 인증서] ← self-signed(자기 서명), 신뢰의 최상위 "앵커"
│ 서명
▼
[Intermediate CA 인증서] ← Root가 서명, 실제 발급 업무 담당
│ 서명
▼
[Leaf(End-entity) 인증서] ← 우리 서버의 인증서 (example.com)
계층특징
Root CA자기 자신이 서명(self-signed). OS·브라우저에 미리 내장. 개인키는 오프라인 금고 수준 보관
Intermediate CARoot가 서명. 실제 인증서 발급을 담당. 여러 단계일 수 있음
Leaf최종 서버/도메인 인증서. 유효기간 짧음

II. 왜 중간 CA(Intermediate)를 두나​

Root로 직접 Leaf를 발급하지 않고 중간 단계를 두는 이유:

  • Root 개인키 보호: Root 키가 유출되면 그 CA가 발급한 모든 인증서가 무너짐. 그래서 Root는 오프라인 보관하고, 평소 발급은 중간 CA가 함
  • 피해 격리: 중간 CA가 손상되면 그 중간 CA만 폐기하면 됨(Root는 안전)
  • 운영 유연성: 용도·지역별로 중간 CA 분리 가능

III. 신뢰 체인 검증 과정​

브라우저가 서버 인증서를 받으면 Leaf → Root까지 거슬러 올라가며 검증합니다.

1) 서버가 [Leaf + Intermediate] 를 보냄 (풀체인)
2) Leaf의 서명을 Intermediate 공개키로 검증 ✔
3) Intermediate의 서명을 Root 공개키로 검증 ✔
4) Root가 "트러스트 스토어에 있는 신뢰된 Root"인가? ✔
5) 각 인증서의 유효기간·폐기상태·용도(EKU)·도메인(SAN) 확인 ✔
→ 모두 통과하면 신뢰 성립

이 과정을 경로 검증(path validation) 이라 하며, 핵심은 "각 단계의 서명을 상위 공개키로 검증" 하는 재귀 구조입니다.

:::caution 가장 흔한 실무 오류 — 중간 CA 누락 서버가 Leaf만 보내고 Intermediate를 안 보내면, 체인이 끊겨 일부 클라이언트에서 "신뢰할 수 없음" 오류가 납니다. 항상 풀체인(Leaf + Intermediate)으로 배포해야 합니다. (06. 실무) :::

IV. 트러스트 스토어 — 신뢰의 뿌리​

트러스트 스토어(Trust Store) 는 운영체제·브라우저가 "이 Root들은 믿는다"고 미리 담아둔 Root 인증서 목록입니다.

  • 관리 주체: Microsoft, Apple, Google(Chrome), Mozilla(Firefox) 등이 각자 Root 프로그램을 운영
  • Root CA가 여기 포함되려면 엄격한 감사(WebTrust 등)를 통과해야 함
  • 최종 신뢰의 근거: 체인이 아무리 그럴듯해도, 최상위 Root가 트러스트 스토어에 없으면 신뢰되지 않음
"신뢰"란 결국 → 내 기기의 트러스트 스토어에 있는 Root를 믿는다는 것

V. Root 인증서의 갱신·교체 (롤오버)​

Root는 매우 오래(보통 20~25년) 쓰도록 발급됩니다. 그래도 만료·알고리즘 교체·보안 사고로 교체가 필요합니다.

도전 과제: Root를 바꾸면 전 세계 기기의 트러스트 스토어가 새 Root를 담을 때까지 시간이 걸립니다(OS 업데이트 등). 그래서 다음 기법을 씁니다.

기법설명
사전 배포새 Root를 수년 전부터 OS·브라우저에 미리 포함시켜 둠
크로스 서명(Cross-signing)새 Root(또는 중간 CA)를 기존 신뢰된 Root로도 서명해, 구형 기기엔 옛 체인·신형 기기엔 새 체인이 동작
중첩 유효기간구·신 Root를 일정 기간 병행

:::info 실제 사례 — 체인 전환 Let's Encrypt의 Root/중간 CA 전환이나, 특정 Root 만료 시점에 구형 기기에서 갑자기 인증서 오류가 나는 일이 크로스 서명·롤오버와 관련됩니다. 서버 운영자는 CA가 안내하는 새 체인으로 교체해 주면 됩니다. :::

Leaf 갱신 vs Root 갱신​

구분주기작업 주체
Leaf(서버) 인증서짧음(수십~수백 일, 축소 추세)서버 운영자(자동화 권장)
Intermediate수년CA
Root수십 년(드묾)CA + OS/브라우저 벤더

→ 서버 운영자가 일상적으로 신경 쓰는 "갱신"은 대부분 Leaf 갱신입니다. (05. 수명주기·갱신)

VI. 결론​

신뢰 체인은 Leaf → Intermediate → Root로 서명이 이어지고, 최종 신뢰는 기기의 트러스트 스토어에 있는 Root에 달려 있습니다. Root는 신뢰의 앵커이기에 강력히 보호·장기 운영되며, 교체 시엔 크로스 서명 등으로 호환성을 지킵니다.