현행 Web PKI는 브라우저가 서버 인증서의 서명 체인을 검증하고, 그 체인이 신뢰된 Root CA까지 이어지는지 확인하는 방식으로 동작한다. 그러나 CA가 잘못된 인증서를 발급하더라도 그 발급 사실이 외부에 공개되지 않는다면, 도메인 관리자는 해당 인증서가 실제 공격에 사용되거나 별도의 경로로 발견되기 전까지 문제를 인지하지 못할 수 있다.

 

Certificate Transparency(CT)는 이 문제를 보완하기 위해 만들어진 공개 감사용 인증서 로그 생태계로 인증서 발급 사실을 공개 로그에 남기고 그 로그 자체도 암호학적으로 검증할 수 있게 만드는 구조이다. CA가 발급하는 인증서 또는 precertificate를 외부에서 조회 가능한 공개 로그에 기록함으로써, 도메인 관리자와 보안 연구자, 브라우저가 특정 도메인에 어떤 인증서가 발급되었는지 확인할 수 있게 한다. 

 

여기서 공개 로그는 단순히 인터넷에서 검색할 수 있는 인증서 데이터베이스를 의미하지 않는다. 각 로그는 특정 Log Operator가 운영하지만, 기록된 인증서 목록과 로그의 상태를 외부에 공개하고, Merkle Tree 기반 증명을 통해 특정 인증서가 실제 로그에 포함되었는지와 과거 기록이 삭제·변조되지 않은 채 유지되는지를 누구나 검증할 수 있도록 설계된다.

 

즉 CT는 인증서 오발급 자체를 사전에 차단하는 제도라기보다 인증서 발급을 CA와 신청자만 알고 있는 비공개 사건으로 남겨두지 않고, 여러 독립적인 주체가 관찰하고 감사할 수 있는 공개적이고 암호학적으로 검증 가능한 기록으로 바꾼다.

 

이 글에서는 CT가 왜 필요한지부터 인증서와 precertificate가 공개 로그에 기록되는 과정, SCT·Signed Tree Head·Inclusion Proof·Consistency Proof의 의미를 살펴본다. 또한 CA, Log Operator, Monitor, User Agent, Domain Owner가 공개 로그를 중심으로 어떻게 역할을 나누고, 인증서 발급과 로그 운영을 감시하는지 설명한다.

 

CT가 등장하기 전의 문제

Web PKI에서는 수많은 CA가 공개적으로 신뢰되는 인증서를 발급할 수 있다. 이 구조는 확장성이 높지만, 신뢰된 CA 중 하나가 잘못된 인증서를 발급하면 해당 인증서도 정상적인 체인을 가질 수 있다는 위험이 있다.

 

예를 들어 다음 상황을 생각할 수 있다.

공격자가 특정 도메인의 DNS 검증 경로를 일시적으로 장악한다.
→ 신뢰된 CA에서 공격자용 인증서를 발급받는다.
→ 브라우저는 정상 CA 체인으로 이어지는 인증서로 판단할 수 있다.

 

CT 이전에는 이러한 발급 사실이 CA와 인증서 신청자 사이에만 머물렀다. 도메인 소유자가 모든 CA의 발급 내역을 직접 확인할 공통된 공개 데이터가 없었기 때문이다. 즉, 도메인 소유자가 아닌 신청자가 CA로부터 인증서를 발급받는데 성공하는 치명적인 사건이 발생했을 때 특별한 일이 없다면 누구도 이 사실을 알아챌 수 없고, 곧바로 대응하지 못하는 구조였다.

 

따라서 CT는 발급 사실을 공개 로그에 기록하도록 만들어 다음 질문에 답할 수 있게 한다.

이 도메인에 어떤 인증서가 발급되었는가?
어느 CA가 언제 발급했는가?
이 인증서가 공개 로그에 실제로 포함되었는가?
로그는 과거 기록을 삭제하거나 바꾸지 않았는가?

 

CT의 핵심 목표

CT의 목적은 다음 세 가지로 정리할 수 있다.

