맨위로가기

인증서 투명성

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

인증서 투명성은 위조된 인증서 발급을 감지하고, 보고하며, 폐지하는 시간을 단축하기 위해 고안된 시스템이다. 2011년 코모도 리셀러 공격과 디지노타의 손상으로 인해 인증 기관의 취약점이 드러나면서, 잘못 발급된 인증서를 감지하기 위한 기술 개발이 시작되었다. 구글은 2013년 첫 번째 인증서 투명성 로그를 시작했으며, 이후 크롬과 사파리 등의 브라우저에서 인증서 투명성 지원을 의무화했다. 인증서 투명성 시스템은 CT 로그, 모니터, 감사자 등의 구성 요소를 가지며, 로그 샤딩과 같은 기술을 통해 효율성을 높인다. 이 시스템은 위조 인증서 발견을 용이하게 하지만, 내부 네트워크에서 사용되는 인증서 정보가 공개될 수 있다는 단점도 존재한다.

더 읽어볼만한 페이지

  • 공개 키 기반 구조 - 코드 서명
    코드 서명은 코드의 출처와 무결성을 보장하기 위해 공개 키와 개인 키 쌍을 사용하여 코드를 서명하는 기술이며, 소프트웨어 보안 강화 및 출처 확인에 유용하다.
  • 공개 키 기반 구조 - 루트 인증서
    루트 인증서는 공개 키 기반 구조에서 디지털 인증서의 유효성을 검증하는 최상위 인증서로서, 웹 브라우저와 운영체제가 신뢰하는 목록을 관리하지만, 보안 침해 사례로 인해 사용자들의 적극적인 보안 조치가 필요하다.
  • 전송 계층 보안 - 공개 키 기반 구조
    공개 키 기반 구조(PKI)는 공개 키 암호화를 기반으로 안전한 통신과 개체 식별을 가능하게 하는 기술로서, 디지털 인증서를 통해 공개 키를 특정 개체에 연결하고 인증서를 관리하며, 인증 기관(CA), 등록 기관(RA) 등 다양한 구성 요소로 이루어져 인증서 발급, 관리, 배포, 사용 및 폐기와 관련된 역할, 정책, 하드웨어, 소프트웨어 및 절차의 집합을 포함한다.
  • 전송 계층 보안 - HTTPS
    HTTPS는 HTTP에 보안 기능이 더해진 통신 규약으로, 웹 브라우저와 서버 간 통신을 암호화하여 보안을 강화하지만, 인증서 비용, 서버 부하, 혼합 콘텐츠 문제 등의 단점도 존재한다.
  • 인터넷 보안 - 전송 계층 보안
    전송 계층 보안(TLS)은 클라이언트-서버 간 통신에서 도청, 간섭, 위조를 막기 위해 설계된 암호화 프로토콜이며, 종단 간 인증, 통신 기밀성을 제공하고, 다양한 프로토콜에 적용되어 HTTPS를 보호하는 데 주로 사용된다.
  • 인터넷 보안 - 토르 (네트워크)
    토르(Tor)는 사용자의 익명성을 보장하고 온라인 활동을 보호하기 위해 개발된 네트워크로, 암호화된 통신을 여러 노드를 거쳐 전송하며 검열 우회, 언론의 자유를 위한 도구로 활용되지만 범죄에도 악용될 수 있다.
인증서 투명성
인증서 투명성
유형보안 프로토콜
설명공개 로그 시스템으로, 디지털 인증서의 투명성을 보장한다.
약칭CT
상세 정보
목적인터넷 사용자의 안전을 향상시키기 위해 설계되었다.
동작 방식인증 기관(CA)이 발행한 모든 인증서를 공개 로그에 기록하고 감사할 수 있도록 한다.
목표잘못 발행된 인증서를 탐지하고, 웹사이트 위조 및 중간자 공격과 같은 보안 위협을 줄이는 것을 목표로 한다.
사용 사례웹 브라우저, 운영 체제 및 기타 소프트웨어에서 CT 로그를 검증하여 유효한 인증서만 사용하도록 보장할 수 있다.
장점인증서 발행의 투명성 증가
보안 위협 탐지 및 완화
인터넷 사용자 보호 강화
구현구글
모질라
클라우드플레어
관련 RFC
RFC 6962인증서 투명성 (Certificate Transparency)
RFC 9162인증서 투명성 버전 2.0 (Certificate Transparency Version 2.0)

