infiltr8 Lab

인증서 투명성(Certificate Transparency) 사례 분석

2026-10-11 · ##웹·서버 ##인증-개념

Security · 웹·서버 · 인증 개념 [정보성]

TLS 연결에서 서버의 신원은 CA가 서명한 인증서로 증명됩니다. 그런데 이 모델에는 한 가지 전제가 숨어 있습니다. CA가 실수하거나 침해당해 엉뚱한 인증서를 발급해도, 그 사실을 빠르게 알아챌 방법이 마땅치 않았다는 점입니다. CT는 이 전제를 바꿉니다. 발급을 막지는 못하지만, 잘못된 발급을 탐지 가능하게 만드는 쪽으로 신뢰모델을 보강합니다.

핵심 사실 요약

CT가 메우려는 빈틈 — 발급 가시성의 부재. TLS 신뢰는 CA 계층에 의존하지만, 어떤 CA가 어떤 도메인에 어떤 인증서를 내줬는지 공개적으로 확인할 통로가 없었습니다. CT는 발급 인증서를 공개 로그에 기록해 이 공백을 메웁니다. 공식 설명에 따르면 이런 가시성 부재는 암호화 연결의 신뢰성을 약화시키고, 웹사이트 스푸핑·서버 가장·중간자(MITM) 공격의 여지를 남깁니다. 중요한 점은 CT의 목적이 오발급(misissuance) 인증서의 예방이 아니라 완화라는 것입니다. 로그 자체가 오발급을 막지는 못하지만, 이해관계자, 특히 인증서에 이름이 오른 도메인 소유자가 오발급을 탐지할 수 있게 합니다.

로그의 구조 — 추가 전용(append-only) 머클 트리. CT 로그는 분산·독립적으로 운영되는 추가 전용 원장입니다. 인증서는 추가만 가능하고 삭제·수정·소급 삽입은 불가능합니다. 이 추가 전용 속성은 머클 트리(Merkle Tree)로 구현됩니다. 머클 트리는 어떤 로그 상태가 이전 상태를 온전히 포함한 상위집합(superset)임을 효율적으로 증명할 수 있어, 로그가 몰래 변조됐는지를 탐지할 수 있게 합니다.

발급 약속 — SCT와 최대 병합 지연(MMD). 로그가 제출을 수락하면 서명된 인증서 타임스탬프(Signed Certificate Timestamp, SCT)를 돌려줍니다. SCT는 “수락한 항목을 머클 트리에 추가하겠다”는 로그의 약속입니다. 로그는 이 약속을 최대 병합 지연(Maximum Merge Delay, MMD)이라는 정해진 시간 안에 이행해야 하며, MMD는 로그마다 설정되는 파라미터입니다. 운영 현장에서 흔히 24시간이 쓰인다고 알려져 있으나, 규격은 특정 값을 못박지 않고 로그별 정책에 맡기므로 고정 상수로 보기는 어렵습니다 ⚠️미확인. 발급 흐름은 대략 이렇습니다. CA가 poison 확장이 든 사전인증서(precertificate)를 로그에 제출하고, SCT를 받아 인증서에 첨부해 도메인 소유자에게 전달하면, 브라우저가 그 SCT 제시를 검증합니다.

역할 분리 — 모니터와 감사(auditor). CT 생태계는 두 역할로 건전성을 지탱합니다. 모니터(monitor)는 모든 로그의 신규 항목을 살펴 의심스러운 인증서를 감시하고, 특정 인증서가 로그에 실제로 추가됐음을 암호학적으로 증명할 수 있습니다. 감사(auditor)는 로그 자체의 정직성, 즉 일관성과 포함 증명을 검증합니다. 전자가 “내 도메인에 이상한 인증서가 생겼나”를 본다면, 후자는 “로그가 거짓말을 하고 있지는 않나”를 봅니다.

표준의 흐름 — RFC 6962에서 RFC 9162로. CT의 원 규격은 2013년 6월 공개된 실험적(experimental) 문서 RFC 6962입니다. 이후 2021년 12월에 나온 RFC 9162(Certificate Transparency Version 2.0)가 RFC 6962를 대체(obsolete)했습니다. 2.0은 CT 로그 아티팩트를 전송하기 위한 TLS 확장을 새로 규정합니다.

필요성의 경험적 근거 — 두 오발급 사건. CT가 왜 필요한지는 실제 사건이 보여줍니다. 2011년 네덜란드 CA 디지노타(DigiNotar)가 침해당해 다수 도메인용 위조 인증서가 발급됐고, 이는 이란발 트래픽의 중간자 공격에 쓰였습니다. 위조 발급부터 공개 발견까지 대략 6~7주(한 달 반 안팎)가 걸린 것으로 전해지나 정확한 기간은 1차 사후분석 원문을 대조하지 못했습니다 ⚠️미확인. 이 사건은 “위조 인증서를 신속히 탐지하는 수단 없이 폐기(revocation)만으로 충분한가”라는 문제의식을 불러 CT 추진의 배경이 됐습니다. 위조 인증서 규모는 수백 건 수준으로 전해지나 정확한 건수는 1차 사후분석 원문을 대조하지 못했습니다 ⚠️미확인. 2015년에는 시만텍(Symantec)이 google.com과 www.google.com용 확장검증(EV) 인증서를 잘못 발급한 사건이 있었습니다. 이는 CT를 통해 포착된 대표적 초기 사례로 거론됩니다. “CT로 발견된 최초”라는 표현도 보이지만, 이는 보도 매체의 주장 성격이 강해 절대적 표현은 피했습니다 ⚠️미확인.

