정보관리기술사 학습 노트
← 목록으로
보안·개인정보
#인증서투명성#CT#SCT#머클트리#오발급탐지
최종 업데이트 · 2026-10-31

인증서 투명성(Certificate Transparency, CT)

1. 개요

가. 정의

인증서 투명성(Certificate Transparency, CT) 이란 공개적으로 신뢰되는 모든 TLS 서버 인증서의 발급 사실을, 누구나 열람할 수 있고 사후에 삭제·변조가 불가능한 공개 추가 전용 로그(public append-only log) 에 기록하게 하여, 인증 기관(CA)의 오발급(mis-issuance) 을 사실상 숨길 수 없게 만드는 공개 감시 체계이다. CT는 2013년 RFC 6962로 표준화되었고, 2021년 12월 RFC 9162(CT 2.0)로 개정되었으며, 핵심 기반 자료구조는 머클 해시 트리(Merkle Hash Tree) 이다.

기존 PKI는 "루트 저장소에 포함된 CA가 발급한 인증서라면 신뢰한다"는 가정 위에 서 있다. 그러나 이 신뢰는 CA가 올바르게만 행동한다는 전제에 전적으로 의존한다. 하나의 CA라도 침해되거나 실수·악의로 특정 도메인(예: google.com)에 대한 인증서를 소유자 동의 없이 발급하면, 공격자는 그 인증서로 정상 서버를 완벽하게 가장할 수 있다. 문제는 이런 오발급이 발급 시점에는 도메인 소유자조차 알 수 없다는 점이다. CT는 "신뢰를 제거"하는 것이 아니라, 모든 발급을 공개 기록으로 강제하여 오발급을 사후에라도 반드시 드러나게 함으로써 CA 생태계에 검증 가능한 책임성(verifiable accountability) 을 부여한다.

CT의 설계 철학은 "예방이 아니라 탐지(detection, not prevention)"로 요약된다. CT 자체가 오발급을 막지는 못한다. 대신 어떤 인증서가 발급되었는지를 전 세계가 동일하게 관찰할 수 있게 만들어, 오발급이 빠르게 발견되고 폐기·조치되도록 한다. 이는 보안을 '완벽한 성벽'이 아니라 '투명한 감사 로그'로 접근하는 전환이며, 블록체인과 유사하게 변조 불가능성(tamper-evidence) 을 암호학적으로 증명한다는 점에서 기술사 관점의 신뢰 모델 설계 사례로 중요하다.

나. 등장 배경과 필요성

CT의 직접적 계기는 2011년 네덜란드 CA인 DigiNotar 침해 사건이다. 공격자는 DigiNotar를 장악해 *.google.com을 포함한 500여 장의 부정 인증서를 발급했고, 이를 이용해 이란 사용자 수십만 명의 Gmail 트래픽을 중간자(MITM)로 가로챈 것으로 알려졌다. 이 사건에서 가장 충격적이었던 점은 부정 발급이 수 주 동안 탐지되지 않았다는 사실이다. 단 한 곳의 CA 실패가 전체 웹 신뢰를 무너뜨릴 수 있고, 피해 도메인의 소유자(Google)조차 자신의 이름으로 발급된 가짜 인증서의 존재를 즉시 알 수 없다는 구조적 공백이 드러났다.

이후 Google 엔지니어들이 주도해, "모든 발급을 공개 로그에 남기고 브라우저가 로그에 기록되지 않은 인증서를 거부하게 하면 오발급을 숨길 수 없다"는 아이디어를 RFC 6962로 구체화했다. 여기에 2015년 Symantec의 반복적 오발급(테스트 목적으로 google.com 등에 대한 인증서를 무단 발급)이 CT 로그를 통해 드러나면서, CT의 실효성이 입증되었다. 이 사건은 결국 Symantec CA 사업의 신뢰 철회(distrust)와 DigiCert로의 인수로 이어졌고, CT가 CA 거버넌스를 실질적으로 규율하는 장치임을 각인시켰다.

그 결과 Chrome은 2018년 4월 이후 발급된 모든 공개 신뢰 인증서에 대해 CT 준수를 강제하기 시작했고, Apple도 유사한 정책을 시행했다. 즉 오늘날 CT는 "선택적 모범 사례"가 아니라 공개 웹 PKI에 참여하기 위한 사실상의 필수 요건이다. 정보관리기술사 관점에서 CT는 TLS·PKI라는 인터넷 신뢰의 뿌리에 감시·투명성 계층을 덧댄 것으로, 하나의 표준 변화가 전 세계 CA·브라우저·서버 운영에 즉시 파급되는 생태계 거버넌스 문제로 이해해야 한다.