2. 역사적 배경

파이어폭스 89에서 인증서 투명성 항목의 예


2011년, 인증 기관인 코모도의 리셀러가 공격을 받고, 디지노타가 손상되는 사건이 발생했다.[17] 이러한 사건은 인증 기관 생태계의 기존 결함을 드러냈고, 무단 인증서 발급을 방지하거나 감시하기 위한 다양한 메커니즘에 대한 작업이 시작되는 계기가 되었다. 같은 해 구글 직원 벤 로리, 아담 랭글리, 에밀리아 캐스퍼는 잘못 발급된 인증서를 감지하기 위한 오픈 소스 소프트웨어 프레임워크 작업을 시작했다. 2012년에는 "Sunlight"라는 코드명으로 표준의 첫 번째 초안을 IETF에 제출했다.[18]

2013년 3월, 구글은 첫 번째 인증서 투명성 로그를 시작했고,[19] 같은 해 6월에는 2012년 초안을 기반으로 한 "인증서 투명성"이 발표되었다. 같은 해 9월, DigiCert는 인증서 투명성을 구현한 최초의 인증 기관이 되었다.[20]

2015년, 구글 크롬은 새로 발급된 확장 유효성 인증서에 대해 인증서 투명성을 요구하기 시작했다.[21][22] 2016년 6월 1일부터 노턴 라이프락에서 새로 발급된 모든 인증서에 대해 인증서 투명성을 요구하기 시작했는데, 이는 도메인 소유자의 인지 없이 187개의 인증서를 발급한 사실이 밝혀졌기 때문이다.[23][24] 2018년 4월부터 이 요구 사항은 모든 인증서로 확대되었다.[25]

2018년 3월 23일, 클라우드플레어는 ''Nimbus''라는 자체 CT 로그를 발표했다.[26]

2019년 5월, 인증 기관 Let's Encrypt는 Oak라는 자체 CT 로그를 시작했다. 2020년 2월부터 승인된 로그 목록에 포함되어 모든 공적으로 신뢰받는 인증 기관에서 사용할 수 있게 되었다.[27]

2021년 12월, "인증서 투명성 버전 2.0"이 발표되었다.[1] 버전 2.0에는 로그 인증서의 필수 구조에 대한 주요 변경 사항과 SCT의 서명 알고리즘으로 Ed25519에 대한 지원 및 SCT에 인증서 포함 증명 포함에 대한 지원이 포함되어 있다.

2022년 2월, 구글은 CT 정책에 대한 업데이트를 발표했으며,[28] 인증서가 자체 CT 로그 서비스에서 SCT를 포함해야 한다는 요구 사항을 제거하여, 이전에 애플에서 발표한 인증서에 대한 모든 요구 사항과 일치시켰다.[29]

2. 1. 초기 역사

2011년, 인증 기관인 코모도의 리셀러가 공격을 받았고, 인증 기관인 디지노타가 손상되는 사건이 발생했다.[17] 이러한 사건은 인증 기관 생태계의 기존 결함을 드러냈고, 무단 인증서 발급을 방지하거나 감시하기 위한 다양한 메커니즘에 대한 작업이 시작되는 계기가 되었다. 같은 해 구글 직원 벤 로리, 아담 랭글리(Adam Langley), 에밀리아 캐스퍼(Emilia Kasper)는 잘못 발급된 인증서를 감지하기 위한 오픈 소스 소프트웨어 프레임워크 작업을 시작했다. 2012년, 그들은 "Sunlight"라는 코드명으로 표준의 첫 번째 초안을 IETF에 제출했다.[18]

2. 2. 주요 발전 과정