1. 발급 사실의 가시성
  - 인증서 또는 precertificate를 공개 로그에 기록해 도메인 소유자와 제3자가 발급 내역을 관찰할 수 있게 한다.

2. CA 활동의 감사 가능성
  - CA가 어떤 도메인에 어떤 인증서를 발급했는지 외부에서 확인할 수 있게 한다.

3. 로그 자체의 검증 가능성
  - 로그 운영자가 기록을 몰래 삭제하거나 과거 상태를 바꾸지 않았는지 Merkle Tree 증명을 통해 검증할 수 있게 한다.

 

CT는 "로그 운영자를 무조건 믿어라"는 구조가 아니다. 로그가 올바르게 행동했는지 외부에서 검증할 수 있는 기준 자료를 제공한다.

CT 로그 메커니즘

CT 흐름은 단순히 완성된 인증서를 데이터베이스에 저장하는 과정이 아니다. 일반적으로 precertificate 제출, SCT 발급, 최종 인증서 제공, 실제 로그 포함과 검증 단계가 이어진다.

인증서 발급 기록이 CT 로그로 저장되는 흐름

 

1. CA가 precertificate를 만든다

CA는 최종 인증서를 발급하기 전에 CT 로그 제출용 precertificate를 생성할 수 있다.

Precertificate에는 최종 인증서에 들어갈 주요 정보가 포함된다.

  • 도메인 이름
  • 사이트 공개키
  • 발급자
  • 유효 기간
  • 인증서 확장 정보

Precertificate는 로그에 제출하기 위한 중간 산출물이다. 브라우저가 일반적인 서버 인증서로 그대로 사용하는 최종 인증서와는 구분된다.

2. CA가 하나 이상의 CT 로그에 제출한다

CA는 precertificate 또는 허용된 형태의 인증서 엔트리를 CT 로그에 제출한다.

CA
→ CT Log A
→ CT Log B
→ CT Log C

 

여러 로그를 사용하는 이유는 하나의 로그 운영자에만 의존하지 않고, 브라우저의 CT 정책이 요구하는 로그 다양성과 가용성을 만족하기 위해서다.

3. 로그가 SCT를 반환한다

CT 로그는 제출을 수락하면 SCT(Signed Certificate Timestamp)를 반환한다. SCT에는 개념적으로 다음 정보가 포함된다.

SCT
├─ Log ID
├─ Timestamp
├─ Entry 관련 정보
├─ Extensions
└─ Log Operator Signature

 

 

SCT는 다음을 의미한다.

이 로그는 해당 인증서 엔트리를 정해진 최대 병합 지연 시간 안에 로그에 포함하겠다고 약속한다.

 

즉 SCT는 이미 로그에 포함되었다는 증명이 아니다. 미래의 포함을 약속하는 서명된 영수증에 가깝다.

4. SCT를 클라이언트에 제공한다

CA와 서버는 SCT를 여러 방식으로 브라우저에 전달할 수 있다.

  • 인증서 안에 포함
  • TLS 확장을 통해 전달
  • OCSP 응답에 포함

브라우저는 자신이 적용하는 CT 정책에 따라 SCT의 출처, 개수, 허용 로그, 인증서 수명 등 여러 조건을 확인할 수 있다.

5. 로그가 인증서를 Merkle Tree에 실제 포함한다

로그 운영자는 SCT에서 약속한 시간 안에 인증서 엔트리를 append-only Merkle Tree에 포함해야 한다.

SCT 발급
≠ 실제 포함 완료

실제 포함
= 인증서 엔트리가 Merkle Tree의 leaf로 추가됨

 

SCT를 발급하고도 정해진 시간 안에 로그에 포함하지 않으면 로그의 위반 행위로 탐지될 수 있다.

 

CT 프로토콜

CT Protocol
├─ 인증서 제출
├─ SCT
├─ Merkle Tree
├─ STH
├─ Inclusion Proof
└─ Consistency Proof

 

CT 프로토콜은 인증서 발급 및 제출 매커니즘뿐 아니라 이러한 로그가 적절하게 운영되기 위해 필요한 여러 논리적 장치들을 포함한다.

append-only와 Merkle Tree