2. CT 생태계의 구성요소와 전체 구조

CT는 단일 시스템이 아니라 서로를 견제하는 여러 역할자의 분산 감시 생태계다. 아래 전체 구조도는 CA의 인증서 제출부터 로그 기록, 브라우저 검증, 그리고 모니터·감사자의 상시 감시까지의 관계를 보여준다. 어느 한 주체도 단독으로 신뢰를 독점하지 않고, 서로의 행위를 교차 검증한다는 점이 핵심이다.

flowchart TD
  CA["인증 기관(CA)"]
  LOG["CT 로그 서버(추가 전용·Merkle Tree)"]
  SERVER["대상 웹 서버(TLS 종단)"]
  BROWSER["브라우저(검증자·Relying Party)"]
  MONITOR["모니터(도메인 소유자·보안기업)"]
  AUDITOR["감사자(로그 일관성 검증)"]
  CA -->|"① 프리인증서 제출"| LOG
  LOG -->|"② SCT(기록 약속) 발급"| CA
  CA -->|"③ SCT 내장 인증서 발급"| SERVER
  SERVER -->|"④ TLS 핸드셰이크 + SCT 제시"| BROWSER
  BROWSER -->|"⑤ SCT 서명·정책 검증"| BROWSER
  LOG -->|"전체 로그 조회"| MONITOR
  MONITOR -->|"내 도메인 오발급 탐지·경보"| MONITOR
  AUDITOR -->|"포함·일관성 증명 요청"| LOG
  BROWSER -.->|"SCT 감사 협력"| AUDITOR
  style CA fill:#e8f0fe,stroke:#2f6fed,stroke-width:1px
  style LOG fill:#eafbea,stroke:#2f9e44,stroke-width:1px
  style BROWSER fill:#fef3e8,stroke:#ed8f2f,stroke-width:2px
  style MONITOR fill:#f3e8fe,stroke:#8f2fed,stroke-width:1px

가. 로그(Log)

CT 로그는 제출된 인증서를 시간 순서대로 덧붙이기만 하는 추가 전용(append-only) 서버로, 내부적으로 머클 해시 트리를 유지한다. 로그는 삭제·수정·재정렬이 불가능하도록 설계되며, 자신이 기록한 전체 상태를 STH(Signed Tree Head, 서명된 트리 머리) 로 서명해 공표한다. 로그 운영자는 Google(Argon·Xenon 계열), Cloudflare(Nimbus), DigiCert, Sectigo, Let's Encrypt(Oak) 등이며, 신뢰성 확보를 위해 여러 독립 운영자가 다수의 로그를 운영한다. 로그는 보통 1년 단위 샤드(shard) 로 분할 운영되어, 특정 연도에 만료되는 인증서만 받는 식으로 크기를 관리한다.

로그의 핵심 약속 중 하나가 MMD(Maximum Merge Delay, 최대 병합 지연) 로, 보통 24시간이다. 로그는 SCT를 발급한 시점부터 MMD 이내에 해당 인증서를 실제 머클 트리에 병합(포함)해야 한다. 이 약속 덕분에 SCT는 "지금 당장 트리에 들어있다"가 아니라 "MMD 안에 반드시 들어간다"는 기록 약속(promise) 으로 기능하며, 발급 지연 없이도 즉시 인증서를 쓸 수 있게 한다. 예컨대 로그가 SCT만 발급하고 실제 병합을 누락하면, 감사자가 포함 증명을 요청했을 때 증명에 실패하므로 로그의 부정이 드러난다.

나. SCT와 CA·서버

SCT(Signed Certificate Timestamp) 는 로그가 "이 인증서를 접수했고 MMD 내 기록하겠다"고 서명한 영수증이다. CA는 발급 전 프리인증서(precertificate) 를 로그에 제출해 SCT를 받고, 이 SCT들을 최종 인증서에 담아 발급한다. 프리인증서는 최종 인증서와 내용이 같되 포이즌 확장(poison extension) 이 들어가 있어 그 자체로는 TLS에 쓰일 수 없는 '기록용 사본'이다. 이렇게 하면 "인증서 안에 SCT를 넣어야 하는데, SCT를 받으려면 인증서를 먼저 로그에 넣어야 한다"는 순환 의존을 깔끔히 해소할 수 있다.