2013년 3월, 구글(Google)은 최초의 CT 로그 서비스를 시작했다.[41] 같은 해 9월, 디지서트(DigiCert)가 CT를 구현한 최초의 인증 기관이 되었다.[42]

2015년, 구글 크롬(Google Chrome)은 신규 EV 인증서에 대해 CT를 필수화했다.[43][44] 2018년 4월 이후(즉, 5월 이후)의 모든 TLS 인증서로 확대되었다.[47]

2018년 3월 23일, 클라우드플레어(Cloudflare)는 Nimbus라는 이름으로 자체 CT 로그 시작을 발표했다.[48]

2018년 3월, 인터넷 드래프트 "Certificate Transparency Version 2.0"이 공개되었다.[49]

2019년 5월, 인증 기관 중 하나인 Let's Encrypt가 Oak라는 이름으로 CT 로그를 시작했다. 2020년 2월부터 승인된 로그 목록에 추가되어 모든 공개 인증 기관에서 사용 가능하게 되었다.[50]

3. 기술적 개요

디지노타 등에서 부정 인증서 발급 사건[35]이 발생하면서 인증 기관 생태계의 결함에 대한 관심이 높아졌다. 이에 대응하여 벤 로리(Ben Laurie), Adam Langley, Emilia Kasper가 오픈 소스 프레임워크를 만들기 시작했고, 이것이 인증서 투명성(CT)이다. 2012년에는 코드네임 Sunlight로서 IETF에 최초의 인터넷 드래프트가 전송되었다.

인증서 투명성 시스템은 추가 전용 인증서 로그 시스템으로 구성되며, 로그는 브라우저 벤더 및 인증 기관 등 여러 당사자가 운영한다.[3] 인증서 투명성을 지원하는 인증서는 하나 이상의 "서명된 인증서 타임스탬프"(SCT)를 포함해야 하며, 이는 로그 운영자가 해당 인증서를 "최대 병합 지연"(MMD) 내에 로그에 포함하겠다는 약속이다.[4][3] 로그 운영자는 최대 병합 지연 내에 해당 인증서를 로그에 추가한다. 로그의 각 항목은 이전 항목의 해시를 참조하여 머클 트리를 형성하고, "서명된 트리 헤드"(STH)는 머클 트리의 현재 루트를 참조한다.

3. 1. 로깅 절차

인증서 투명성 시스템은 추가 전용 인증서 로그 시스템으로 구성된다. 로그는 브라우저 벤더 및 인증 기관을 포함한 여러 당사자가 운영한다.[3] 인증서 투명성을 지원하는 인증서는 하나 이상의 "서명된 인증서 타임스탬프"(SCT)를 포함해야 한다. 이는 로그 운영자가 해당 인증서를 "최대 병합 지연"(MMD) 내에 로그에 포함하겠다는 약속이다.[4][3] 최대 병합 지연 내에 로그 운영자는 해당 인증서를 로그에 추가한다. 로그의 각 항목은 이전 항목의 해시를 참조하여 머클 트리를 형성한다. "서명된 트리 헤드"(STH)는 머클 트리의 현재 루트를 참조한다.

누구나 CT 로그에 인증서를 제출할 수 있지만, 이 작업은 일반적으로 CA(인증 기관)에 의해 다음과 같이 수행된다:[4][5]

1. 신청자는 CA에 인증서를 요청한다.[6]

2. CA는 사용자가 받아들여서는 안 된다는 신호를 보내는 독(poison) 확장 기능을 가진 인증서인 특별한 ''사전 인증서''(precertificate)를 발급한다.

3. CA는 사전 인증서를 로그로 보낸다.

4. 로그는 해당 SCT(Signed Certificate Timestamps, 서명된 인증서 타임스탬프)를 CA로 반환한다.

5. CA는 로그에서 수집한 SCT를 X.509 확장 기능으로 최종 인증서에 첨부하여 신청자에게 제공한다.