CT 로그는 기존 기록을 수정하거나 삭제하는 일반 데이터베이스처럼 동작해서는 안 된다. 즉 append-only 속성을 가져야만 한다.

  • 기존 엔트리 삭제
  • 기존 엔트리 내용 변경
  • 과거 순서 재배치

위와 같은 동작을 감지하고 암호학적으로 검증하기 위해 CT는 Merkle Tree를 사용한다.

 

 

Merkle Tree에서는 각 인증서 엔트리를 해시하고, 두 해시를 다시 묶어 상위 해시를 만드는 과정을 반복해 하나의 Merkle Root를 계산한다. 인증서 하나의 바이트가 바뀌어도 최종 Root가 달라지므로, 로그 상태의 변조를 탐지할 수 있다.

Signed Tree Head

로그는 특정 시점의 트리 상태를 Signed Tree Head(STH)로 공개한다.

Signed Tree Head
├─ Tree Size
├─ Merkle Root Hash
├─ Timestamp
└─ Log Operator Signature

 

각 필드의 의미는 다음과 같다.

  • Tree Size: 해당 시점까지 포함된 로그 엔트리 수
  • Merkle Root Hash: 전체 트리 상태를 대표하는 루트 해시
  • Timestamp: 로그 상태가 생성된 시각
  • Signature: 로그 운영자의 개인키로 만든 서명

STH는 "이 로그는 이 시점에 이 크기와 Root를 가진 트리 상태를 공개했다"는 서명된 체크포인트다. Monitor와 검증 주체는 STH를 기준으로 인증서 포함 여부와 이전 상태와의 일관성을 검증한다.

 

Inclusion Proof

Inclusion Proof는 특정 인증서 엔트리가 특정 STH가 나타내는 Merkle Tree에 실제로 포함되었음을 증명한다. 전체 트리를 전부 내려받을 필요 없이 해당 leaf에서 Merkle Root를 계산하는 데 필요한 sibling hash 목록만 있으면 된다.

Certificate Entry
+ Merkle Audit Path
  → 계산된 Merkle Root

계산된 Root == STH의 Merkle Root
  → 해당 인증서가 그 트리에 포함됨

 

따라서 SCT와 inclusion proof는 역할이 다르다.

항목 역할
SCT 정해진 시간 안에 포함하겠다는 로그의 서명된 약속
Inclusion Proof 인증서가 특정 로그 상태에 실제 포함되었다는 암호학적 증명

 

Consistency Proof

Consistency Proof는 두 개의 서로 다른 트리 상태를 비교해, 새로운 트리가 이전 트리의 모든 기록을 유지하면서 뒤에 새 엔트리만 추가한 결과임을 증명한다. 즉 과거 기록이 변경 없이 유지되었는지를 나타낸다.

이전 STH
Tree Size: 1,000

현재 STH
Tree Size: 1,500

 

검증에 성공하면 다음을 알 수 있다.

과거 1,000개 엔트리가 그대로 유지됨
+
새로운 500개 엔트리만 추가됨

 

즉 consistency proof는 CT 로그의 append-only 성질을 검증하는 장치다.

만약 로그가 과거 인증서를 삭제하거나 변경했다면 사실상 이전 Root와 새로운 Root 사이의 올바른 consistency proof가 나올 수 없다.

Maximum Merge Delay

로그는 SCT를 발급한 뒤 트리에 포함되는 것을 무한정 미룰 수 없다. 각 로그에는 인증서 엔트리를 실제 트리에 반영해야 하는 최대 시간이  존재하는데 이 시간을 Maximum Merge Delay(MMD)라고 한다.

SCT 발급 시각 + MMD
  → 이 시점까지 인증서가 로그에 포함되어야 함

 

Monitor는 SCT가 발급된 인증서가 MMD 안에 실제 포함되었는지 확인할 수 있다.

SCT
→ 로그가 포함을 약속했다는 의미

MMD 이후 inclusion proof 확인
→ 로그가 약속을 실제로 이행했다는 의미

 

CT 생태계 구성 요소