다. 모니터(Monitor)와 감사자(Auditor)

모니터는 로그 전체를 내려받아 "내가 관심 있는 도메인에 대해 내가 모르는 인증서가 발급되지 않았는가"를 상시 감시하는 역할자다. 대형 서비스 기업은 자사 도메인에 대한 모든 발급을 감시하고, crt.sh(Sectigo), Censys, Cloudflare 등은 누구나 검색할 수 있는 공개 모니터를 제공한다. 감사자는 주로 브라우저에 내장된 형태로, 로그가 제시한 STH와 증명을 받아 로그가 거짓말을 하지 않는지(두 사용자에게 서로 다른 로그를 보여주는 '분기(split-view)' 공격을 하지 않는지)를 검증한다. 모니터는 'CA의 정직성'을, 감사자는 '로그의 정직성'을 감시한다는 점에서 책임이 분리된다.

모니터와 감사자의 분리는 CT가 단일 실패점(single point of trust)을 두지 않는다는 원칙의 구체적 구현이다. 만약 감시 역할이 한 주체에 집중되면 그 주체가 침해·매수될 때 전체 투명성이 무너진다. 그래서 CT는 다수의 독립 모니터와, 브라우저라는 수십억 대의 분산 감사자를 동시에 운영한다. 어떤 CA가 오발급을 하더라도 어느 한 모니터만 깨어 있으면 적발되고, 어떤 로그가 거짓말을 하더라도 서로 STH를 교환하는 감사자가 하나만 정직하면 모순이 드러난다. 이처럼 "다수 중 하나만 정직해도 전체가 지켜진다"는 N분의 1 신뢰 모델이 CT 견고성의 수학적 바탕이다.

라. 로그의 신뢰성 확보 요건

로그가 생태계의 핵심인 만큼, 브라우저는 로그를 아무나 운영하도록 허용하지 않고 엄격한 포함 기준을 적용한다. 로그는 일정한 가용성(SLA), 명확한 운영 정책, 독립적 운영 주체, 그리고 상한 MMD 준수 등을 입증해야 공개 신뢰 로그 목록에 포함된다. 또한 브라우저는 하나의 운영자가 전체 SCT를 독점하지 못하도록 서로 다른 운영자의 로그에서 SCT를 받도록 요구한다(예: 한 개는 특정 벤더, 다른 하나는 그와 독립된 벤더). 이는 특정 로그 운영자가 사업을 접거나 신뢰를 잃어도 이미 발급된 인증서가 한꺼번에 무효화되지 않도록 하는 운영 다양성(operational diversity) 확보 장치다. 실제로 특정 로그가 규정 위반이나 장애로 '불신(distrust)' 처리된 전례가 있으며, 이때 해당 로그에만 의존하던 인증서는 재발급 압박을 받았다. 로그 운영은 곧 생태계 신뢰 인프라 운영이라는 점에서, 기술사 관점의 가용성·거버넌스 설계 대상이 된다.

3. 동작 원리: 로그 기록·SCT·암호학적 증명

CT의 신뢰는 머클 트리의 두 가지 증명, 즉 포함 증명(inclusion proof) 과 일관성 증명(consistency proof) 에서 나온다. 아래 상세 흐름도는 프리인증서 제출→SCT 발급→인증서 배포→브라우저 검증→모니터·감사의 전 과정을 순서대로 보여준다.

sequenceDiagram
  participant CA as CA
  participant Log as CT 로그
  participant Srv as 웹 서버
  participant Br as 브라우저
  participant Mon as 모니터
  CA->>Log: 프리인증서 제출(poison 확장)
  Log-->>CA: SCT 서명 반환(MMD 내 병합 약속)
  CA->>Srv: SCT 내장 인증서 발급
  Note over Log: MMD(24h) 내 Merkle Tree에 병합
  Br->>Srv: TLS 핸드셰이크 요청
  Srv-->>Br: 인증서 + SCT 제시
  Br->>Br: SCT 서명·개수·로그 정책 검증
  Mon->>Log: 전체 로그 주기적 조회
  Mon-->>Mon: 내 도메인 오발급 탐지 시 경보

가. 머클 트리와 포함 증명