마지막으로, CA는 최종 인증서도 로깅하기로 결정할 수 있다. 예를 들어, Let's Encrypt E1 CA는 사전 인증서와 최종 인증서 모두를 로깅하는 반면(CA [https://crt.sh/?caid=183283 crt.sh profile page]의 '발급된 인증서' 섹션 참조), Google GTS CA 2A1은 그렇지 않다( [https://crt.sh/?caid=180750 crt.sh profile page] 참조).

CT 로그는 인증서 및 사전 인증서를 기록하는 대장이다. 데이터 구조로 마클 트리가 사용된다. 인증서 및 사전 인증서의 등록을 CT 로그에 요청하면 CT 로그는 그 증거로 '''서명된 인증서 타임스탬프'''(SCT, Signed Certificate Timestamp)를 발행한다.

CT의 목적을 달성하기 위해 CT 로그에는 다음이 요구된다.

  • 로그에 전송된 인증서 및 사전 인증서 각각에 대해 신뢰할 수 있는 루트 인증 기관의 인증서에 체인되어 있는지의 검증
  • 유효한 서명 체인이 없는 인증서의 공개를 거부하는 것
  • 새롭게 수락하는 인증서부터 루트 인증서까지의 체인 전체를 저장하는 것
  • 요청에 따라 감사를 위해 이 체인을 제시하는 것


로그로서, 완전하게 유효하지 않거나 유효 기간이 만료된 인증서를 수락하는 경우도 있을 수 있다.

3. 2. 로그 샤딩 (Log Sharding)

웹 PKI를 통해 발행되는 인증서의 양이 많아짐에 따라, 인증서 투명성 로그는 방대한 양의 인증서를 포함하게 될 수 있다. 이러한 다량의 인증서는 로그에 부담을 줄 수 있다. 시간적 샤딩은 로그를 여러 개로 나누고(샤딩), 각 샤드에서 특정 기간(주로 달력 연도) 내에 만료 날짜가 있는 사전 인증서 및 인증서만 허용함으로써 로그의 부담을 경감하는 방법이다.[15][12][13] 클라우드플레어(Cloudflare)의 님버스(Nimbus) 로그 시리즈는 시간적 샤딩을 처음으로 사용하였다.

3. 3. 강제 인증서 투명성 (Mandatory Certificate Transparency)

일부 브라우저는 전송 계층 보안(TLS) 인증서가 인증서 투명성과 함께 기록되었다는 증거를 요구한다.[7][25] 이는 인증서에 포함된 SCT, TLS 핸드셰이크 중의 확장 또는 OCSP를 통해 이루어진다.

브라우저현재 SCT 요구 사항현재 OCSP/TLS 확장 요구 사항
크롬/크로미움
파이어폭스없음[10]없음
사파리현재 승인된 로그에서 2개의 SCT



구글 크롬 및 사파리에서는 HTTPS 통신 시 서버 인증서가 CT를 지원하는 것을 요구한다. 미지원 시 인증서를 신뢰하지 않고 통신을 중단한다.[37] 지원 여부 판단을 위해 웹 서버에서 SCT를 획득할 수 있어야 한다.[38]

구글 크롬의 경우, 이 처리는 다음 조건을 충족해야 적용된다.[39]


  • EV 인증서의 경우 2015년 1월 이후 발급된 것
  • 그 외 모든 인증서의 경우 2018년 5월 이후 발급된 것
  • 발급일에 관계없이, HTTP 응답에 Expect-CT 헤더 필드가 지정된 경우, 해당 지침을 따른다.


사파리의 경우, 2018년 10월 15일 이후 발급된 서버 인증서에 대해 CT 지원을 요구한다.[40]

4. 구성 요소

