현행 Web PKI는 인증서의 기술적 유효성을 검증한다. Certificate Transparency는 인증서 발급 사실을 공개하고 CA와 로그의 행동을 감사할 수 있게 한다. 하지만 다음 질문은 여전히 별도로 남는다.기술적으로 유효하고 CT 로그에도 기록된 인증서가 실제 도메인 관리자가 사용하도록 승인한 인증서인가?CA의 도메인 통제권 검증, CT의 발급 투명성, 조직 내부의 인증서 승인 절차는 서로 다른 문제다. 이 글에서는 이 신뢰 공백을 분석하고, CT 기반 인증서 발견과 도메인 관리자 승인 기록, 브라우저의 실제 연결 인증서 비교를 결합하는 추가 검증 프로세스를 제안한다. 관련 배경은 이전 문서에서 다룬 바가 있다.「브라우저는 HTTPS 인증서를 어떻게 신뢰하는가」: 현행 Web PKI와 TLS..

현행 Web PKI는 브라우저가 서버 인증서의 서명 체인을 검증하고, 그 체인이 신뢰된 Root CA까지 이어지는지 확인하는 방식으로 동작한다. 그러나 CA가 잘못된 인증서를 발급하더라도 그 발급 사실이 외부에 공개되지 않는다면, 도메인 관리자는 해당 인증서가 실제 공격에 사용되거나 별도의 경로로 발견되기 전까지 문제를 인지하지 못할 수 있다. Certificate Transparency(CT)는 이 문제를 보완하기 위해 만들어진 공개 감사용 인증서 로그 생태계로 인증서 발급 사실을 공개 로그에 남기고 그 로그 자체도 암호학적으로 검증할 수 있게 만드는 구조이다. CA가 발급하는 인증서 또는 precertificate를 외부에서 조회 가능한 공개 로그에 기록함으로써, 도메인 관리자와 보안 연구자, 브라우..

HTTPS 연결에서 웹 브라우저는 서버가 제시한 인증서를 보고 해당 서버를 신뢰할 수 있는지 판단한다. 이 과정은 단순히 인증서에 적힌 발급자 이름을 확인하는 수준이 아니다. 먼저 서버 운영자가 키 쌍을 생성하고, CA가 도메인 통제권을 검증한 뒤 사이트 공개키와 도메인 정보를 디지털 서명으로 묶는다. 사용자가 사이트에 접속하면 브라우저는 TLS handshake에서 받은 인증서 체인의 서명을 단계적으로 검증하고, 마지막 인증서가 플랫폼의 Trust Store에 등록된 신뢰 앵커까지 이어지는지 확인한다. 이 일련의 과정은 비대칭 암호화 즉, 공개키를 기반으로 하는 구조(PKI)에 의존한다. Web PKI의 핵심은 다음 한 문장으로 요약할 수 있다.인증 기관(CA)이 “이 공개키는 이 도메인에 속한다”는..