CT는 하나의 중앙 서비스가 아니라 여러 주체가 역할을 나누는 생태계다.

https://certificate.transparency.dev/community/

 

Community : Certificate Transparency

Our Story Thank you to our amazing community Certificate Transparency works thanks to the ecosystem of people and organizations who set up and run user agents, logs and monitors. Join us! Join Google Group

certificate.transparency.dev

CT 생태계 역할 분담

Certificate Authorities

CA는 인증서 또는 precertificate를 CT 로그에 제출하고 SCT를 받아 인증서 발급 과정에 사용한다. 주요 책임은 다음과 같다.

  • 올바른 인증서 엔트리 제출
  • 브라우저 정책을 만족하는 SCT 확보
  • 최종 인증서와 SCT의 일관성 유지
  • 발급 인증서가 CT 요구사항을 만족하도록 관리

Log Operators

Log Operator는 CT 로그를 운영한다.

  • 인증서 제출 수신
  • SCT 발급
  • MMD 안에 엔트리 포함
  • STH 공개
  • Inclusion Proof 제공
  • Consistency Proof 제공
  • 로그의 가용성과 무결성 유지

Log Operator는 인증서가 안전한지 승인하는 주체가 아니다. 제출된 인증서를 투명하게 기록하고 검증 가능한 로그 상태를 제공하는 역할이다.

Monitors

Monitor는 CT 로그와 인증서 발급을 지속적으로 감시한다. Monitor의 역할은 두 범주로 나눌 수 있다.

인증서 모니터링

  • 특정 도메인의 새 인증서 탐지
  • 예상하지 못한 CA 발급 탐지
  • 와일드카드·서브도메인 인증서 확인
  • 만료 예정 인증서와 중복 발급 분석
  • 조직 정책에 맞지 않는 인증서 식별

로그 모니터링

  • SCT를 발급한 인증서가 MMD 안에 포함되었는지 확인
  • STH 간 consistency proof 검증
  • 로그가 일부 사용자에게 다른 트리 상태를 보여주는지 감시
  • 로그 가용성과 비정상 동작 탐지

User Agents

User Agent는 일반적으로 브라우저와 같은 클라이언트다. 브라우저는 자체 CT 정책에 따라 다음을 확인할 수 있다.

  • SCT 서명이 유효한가
  • SCT를 발급한 로그가 허용된 로그인가
  • 필요한 SCT 개수를 만족하는가
  • 로그 다양성 정책을 만족하는가
  • 인증서 수명과 발급 시점에 맞는 CT 조건을 만족하는가

구체적인 정책은 브라우저와 시점에 따라 달라질 수 있다. 따라서 "CT 로그에 하나만 기록되면 항상 신뢰된다"라고 단순화해서는 안 된다.

Domain Owners와 보안 운영자

도메인 소유자는 CT 검색과 모니터링을 통해 자신의 도메인에 발급된 인증서를 확인한다.

우리 조직이 요청하지 않은 인증서가 있는가?
허용하지 않은 CA가 인증서를 발급했는가?
예상하지 않은 서브도메인이 포함됐는가?
갱신·교체 과정이 계획대로 진행됐는가?

 

도메인 소유자는 CT 생태계가 제공하는 공개 데이터를 실제 보안 대응으로 연결하는 주체다.

연구자와 보안 서비스

공개 CT 데이터는 다음과 같은 분석에도 사용된다.

  • CA별 발급 패턴 분석
  • 피싱 인프라와 유사 도메인 탐지
  • 인증서 오발급 연구
  • 인터넷 자산 탐색
  • 로그 운영 이상 분석
  • 인증서 생태계 변화 추적

 

Split View와 로그 감시

악의적인 로그가 서로 다른 사용자에게 서로 다른 트리 상태를 보여주는 상황을 split view라고 생각할 수 있다.

사용자 A에게 보여준 STH ≠ 사용자 B에게 보여준 STH

 

로그가 특정 공격용 인증서를 일부 대상에게만 보이게 하고, 일반 Monitor에게는 숨기는 시나리오가 가능하다면 투명성의 목적이 무너진다.

 