인증서 투명성(CT) 시스템은 다음 요소들로 구성된다.


  • '''CT 로그 (CT Log):''' 인증서 및 사전 인증서를 기록하는 추가 전용 대장이다. 머클 트리 데이터 구조를 사용하며, 인증서 등록 요청 시 '''서명된 인증서 타임스탬프'''(SCT)를 발행한다. CT 로그는 다음 요구사항을 만족해야 한다.
  • 신뢰할 수 있는 루트 인증 기관의 인증서에 체인되는지 검증
  • 유효한 서명 체인이 없는 인증서 공개 거부
  • 새롭게 수락하는 인증서부터 루트 인증서까지의 체인 전체 저장
  • 요청 시 감사를 위해 체인 제시
  • '''CT 모니터 (CT Monitor):''' 로그 서버의 클라이언트 역할을 하며, 로그가 올바르게 작동하는지 검사한다. 모니터는 기록되는 로그를 감시하고, 관심 있는 인증서(예: 자신이 소유한 도메인)의 무단 발급 여부를 감시한다.
  • '''CT 감사자 (CT Auditor):''' 로그 서버의 클라이언트 역할을 하며, 로그의 부분적인 정보를 사용하여 자신이 가진 다른 부분적인 정보와 대조하여 로그 전체의 무결성을 검증한다.[36]
  • '''CT 로그 프로그램 및 루트 저장소:''' 애플Apple|애플영어[14]과 구글Google|구글영어[15]은 별도의 정책과 신뢰할 수 있는 로그 목록을 갖춘 개별 로그 프로그램을 운영한다. CT 로그는 자체 루트 저장소를 유지하며, 신뢰할 수 있는 루트로 연결되는 인증서만 허용한다.[1]

4. 1. CT 로그 (CT Log)

인증서 투명성 시스템은 추가 전용 인증서 로그 시스템으로 구성된다. 로그는 브라우저 벤더 및 인증 기관을 포함한 여러 당사자가 운영한다.[3] 인증서 투명성을 지원하는 인증서는 하나 이상의 "서명된 인증서 타임스탬프"(SCT)를 포함해야 하는데, 이는 로그 운영자가 해당 인증서를 "최대 병합 지연"(MMD) 내에 로그에 포함하겠다는 약속이다.[4][3] 로그 운영자는 최대 병합 지연 내에 해당 인증서를 로그에 추가한다. 로그의 각 항목은 이전 항목의 해시를 참조하여 머클 트리를 형성한다. "서명된 트리 헤드"(STH)는 머클 트리의 현재 루트를 참조한다.

CT 로그는 인증서 및 사전 인증서를 기록하는 대장이다. 데이터 구조로 마클 트리가 사용된다. 인증서 및 사전 인증서의 등록을 CT 로그에 요청하면 CT 로그는 그 증거로 '''서명된 인증서 타임스탬프'''(SCT, Signed Certificate Timestamp)를 발행한다.

CT의 목적을 달성하기 위해 CT 로그에는 다음 사항이 요구된다.

  • 로그에 전송된 인증서 및 사전 인증서 각각에 대해 신뢰할 수 있는 루트 인증 기관의 인증서에 체인되어 있는지 검증
  • 유효한 서명 체인이 없는 인증서의 공개를 거부하는 것
  • 새롭게 수락하는 인증서부터 루트 인증서까지의 체인 전체를 저장하는 것
  • 요청에 따라 감사를 위해 이 체인을 제시하는 것


로그로서, 완전하게 유효하지 않거나 유효 기간이 만료된 인증서를 수락하는 경우도 있을 수 있다.

4. 2. CT 모니터 (CT Monitor)

모니터는 로그 서버의 클라이언트 역할을 한다. 모니터는 로그가 올바르게 작동하는지 확인하기 위해 로그를 검사한다. 불일치는 로그가 올바르게 작동하지 않았음을 증명하는 데 사용되며, 로그의 데이터 구조(머클 트리)에 대한 서명은 로그가 잘못된 동작을 부인하는 것을 방지한다.

모니터는 기록되는 로그를 감시하는 시스템이다. 또한, 관심 있는 인증서의 등록을 감시하기도 한다. 예를 들어, 자신이 소유한 도메인이 무단으로 발급되지 않았는지 감시할 수 있으며, 여러 회사가 이를 위한 서비스를 제공하고 있다.

CT 모니터링 서비스를 제공하는 회사들은 다음과 같다.

4. 3. CT 감사자 (CT Auditor)