로그의 모든 항목은 머클 트리의 잎(leaf)에 해시되어 들어가고, 잎들을 두 개씩 묶어 해시하는 과정을 반복해 단 하나의 루트 해시(Merkle Tree Hash) 로 수렴한다. 포함 증명이란 "특정 인증서가 이 루트에 실제로 포함되어 있다"를 증명하는 것으로, 전체 트리가 아니라 경로상의 형제 노드 해시들(log₂N개)만 제시하면 검증자가 루트를 재계산해 확인할 수 있다. 예를 들어 100만 건(2²⁰) 규모 로그라도 약 20개의 해시만으로 포함을 증명할 수 있어, 대규모 로그에서도 검증 비용이 로그적으로만 증가한다.

이 로그적 효율성은 CT가 수십억 장 규모로 확장될 수 있었던 결정적 이유다. 가령 전 세계 유효 인증서가 수억 장에 달하고 단기 인증서화로 발급 빈도가 급증하는 상황에서, 만약 포함 증명이 전체 트리 크기에 비례했다면 검증은 사실상 불가능했을 것이다. 머클 트리는 "전체를 다 보지 않고도 전체의 한 조각이 전체에 속함을 증명"하게 해 주며, 이 성질이 블록체인·Git·분산 백업 등 변조 탐지가 필요한 다른 분야에서도 동일하게 활용된다. CT의 포함 증명은 결국 [[merkle-tree]]가 제공하는 무결성 검증 원리를 '인증서 발급 투명성'이라는 구체적 문제에 적용한 사례로 이해할 수 있다.

나. 일관성 증명과 분기 공격 방어

일관성 증명은 "과거의 트리(크기 m)가 현재의 트리(크기 n, n>m)에 접두(prefix)로 그대로 포함되어 있다"를 증명한다. 이는 로그가 과거 기록을 삭제·수정하지 않고 오직 덧붙이기만 했음을 암호학적으로 보장한다. 만약 로그가 특정 감사자에게는 A라는 트리를, 다른 감사자에게는 A와 모순되는 B라는 트리를 보여주는 분기 공격(split-view) 을 시도하면, STH를 교차 공유하는 '가십(gossip) 프로토콜'을 통해 두 STH가 서로 일관성 증명을 만들 수 없음이 드러나 부정이 적발된다. 즉 로그조차 신뢰의 특권을 갖지 못하며, 수학적으로 정직을 강제당한다.

다. SCT 전달 방식

브라우저는 보통 2개 이상의 서로 다른 로그에서 발급된 SCT를 요구하며(인증서 유효기간에 따라 요구 개수가 달라짐), 이는 특정 로그 하나가 문제여도 생태계가 흔들리지 않게 하는 다양성 요건이다. SCT를 서버가 브라우저에 전달하는 경로는 세 가지이며, 각각 장단점이 뚜렷하다.

전달 방식 방법 장점 단점
X.509v3 확장 내장 인증서 자체에 SCT 포함(프리인증서 기반) 서버·CA 설정 변경 불필요, 가장 널리 사용 발급 후 SCT 변경 불가
TLS 확장(ALPN/SCT 확장) 핸드셰이크 시 서버가 SCT 전달 발급 후에도 SCT 교체·추가 유연 서버 설정 복잡, 지원 제한적
OCSP Stapling OCSP 응답에 SCT를 실어 전달 기존 Stapling 인프라 재활용 OCSP 자체가 축소되는 추세

실무적으로 전 세계 인증서의 대다수는 X.509v3 확장 내장 방식을 쓴다. CA가 발급 과정에서 자동으로 SCT를 넣어주므로 서버 관리자가 별도 설정을 할 필요가 없고, Let's Encrypt 같은 자동화 CA에서 특히 기본값으로 동작한다. 이 단순성이 CT의 전면 확산을 가능케 한 실용적 핵심이다.

4. 기존 PKI 신뢰 모델과의 비교 및 사례

CT를 기존 폐기(CRL·OCSP) 기반 신뢰와 비교하면 그 성격 차이가 분명해진다. 폐기가 "이미 신뢰한 인증서를 사후에 철회"하는 사후 대응이라면, CT는 "발급 사실 자체를 모두가 보게 만드는" 발급 단계의 투명화다. 둘은 대체재가 아니라 상호 보완재다. CT로 오발급을 발견하면, 그 인증서를 폐기(revocation)로 실제 무효화하는 식으로 연결된다.