브라우저의 강제 — “로그에 없으면 신뢰하지 않음”. CT가 실효를 가진 결정적 계기는 클라이언트의 강제였습니다. 규격의 의도는 로그에 나타나지 않는 인증서를 클라이언트가 신뢰하지 않게 하여, CA가 모든 발급 인증서를 로그에 등록하도록 사실상 강제하는 것입니다. 크롬(Chrome)은 크롬 68(2018년 7월경)부터 CT를 전면 강제했고, 2018년 4월 30일 이후 발급돼 공개 신뢰 루트로 검증되는 모든 TLS 인증서를 CT 로그 등재 대상으로 삼은 것으로 전해집니다. 다만 이 구체 버전 번호와 2018년 7월 24일·4월 30일이라는 날짜는 참고자료 중 접속 가능한 1차 출처로 대조하지 못했으므로 발행 시점에 구글/크로미움 공식 공지로 재확인이 필요합니다 ⚠️미확인. 공개 신뢰 인증서가 CT 로그에 등재돼야 크롬이 신뢰하고 웹사이트가 SCT로 로그 포함을 증명해야 한다는 큰 틀의 강제 방향은 규격의 의도(참고자료 1번)와 일치합니다. 정책도 바뀌어 왔습니다. 초기에는 구글 운영 로그 SCT 1개와 비(非)구글 로그 SCT 1개가 필요했으나, 크롬 100(2022년 3월 29일) 이후 2022년 4월 15일 이후 발급분부터는 구글 로그 SCT 요구가 사라지고 서로 다른 2개 이상의 로그 운영자가 발급한 SCT를 요구하는 방식으로 전환됐습니다. 인증서 유효기간이 길수록 더 많은 SCT를 요구하는 방향성은 확인되나, 유효기간 구간별 정확한 SCT 개수는 정책이 자주 바뀌므로 발행 시점 기준 재확인이 필요합니다 ⚠️미확인.

실무에서 알아둘 점

CT는 공격 취약점이 아니라 신뢰 인프라이므로 패치 대상이 아닙니다. 대신 운영 관점에서 두 가지가 실무 가치를 가집니다. 첫째, 자기 도메인에 대한 CT 로그를 모니터링하면 자기도 모르게 발급된 인증서를 조기에 포착할 수 있습니다. 둘째, 공개 신뢰 인증서를 쓰는 서비스라면 발급 체계가 SCT를 제대로 첨부하는지 확인해 두는 편이 안전합니다. 크롬을 비롯한 주요 클라이언트가 SCT 부재를 신뢰 거부로 처리하기 때문입니다.

짧은 논평

CT의 설계 철학은 다른 보안 메커니즘과 통하는 데가 있습니다. 완벽한 예방이 어려울 때, 사후에라도 “되돌릴 수 없는 공개 기록”을 남겨 부정을 드러나게 만드는 접근입니다. 추가 전용 머클 트리라는 자료구조는 감사 로그나 투명성 원장 계열에서 반복해 등장하는 발상이고, CT는 그 발상을 전 세계 TLS 신뢰에 적용한 대규모 사례라 할 수 있습니다. 한 CA의 실수가 조용히 묻히던 구조를, 모두가 볼 수 있는 기록으로 바꿔 놓은 셈입니다.

References / 참고자료

이 글은 아래 원 자료를 우리 관점에서 다시 쓰고 정리한 것입니다. 특정 문장·코드를 그대로 옮기지 않았으며, 자세한 내용은 원문을 참고하세요.

  1. IETF, “RFC 9162 — Certificate Transparency Version 2.0”, CT 2.0 현행 규격이며 RFC 6962를 대체. 로그 구조·SCT·MMD·감사·브라우저 강제 의도의 1차 근거. https://www.rfc-editor.org/rfc/rfc9162.html
  2. IANA / IETF, “RFC 6962 — Certificate Transparency”, 2013년 6월 공개된 원 실험 규격 정보 페이지. https://www.iana.org/go/rfc6962
  3. Certificate Transparency Project, “How CT Works”, 로그·모니터·SCT·머클 트리·발급 흐름을 설명하는 공식 프로젝트 문서. https://certificate.transparency.dev/howctworks/
  4. Electronic Frontier Foundation, “Symantec issues rogue EV certificate for google.com” (2015-09), CT로 포착된 EV 인증서 오발급 사례. https://www.eff.org/deeplinks/2015/09/symantec-issues-rogue-ev-certificate-googlecom
  5. Chromium CT Policy 그룹 공지, “Removal of ‘1 Google Log’ SCT requirement and changes to number of required embedded SCTs”, 크롬 SCT 요건 변경의 1차 공지. https://groups.google.com/a/chromium.org/g/ct-policy/c/507lPdbbwSk/m/JpxJEtrQAwAJ
  6. SecurityWeek, “Chrome Browser Now Enforces Certificate Transparency”, 크롬 68 강제 시행을 전한 2차 보도. ⚠️미확인 — 자동 수집 시점 접속이 차단(HTTP 403)되어 본문 주장과 직접 대조하지 못함. 위 4번(EFF)은 2015-09 작성분으로 2015년 당시 EV 한정 요구(“In Chrome, CT is required for all new EV certificates”)만 다루므로, 2018년 크롬 68의 전면강제를 교차확인하는 출처가 되지 못합니다. 크롬 68 강제의 구체 버전·시행일을 뒷받침하는 접속 가능한 1차 출처는 참고자료에 없습니다. https://www.securityweek.com/chrome-browser-now-enforces-certificate-transparency