감사자는 로그 서버의 클라이언트 역할도 수행한다. 인증서 투명성 감사자는 로그의 부분적인 정보를 사용하여 자신이 가지고 있는 다른 부분적인 정보와 대조하여 로그를 검증한다.[1] 감시자가 로그 내의 개별 인증서에 관심을 갖는 존재인 반면, 로그 전체의 무결성을 검증하는 역할은 감사자가 수행한다.[36]

4. 4. CT 로그 프로그램 및 루트 저장소

애플Apple|애플영어[14]과 구글Google|구글영어[15]은 별도의 정책과 신뢰할 수 있는 로그 목록을 갖춘 개별 로그 프로그램을 운영하고 있다.

인증서 투명성 로그는 자체 루트 저장소를 유지하며, 신뢰할 수 있는 루트로 연결되는 인증서만 허용한다.[1] 과거에 많은 문제를 일으키는 로그들이 일관성이 없는 루트 저장소를 게시해왔다.[16]

5. 장점 및 단점

인증서 투명성은 위조된 인증서를 발견하고, 보고하고, 폐지하는 데 오랜 시간이 걸리는 디지털 인증서 관리의 문제점을 해결하는 데 도움을 준다. 인증서 투명성을 사용하면 도메인 소유자와 관심 있는 모든 사람이 도메인에 대해 발급된 모든 인증서에 대한 정보를 얻을 수 있다.[35] 또한, 도메인 이름 소유자가 모르게 해당 도메인에 대한 인증서가 발급되는 것을 방지한다.

인증서 투명성은 온라인 인증서 상태 프로토콜(OCSP)이나 Convergence_(SSL)|컨버전스영어와 달리 사이드 채널 통신이 필요하지 않으며, 신뢰할 수 있는 제3자 없이도 운영할 수 있다.

하지만 내부 네트워크에서 사용되고 인증 기관에서 발급된 인증서를 사용하는 도메인 이름은 해당 인증서가 CT 로그에 추가되면서 공개적으로 검색 가능해진다. 이로 인해 관계자만 이용하는 FQDN(간단히 말해 서버명)이 외부에 노출될 수 있다는 부작용이 있다.[1]

5. 1. 장점

디지털 인증서 관리의 문제점 중 하나는 위조된 인증서를 발견하고, 보고하고, 폐지하는 데 오랜 시간이 걸린다는 것이다. 인증서 투명성을 사용하지 않고 발급된 인증서는 전혀 발견되지 않을 수도 있다. 인증서 투명성은 도메인 소유자(및 관심 있는 모든 사람)가 도메인에 대해 발급된 모든 인증서에 대한 정보를 얻을 수 있도록 한다.[35]

인증서 투명성(CT)은 도메인 이름 소유자가 알지 못하는 사이에 해당 도메인에 대한 인증서가 발급되지 않도록 지원한다.

온라인 인증서 상태 프로토콜(OCSP)이나 Convergence_(SSL)|컨버전스영어와 마찬가지로, CT는 사이드 채널 통신을 필요로 하지 않는다. 또한, CT는 신뢰할 수 있는 제3자를 필요로 하지 않고 운영할 수 있다.

5. 2. 부작용 (단점)

내부 네트워크에서 사용되고 인증 기관에서 발급된 인증서를 사용하는 도메인 이름은 해당 인증서가 CT 로그에 추가되면서 공개적으로 검색 가능해진다. 기록된 로그를 조사함으로써 관계자만 이용하는 FQDN(간단히 말해 서버명)이 외부에 노출될 수 있다.[1]

6. 서명 알고리즘

인증서 투명성 버전 2.0에서 로그는 IANA 레지스트리 "서명 알고리즘"에 있는 알고리즘 중 하나를 사용해야 한다.[1][30]

7. CT 로그 조사 도구

다음은 인증서 투명성(CT) 로그를 조사하고 분석하는 데 사용되는 도구들이다.