구분 기존 PKI(폐기 기반) 인증서 투명성(CT)
신뢰 전제 CA의 선의·정확성 신뢰 CA를 신뢰하되 공개 검증으로 견제
초점 사후 신뢰 철회(폐기) 발급의 공개·탐지
변조 방지 서명 체인 머클 트리 기반 암호학적 증명
오발급 가시성 소유자도 모를 수 있음 모니터가 즉시 탐지 가능
강제 수단 루트 저장소 포함 정책 브라우저의 SCT 요구(미준수 시 차단)

차이가 생기는 근본 이유는 신뢰의 소재(locus) 가 다르기 때문이다. 폐기 모델은 신뢰를 CA에 두고 문제가 생기면 거둬들이는 반면, CT는 신뢰를 "공개 관찰 가능성"이라는 생태계 속성에 분산한다. 실무적 함의로, CT가 있는 환경에서는 도메인 소유자가 CT 모니터링을 통해 자신의 보안을 CA에 전적으로 위임하지 않고 직접 확인할 수 있다. 예컨대 어떤 기업이 자사 도메인에 대해 발급된 적 없는 와일드카드 인증서가 CT 로그에 올라온 것을 모니터로 발견하면, 이는 내부 유출이나 CA 오발급의 조기 경보가 된다.

구체 사례로, 2017년 Google은 Symantec이 CT 로그 외부에서 테스트 인증서를 발급해 온 정황을 CT를 통해 추적·확인했고, 이는 약 3만 장 이상의 인증서 신뢰에 영향을 미치는 대규모 신뢰 철회 결정으로 이어졌다. 또한 Facebook은 CT 모니터링을 자동화해, 자사 도메인에 대한 예기치 않은 인증서 발급을 수 분 내 탐지하는 내부 경보 체계를 운영한다고 공개한 바 있다. 이처럼 CT는 이론적 장치가 아니라 실제 대형 서비스의 상시 보안 운영에 깊이 통합되어 있다.

흥미로운 점은 CT가 공격자뿐 아니라 방어자의 정찰 도구로도 쓰인다는 양면성이다. 보안 연구자·레드팀은 crt.sh 등으로 특정 조직의 CT 기록을 검색해 외부에 노출된 하위 도메인·내부 시스템 명을 수집하는 자산 탐색(asset discovery) 에 활용한다. 역으로 블루팀은 동일한 데이터로 '그림자 IT'나 만료 임박 인증서를 선제적으로 식별한다. 동일한 투명성이 공격·방어 양쪽의 가시성을 함께 높인다는 사실은, 보안 설계가 늘 '우리에게 열린 창은 상대에게도 열린다'는 관점을 요구함을 보여주는 좋은 예다.

5. 심화: Static CT API(Sunlight·Tiled Log)와 CT 2.0 동향

전통적 RFC 6962 로그는 운영 비용과 복잡성이 높았다. 로그가 직접 상태를 질의형 API로 서비스해야 했고, 가용성·확장성 부담이 운영자에게 집중되었다. 이를 해소하기 위해 2024년 전후로 Static CT API(정적 CT API, 과거 명칭 Sunlight API) 가 등장했다. 이 방식은 로그를 타일(tile)이라 불리는 평면 파일 집합으로 표현하여, CDN·오브젝트 스토리지(S3 등)에서 정적 파일처럼 배포한다. 타일은 256개 항목 단위로 구성되며, 검증자는 동적 API 대신 정적 파일을 내려받아 트리를 재구성한다. 대표 구현체가 Filippo Valsorda의 Sunlight이며, Let's Encrypt는 2024~2025년에 걸쳐 이를 프로덕션에 도입하고 그 운영 경험을 공개했다.

Static CT API의 설계 의의는 운영 비용의 급감과 가용성 향상에 있다. 동적 서버 대신 정적 파일 배포 모델을 택함으로써 로그 운영자는 데이터베이스 부하와 질의 폭주 위험에서 벗어나고, CDN의 캐싱·가용성을 그대로 활용한다. 주요 브라우저(Chrome 등)도 2025년을 전후해 Static CT API 로그를 공개 신뢰 로그 후보로 수용하는 정책 변화를 반영했다. 다만 이 방식은 정적 로그가 요구하는 leaf_index 확장을 SCT에 포함하는 등 세부 규격이 다르므로, 브라우저 정책은 당분간 RFC 6962 로그와 정적 로그를 병행 인정하는 전환기를 거치고 있다. (세부 규격·정책 수치는 변동 가능성이 있어 일반화해 기술한다.)