이를 탐지하려면 여러 주체가 STH를 비교하고, 일관성 증명을 교환하며, 로그 상태를 감시해야 한다. 이러한 정보 교환은 gossip 계열 메커니즘과 연결된다.

 

추가로 이런 공개 로그 데이터를 색인해 CT 검색 API를 제공하는 다음 서비스도 이런 감시에 기여한다.

  • Censys Certificates
  • SSLMate
  • CertStream
  • Google Certificate Transparency Report
  • crt.sh

 

CT의 보안은 로그의 암호학적 구조만으로 완성되지 않는다. 서로 독립적인 Monitor와 User Agent가 로그 상태를 비교하고 이상을 발견하는 운영 생태계가 함께 필요하다.

 

CT가 보장하는 것과 보장하지 않는 것

CT가 제공하는 것

  • 인증서 발급 사실의 공개 가시성
  • 특정 인증서의 로그 포함 여부를 검증할 수 있는 기반
  • 로그가 append-only인지 확인할 수 있는 증명
  • CA와 로그 운영자의 행동을 외부에서 감사할 수 있는 데이터
  • 도메인별 인증서 모니터링 기반

CT가 보장하지 않는 것

  • 해당 인증서가 안전하다는 사실
  • 도메인 관리자가 인증서를 승인했다는 사실
  • 인증서 발급이 조직 내부 정책을 통과했다는 사실
  • 현재 서버가 해당 인증서를 실제 사용 중이라는 사실
  • 인증서 개인키가 탈취되지 않았다는 사실
  • 서버가 침해되지 않았다는 사실
  • 피싱 도메인이 아니라는 사실

CT 로그에 존재한다는 것은 인증서 발급 사실이 공개되었다는 의미이지, 인증서가 정상 사용을 승인받았다는 의미가 아니다.

 

CT가 Web PKI에 추가한 신뢰

Web PKI와 CT가 해결하고자 하는 문제는 다르다.

Web PKI:
이 인증서가 신뢰된 CA 체인과 브라우저 정책을 만족하는가?

Certificate Transparency:
이 인증서 발급 사실이 공개 로그에 기록되고 로그 상태를 외부에서 감사할 수 있는가?

 

따라서 CT는 CA 기반 신뢰를 대체하는 것이 아니라 기존 Web PKI 위에서 발급 투명성과 감사 가능성을 추가한다.

 

이 구조 덕분에 도메인 관리자는 자신이 요청하지 않은 인증서를 더 빠르게 발견할 수 있고, 브라우저는 CA와 로그 운영자의 이상 행동을 감시할 수 있다.

CT의 한계

Certificate Transparency의 핵심은 단순히 인증서를 누구나 검색할 수 있게 만드는 것이 아니다.

인증서 제출
→ SCT라는 포함 약속
→ Merkle Tree에 실제 포함
→ STH로 로그 상태 공개
→ Inclusion Proof로 개별 포함 검증
→ Consistency Proof로 append-only 검증
→ Monitor와 User Agent가 지속적으로 감시

 

CT는 인증서 발급을 공개 사건으로 만들고, 로그 운영자까지 감사 대상으로 포함한다.

 

그러나 CT가 보여주는 것은 어디까지나 어떤 인증서가 발급되고 기록되었는가이다. 그 인증서가 실제 도메인 관리자의 검토와 승인을 거쳤는지, 현재 운영 환경에서 사용을 허용받았는지는 별도의 문제다.

 

즉, 발급된 인증서와 승인된 인증서는 다르다.

 

여전히 존재하는 신뢰 공백을 채우기 위해 도메인 관리자 승인 기반 추가 검증 프로세스를 다음 설명하겠다.

 

발급된 인증서와 승인된 인증서는 다르다

참고 자료

'cs > web' 카테고리의 다른 글

발급된 인증서와 승인된 인증서: 도메인 관리자 승인 기반 추가 검증 프로세스 제안  (0) 2026.06.24
브라우저는 HTTPS 인증서를 어떻게 신뢰하는가: 현행 Web PKI와 TLS 인증서 검증  (0) 2026.06.23

티스토리툴바