모니터는 기록되는 로그를 감시하는 시스템이다. 예를 들어 자신이 소유한 도메인이 무단으로 발급되지 않았는지 감시하는 데 사용될 수 있으며, 여러 회사들이 이러한 서비스를 제공하고 있다.

8. 한국에 미치는 영향 (별도 추가)

인증서 투명성은 대한민국의 웹 환경과 보안에 큰 영향을 미치고 있다. 특히, 공인인증서 폐지 이후 다양한 민간 인증서가 등장하면서 인증서 투명성의 중요성이 더욱 강조되고 있다.

공인인증서 폐지 이전에는 정부 주도의 단일 인증 시스템으로 인해 인증서 발급 및 관리 과정에서 투명성이 부족하다는 지적이 있었다. 그러나 민간 인증서 시장이 활성화되면서 다양한 인증 기관이 경쟁하게 되었고, 이에 따라 인증서 발급 과정의 투명성과 신뢰성을 확보하는 것이 중요한 과제가 되었다.

인증서 투명성은 이러한 문제를 해결하는 데 기여할 수 있다. 인증서 발급 내역을 공개적으로 기록하고 검증함으로써, 사용자는 자신이 접속하는 웹사이트가 실제로 신뢰할 수 있는 인증서를 사용하는지 확인할 수 있다. 또한, 인증 기관의 부정행위나 실수로 인한 잘못된 인증서 발급을 조기에 발견하고 대응할 수 있도록 돕는다.

다만, 인증서 투명성 도입 과정에서 대한민국의 특수한 상황을 고려해야 한다. 예를 들어, 여전히 많은 웹사이트에서 액티브X와 같은 비표준 기술을 사용하고 있으며, 이는 인증서 투명성 적용에 어려움을 줄 수 있다. 또한, 다양한 민간 인증서가 경쟁하는 상황에서 인증서 투명성 시스템이 특정 인증 기관에 유리하게 작용하지 않도록 주의해야 한다.

결론적으로, 인증서 투명성은 대한민국의 웹 환경과 보안을 강화하는 데 중요한 역할을 할 수 있다. 하지만, 대한민국의 특수한 상황을 고려하여 신중하게 도입하고 적용해야 할 것이다.

참조