브라우저 강제의 실제 효과도 심화 학습 포인트다. Chrome은 CT 미준수 인증서에 대해 '보안 연결 아님' 오류를 띄워 접속을 사실상 차단하므로, CA가 CT를 건너뛸 경제적 유인이 사라졌다. 이 '브라우저 주도 강제'는 표준 문서(RFC)의 권고만으로는 달성하기 어려운 생태계 전환을, 시장 지배적 클라이언트의 정책으로 단기간에 실현한 사례다. 다만 이는 소수 브라우저 벤더가 사실상의 규범 제정자가 되는 중앙집중적 거버넌스 쏠림이라는 양가적 측면도 지니며, 이에 대응해 CA/Browser Forum·IETF 같은 다자 협의체가 균형추 역할을 한다.

표준 측면에서는 RFC 9162가 정의하는 CT 2.0이 있으나, 2026년 현재 주요 브라우저의 실제 구현은 여전히 RFC 6962 계열이 중심이다. CT 2.0은 SCT 구조 개선, 포함 증명 기반 검증 강화 등을 담고 있어 장기적으로 이행이 예상되지만, 기존 생태계의 호환성 때문에 전환은 점진적이다. 기술사 관점에서 이 대목은 "표준 제정과 실제 배포 사이의 지연(standard-deployment gap)"이라는 일반적 현상의 좋은 사례로, 신규 표준 도입 시에는 반드시 기존 설비·클라이언트와의 호환 전략을 함께 설계해야 함을 시사한다.

6. 고려사항 및 시사점(기술사 관점)

  • 적용 전략 — CT 모니터링의 내재화: CT는 이제 "브라우저가 알아서 하는 것"에 그치지 않는다. 도메인을 보유한 모든 조직은 crt.sh·Censys 또는 상용 모니터를 통해 자사 도메인에 대한 발급을 상시 감시하고, 미인가 발급을 보안관제(SOC)·사고대응(IR) 프로세스에 연동해야 한다. 이는 공급망·내부 유출의 조기 경보 채널로 기능한다.

  • 트레이드오프 — 투명성과 프라이버시: CT는 모든 공개 인증서를 노출하므로, 조직이 아직 공개하지 않은 내부 서비스 도메인(subdomain)이 CT 로그를 통해 외부에 드러나는 정보 노출 위험이 있다. 이에 대한 완화책으로 와일드카드 인증서 사용이나, 발급 전 도메인 명명 전략 수립이 필요하다. 투명성의 이득과 도메인 기밀성의 상충을 설계 단계에서 의식해야 한다.

  • 전망 — 단기 인증서·자동화와의 결합: 인증서 유효기간이 47일 수준으로 단축되는 흐름(CA/Browser Forum) 속에서 발급 빈도가 급증하면, CT 로그의 처리량도 폭증한다. Static CT API로의 전환은 이 확장성 압력에 대한 생태계의 응답이며, 조직은 ACME 기반 자동 발급·갱신과 CT가 자동으로 맞물려 돌아가는 파이프라인을 전제로 인프라를 설계해야 한다.

  • 연계 기술 — PKI·폐기·공급망 보안의 통합 관점: CT는 단독 기술이 아니라 PKI, 인증서 폐기(CRL·OCSP), CAA 레코드(DNS 기반 발급 제한), 그리고 넓게는 소프트웨어 공급망 투명성(SBOM) 흐름과 같은 "검증 가능한 투명성" 계열에 속한다. 기술사는 CT를 개별 보안 통제가 아니라, 신뢰를 암호학적 증명과 공개 감시로 재구성하는 큰 설계 원칙의 한 구현으로 이해하고, 조직의 전반적 신뢰·거버넌스 체계에 위치시켜야 한다.

  • 거버넌스 — 표준·브라우저 정책 추적의 상시화: CT 준수 요건(요구 SCT 개수, 인정 로그 목록, 정적 로그 수용 여부)은 브라우저·CA/Browser Forum의 정책에 따라 바뀐다. 한 번 설정하고 끝나는 것이 아니라, 정책 변화를 상시 추적해 인증서 운영 체계에 선제 반영하는 지속적 거버넌스 활동이 필요하다.

참고자료

한 줄 요약: 인증서 투명성(CT)은 모든 공개 TLS 인증서 발급을 머클 트리 기반의 공개 추가 전용 로그에 기록하게 하여 CA 오발급을 사후에 반드시 드러나게 하는 '탐지 중심' 신뢰 체계로, SCT·포함/일관성 증명·모니터·감사자의 분산 감시로 작동하며 Static CT API로 확장성·운영성을 높여가고 있다.