[1] 간행물 Certificate Transparency Version 2.0 2021-12
[2] 웹사이트 Introducing Certificate Transparency Monitoring https://blog.cloudfl[...] 2019-08-08
[3] 서적 Proceedings of the Internet Measurement Conference 2018 ACM 2018-10-31
[4] 웹사이트 How CT Works : Certificate Transparency https://certificate.[...] 2022-02-25
[5] 웹사이트 Certificate Transparency (CT) Logs https://letsencrypt.[...] Let's Encrypt 2024-01-04
[6] 웹사이트 Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates https://cabforum.org[...] CA/B Forum 2024-01-04
[7] 웹사이트 Certificate Transparency: FAQs https://www.digicert[...] 2015-06-03
[8] 문서
[9] 웹사이트 Chrome Certificate Transparency Policy https://googlechrome[...] 2022-02-26
[10] 웹사이트 Certificate Transparency - Web security https://developer.mo[...] 2022-02-26
[11] 웹사이트 Apple's Certificate Transparency policy https://support.appl[...] 2021-03-05
[12] 서적 Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security ACM 2019-11-06
[13] 웹사이트 Scaling CT Logs: Temporal Sharding https://www.digicert[...] 2022-02-26
[14] 웹사이트 Apple's Certificate Transparency log program. https://support.appl[...] 2019-01-28
[15] 웹사이트 Chrome CT Log Policy. https://googlechrome[...] 2021-10-14
[16] 서적 Characterizing the root landscape of Certificate Transparency logs
[17] 뉴스 Another fraudulent certificate raises the same old questions about certificate authorities https://arstechnica.[...] 2011-08-30
[18] 간행물 Certificate Transparency (draft-laurie-pki-sunlight) https://datatracker.[...] IETF 2012-09-12
[19] 웹사이트 Known Logs - Certificate Transparency http://www.certifica[...] 2015-12-31
[20] 웹사이트 DigiCert Announces Certificate Transparency Support https://www.darkread[...] Dark Reading 2013-09-24
[21] 웹사이트 Certificate Transparency Required for EV Certificates to Show Green Address Bar in Chrome https://blog.digicer[...] DigiCert 2014-12-05
[22] 메일링리스트 Updated Certificate Transparency + Extended Validation plan https://cabforum.org[...] 2014-02-04
[23] 웹사이트 Symantec Certificate Transparency (CT) for certificates issued before June 1, 2016 https://web.archive.[...] Symantec 2016-06-09
[24] 웹사이트 Sustaining Digital Certificate Security https://security.goo[...] 2015-10-28
[25] 웹사이트 Certificate Transparency Enforcement in Google Chrome https://groups.googl[...] Google Groups 2018-02-07
[26] 웹사이트 Introducing Certificate Transparency and Nimbus https://blog.cloudfl[...] 2018-03-23
[27] 웹사이트 Introducing Oak, a Free and Open Certificate Transparency Log - Let's Encrypt https://letsencrypt.[...] 2021-04-13
[28] 웹사이트 Google CT Policy Update https://groups.googl[...] 2022-02-14
[29] 웹사이트 Apple's Certificate Transparency Policy https://support.appl[...] 2021-03-05
[30] 웹사이트 Signature Algorithms https://www.iana.org[...] IANA 2023-05-28
[31] 웹사이트 Monitors : Certificate Transparency https://certificate.[...] 2023-03-06
[32] 간행물 Certificate Transparency IETF 2013-06
[33] 웹사이트 Introducing Certificate Transparency Monitoring https://blog.cloudfl[...] 2019-08-08
[34] 웹사이트 Certificate Transparency: FAQs https://www.digicert[...] 2015-06-03
[35] 뉴스 Another fraudulent certificate raises the same old questions about certificate authorities https://arstechnica.[...] 2011-08-30
[36] 웹사이트 How Certificate Transparency Works - Certificate Transparency https://sites.google[...] 2021-05-15
[37] 웹사이트 Certificate Transparency（証明書の透明性） https://www.websecur[...] DigiCert 2021-07-22
[38] 웹사이트 CT(Certificate Transparency) SCT証明書 https://valuessl.net[...] 2021-07-22
[39] 웹사이트 Chrome Certificate Transparency Policy https://googlechrome[...] Google 2021-07-22
[40] 웹사이트 Apple 2018年10月15日以降SSL証明書でCTを必須に https://rms.ne.jp/di[...] 2018-06-06
[41] 웹사이트 Known Logs - Certificate Transparency https://www.certific[...] 2015-12-31
[42] 웹사이트 DigiCert Announces Certificate Transparency Support https://www.darkread[...] Dark Reading 2013-09-24
[43] 웹사이트 Certificate Transparency Required for EV Certificates to Show Green Address Bar in Chrome https://blog.digicer[...] DigiCert 2014-12-05
[44] 간행물 Updated Certificate Transparency + Extended Validation plan https://cabforum.org[...] 2014-02-04
[45] 웹사이트 Symantec Certificate Transparency (CT) for certificates issued before June 1, 2016 https://knowledge.sy[...] Symantec 2016-06-09
[46] 웹사이트 Sustaining Digital Certificate Security https://security.goo[...] 2015-10-28
[47] 웹사이트 Certificate Transparency Enforcement in Google Chrome https://groups.googl[...] Google Groups 2018-02-07
[48] 웹사이트 Introducing Certificate Transparency and Nimbus https://blog.cloudfl[...] 2019-08-09
[49] 웹사이트 Certificate Transparency Version 2.0 https://tools.ietf.o[...] 2021-04-13
[50] 웹사이트 Introducing Oak, a Free and Open Certificate Transparency Log https://letsencrypt.[...] Let's Encrypt 2021-04-13
[51] IETF Certificate Transparency Version 2.0 2021-12
[52] 웹인용 Introducing Certificate Transparency Monitoring https://blog.cloudfl[...] 2019-08-09


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com