발급된 인증서와 승인된 인증서: 도메인 관리자 승인 기반 추가 검증 프로세스 제안

현행 Web PKI는 인증서의 기술적 유효성을 검증한다. Certificate Transparency는 인증서 발급 사실을 공개하고 CA와 로그의 행동을 감사할 수 있게 한다.

 

하지만 다음 질문은 여전히 별도로 남는다.

기술적으로 유효하고 CT 로그에도 기록된 인증서가 실제 도메인 관리자가 사용하도록 승인한 인증서인가?

CA의 도메인 통제권 검증, CT의 발급 투명성, 조직 내부의 인증서 승인 절차는 서로 다른 문제다. 이 글에서는 이 신뢰 공백을 분석하고, CT 기반 인증서 발견과 도메인 관리자 승인 기록, 브라우저의 실제 연결 인증서 비교를 결합하는 추가 검증 프로세스를 제안한다.

 

관련 배경은 이전 문서에서 다룬 바가 있다.

• 「브라우저는 HTTPS 인증서를 어떻게 신뢰하는가」: 현행 Web PKI와 TLS 인증서 검증
• 「Certificate Transparency는 어떻게 인증서 발급을 공개하고 감사 가능하게 만드는가」: CT 로그와 생태계

브라우저는 HTTPS 인증서를 어떻게 신뢰하는가: 현행 Web PKI와 TLS 인증서 검증

 

Certificate Transparency: 웹 인증서 관련 공개 감사용 로그 생태계

 

유효한 인증서와 승인한 인증서

인증서가 Web PKI 정책상 유효하다고 해서 반드시 도메인 운영자가 기대한 인증서라는 뜻은 아니다. 다음과 같은 문제 상황이 가능하다.

• CA가 잘못된 주체에게 인증서를 발급했다.
• 공격자가 일시적으로 DNS 또는 도메인 검증 경로를 장악했다.
• 외부 협력사나 내부 조직이 정식 승인 없이 인증서를 발급했다.
• 테스트 환경 인증서가 운영 환경에 사용되었다.
• 더 이상 사용하지 않는 인증서가 서버에 남아 있다.
• 인증서가 갱신되었지만 보안 담당자가 이를 인지하지 못했다.
• 조직이 허용하지 않은 CA에서 인증서가 발급되었다.

이러한 인증서는 정상적인 CA 체인과 유효한 CT 증거를 가질 수 있다.

Web PKI 검증 성공 + CT 정책 충족 ≠ 도메인 관리자 허가

 

브라우저와 CT가 확인하지 않는 질문은 다음과 같다.

이 인증서가 조직의 정식 발급 요청과 연결되는가?
보안 담당자가 발급 사실을 검토했는가?
현재 운영 환경에서 사용하도록 승인되었는가?
폐기 또는 교체 대상으로 분류된 인증서는 아닌가?

 

현행 시스템에 남는 신뢰 공백

현재 인증서 생태계를 세 계층으로 나누면 다음과 같다.

계층	답하는 질문
Web PKI	인증서가 신뢰된 CA 체인과 브라우저 정책을 만족하는가?
Certificate Transparency	인증서 발급 사실이 공개되고 감사 가능한가?
관리자 승인 계층	인증서를 실제 도메인 관리자가 검토하고 사용을 승인했는가?

 

앞의 두 계층은 현재 널리 구축되어 있지만, 세 번째 계층은 일반 브라우저 검증에 포함되어 있지 않다. 브라우저가 CT에서 인증서를 발견할 수 있다는 것이 그 인증서를 실제 관리자가 신청하고 발급했다는 것은 아니다.

CT:
“이 인증서가 발급되었다.”

추가 승인 계층:
“이 인증서는 검토되었으며 현재 사용이 허용되었다.”

 

중요 도메인의 인증서 보안 체계

네이버나 구글처럼 하나의 인증서 오발급·개인키 탈취가 대규모 사용자 피해로 이어질 수 있는 중요 도메인은 CT 모니터링 하나에 의존하지 않고, 인증서 발견과 인벤토리 관리, 발급·갱신·폐기 등 수명주기 자동화, HSM·KMS를 통한 개인키 보호, SIEM·SOC와의 보안 이벤트 연동을 모두 하나의 인증서 보안 체계로 통합해 운영한다.

 

CT 모니터링은 외부에서 새로 발급된 인증서를 탐지하고, 인증서 발견 기능은 조직 내부와 클라우드에 흩어진 미관리 인증서를 식별하며, 수명주기 자동화는 만료와 갱신 실패를 방지한다. 개인키 보호는 인증서가 정상적으로 승인된 이후에도 키 탈취로 서버가 사칭되는 위험을 낮추고, 보안 이벤트 연동은 오발급·미승인 발급·폐기 인증서 사용 같은 이상 징후를 실제 대응 절차로 연결한다.

 

즉, 중요 도메인은 인증서의 발견·발급·보관·사용·감시·폐기·대응 전 과정을 관리하는 다층적이고 통합된 보안 체계를 추가적으로 적용하고 있음을 이해해야 한다.

 

이러한 다층 구조는 미인가 인증서 발급, 미관리 인증서, 갱신 실패, 개인키 유출과 같은 서로 다른 위험을 보완적으로 탐지하고 대응할 수 있다는 장점이 있지만, 여러 상용 서비스와 보안 인프라를 도입하고 24시간 모니터링·정책 관리·장애 대응을 담당할 전문 인력을 유지해야 한다는 비용 문제가 있다.

 

특히 관리하는 도메인과 인증서가 많고 글로벌 인프라가 복잡한 조직일수록 이러한 보안 체계의 복잡도가 그나마 의미 있게 작동한다. 물론 이 복잡한 체계가 얼마나 강력한지와 별개로 보안 서비스 구독료뿐 아니라 HSM·KMS 운영비, API 사용료, 시스템 연동과 유지보수, 보안 인력 비용 등 전체 인증서 보안 비용이 크게 증가할 수 있다.

 

현재의 강력한 인증서 보안은 여러 통제를 중첩하는 복잡도가 높은 방식이라 대규모 조직은 돼야 감당할 만한 높은 구축·운영 비용을 요구한다

추가 검증 프로세스의 기본 아이디어

추가 프로세스의 메커니즘

결국 인증서의 오발급이 발생했을 때, 이를 빠르게 감지하여 치명적인 문제를 막는다는 측면에서 관리자 승인 기반 추가 검증 프로세스를 제안한다. 즉, 인증서의 발급 기록은 CT에, 관리자가 해당 인증서를 허가했다는 승인 기록은 공개된 블록체인에 기록하여 브라우저가 TLS로 인증서 검증을 할 때, 블록체인 조회를 통한 승인 기록 검증을 추가할 수 있다. 여기서 블록체인은 모두가 검증 가능한 공개 장부 인프라로서 채택됐다.

 

다음 프로세스를 생각할 수 있다.

도메인 관리자
1. CT 생태계에서 도메인 관련 인증서를 발견한다.
2. 도메인 관리자가 인증서를 검토한다.
3. 승인 또는 폐기 상태를 블록체인에 기록한다.

브라우저
1. 브라우저는 실제 TLS 연결에서 받은 leaf certificate를 읽는다.
2. 현재 인증서 fingerprint를 토대로 블록체인에서 관리자 승인 기록을 조회한다.
3. 결과를 사용자에게 추가 보안 신호로 제공한다.

이 프로세스는 브라우저의 TLS 검증 위에서 동작한다.

브라우저 기본 TLS 검증
+ CT 기반 발급 투명성
+ 도메인 관리자 승인 상태 검증

즉, 기존 Web PKI 인프라와 CT 생태계의 검증 위에 조직의 의사결정을 반영하는 보조 계층을 추가하는 방식이다.

 

관리자 측 프로세스: 인증서 발견과 승인

관리자 측 시스템은 CT 검색 또는 모니터링 소스를 이용해 도메인에 발급된 인증서를 수집한다.

CT Logs / Search Source
→ 도메인별 인증서 선택
→ 관리자 검토
→ Approved / Revoked 상태 결정
→ 승인 레지스트리에 기록

 

관리자의 인증서 승인 프로세스

 

인증서 승인 취소 프로세스

 

관리자는 다음 정보를 검토할 수 있다.

• 인증서의 SAN과 서브도메인 범위
• 발급 CA
• 인증서 유효 기간
• SHA-256 fingerprint
• 공개키 정보
• 발급 시점
• 내부 변경 요청 또는 배포 티켓
• 현재 운영 환경에서의 사용 여부

관리자는 CT 인프라를 활용해 인증서 단위로 접근하고, 각각에 대한 승인 여부를 새로운 레지스트리에 기록함으로써 추가적으로 관리할 수 있다.

승인 인증서 전용 관리 모듈

 

사용자 측 프로세스: 실제 연결 인증서 비교

관리자 승인 목록만 있어서는 사용자가 현재 어떤 인증서를 받았는지 알 수 없다. 브라우저 측에서는 실제 TLS 연결에서 수신한 leaf certificate를 관찰하고 승인 목록과 직접 대조해야 한다.

사용자가 HTTPS 사이트에 접속
→ 브라우저가 기본 TLS 검증
→ 확장 또는 보조 모듈이 leaf certificate 추출
→ SHA-256 fingerprint 계산
→ 도메인별 승인 상태 조회
→ 현재 fingerprint와 비교
→ 결과 UI 표시

 

CT에는 과거 인증서, 갱신 예정 인증서, 테스트 인증서와 현재 운영 인증서가 함께 존재할 수 있다. 따라서 CT 검색 결과만으로 현재 사용 중인 인증서를 판단해서는 안 된다.

 

핵심은 브라우저가 실제 연결에서 전달받은 인증서를 비교한다는 것이다.

 

왜 인증서 fingerprint를 사용하는가

X.509 인증서 전체를 레지스트리에 저장하면 비용과 구현 복잡도가 커질 수 있다. 대신 인증서 DER 바이트의 SHA-256 fingerprint를 식별자로 사용할 수 있다. 실제 CT 검색 서비스에서도 이런 방식으로 식별자를 정의하고 색인한다.

leaf certificate DER
→ SHA-256
→ certHash

fingerprint 방식은 다음 장점이 있다.

• 고정 길이 값으로 비교 가능
• 인증서 원본 전체를 저장할 필요 없음
• 인증서 내용이 달라지면 fingerprint도 변경
• 브라우저가 받은 인증서와 승인 인증서를 정확히 비교 가능

도메인도 일관되게 정규화해야 한다.

Example.COM.
→ example.com
→ domainHash

정규화 정책에는 다음을 고려해야 한다.

• 대소문자
• 마지막 점
• 국제화 도메인과 Punycode
• apex와 www 관계
• wildcard 정책
• 서브도메인별 권한 범위

 

레지스트리에는 무엇을 기록해야 하는가

개념적인 승인 상태는 다음과 같이 설계할 수 있다.

Domain
├─ Owner / Approver
└─ Certificates
    ├─ certHash A: Approved
    ├─ certHash B: Revoked
    └─ certHash C: Approved

 

최소한 다음 정보가 필요하다.

• 도메인 식별자
• 인증서 fingerprint
• 승인 상태
• 승인 또는 폐기 시각
• 승인 주체
• 상태 변경 이력
• 선택적으로 인증서 만료일과 메타데이터

상태는 단순한 boolean보다 명시적인 enum이 적합하다.

UNKNOWN
APPROVED
REVOKED

 

공개 검증 가능한 레지스트리의 필요성

승인 기록은 중앙 데이터베이스에도 저장할 수 있다. 그러나 다음 요구가 있다면 공개 검증 가능한 레지스트리를 고려할 수 있다.

• 승인과 폐기 이력을 외부에서 검증
• 변경 기록의 위변조 저항성
• 여러 클라이언트가 동일한 상태 공유
• 단일 관리 서버와 분리된 조회 경로
• 승인 주체의 서명 기반 증명

블록체인 기반 레지스트리는 하나의 선택지다.

mapping(bytes32 => address) public domainOwner;
mapping(bytes32 => mapping(bytes32 => CertificateStatus)) public certificates;

 

다만 블록체인이 항상 필수인 것은 아니다. CT 프로토콜에서와 같이 투명 로그, 서명된 상태 목록, 재현 가능한 감사 로그도 요구사항에 따라 대안이 될 수 있다. 그러나 로그(실시간성, 누락방지)를 기록하려는 목적인 CT와 다르게 선택적인 승인 여부 이벤트를 기록하는 특성상 이미 완성된 인프라로서 존재하는 공유 원장 시스템인 블록체인을 쓰지 않을 이유가 없다.

 

핵심은 저장 기술 자체보다 다음 속성이다.

누가 승인했는가?
무엇을 승인했는가?
언제 상태가 변경되었는가?
클라이언트가 그 기록을 독립적으로 검증할 수 있는가?

 

제안 시스템의 고려 사항

도메인 제어권과 승인 권한 연결

현재 web PKI에서 CA가 신청자의 challenge를 기반으로 인증서를 발급해주는 것과 마찬가지로, 승인 레지스트리가 신뢰를 가지려면 승인 주체가 실제 도메인 관리 권한을 가진 주체인지 확인해야 한다. 여기서 DNS TXT challenge를 사용할 수 있다.

1. 사용자가 도메인 등록을 요청한다.
2. 시스템이 일회성 challenge를 생성한다. (예시: 승인자의 온체인 계정 주소를 기록하라)
3. 사용자가 DNS TXT 레코드에 challenge를 게시한다. 
4. 검증 모듈이 authoritative DNS를 조회한다.
5. challenge가 일치하면 도메인 제어권을 확인한다.
6. 검증된 계정 또는 주소에 승인 권한을 부여한다.

 

_certificate-approval.example.com
TXT "verification=<challenge>"

 

설계 시 다음을 결정해야 한다.

• challenge 만료 시간
• 재사용 방지
• DNS propagation과 cache 처리
• authoritative DNS 기준 조회
• apex와 subdomain 권한 구분
• wildcard 인증서 승인 권한
• owner 변경과 재검증
• DNSSEC 결과 활용 여부

DNS 제어권 검증은 CA의 DV와 유사한 면이 있지만 목적은 다르다. CA는 신청자의 인증서 발급 자격을 확인하는 것이고, 이 시스템은 승인 레지스트리의 관리 권한을 바인딩하는 것이다. 물론 CA의 challenge를 파훼한 공격자라면 이 추가 시스템의 challenge 마저 파훼할 가능성도 존재한다.

 

그러나 대부분의 인증서 탈취 사례는 외부에 임시로 발급된 인증서를 통한 공격이라는 점에서 내부자임을 증명하는 DNS TXT challenge는 가장 효과적인 기법이다. 이 challenge를 반복적으로 파훼당해 얻은 피해라면 웹의 보안 인프라라기보단 도메인 관리 조직의 허술함이 그 이유일 가능성이 높다.

 

게다가 이 추가 프로세스는 인증서의 신뢰성을 직접 제한하기보다, 그저 브라우저에게 도메인 관리자의 승인 여부에 대한 정보를 신호로 추가 제공하는 것일뿐이므로 공격자로 하여금 그 난이도에 비해 얻는 효용이 크지않다.

 

즉, 정당한 관리자는 쉬운 challenge를 통해 브라우저에게 승인 신호를 추가 제공할 수 있는 것이나 공격자는 겨우 추가적인 승인 신호를 위해 번거로운 challenge를 파훼해야 한다는 것이다.

브라우저에서 표시할 검증 상태

사용자에게 결과를 성공과 실패 두 가지로만 보여주면 안 된다.

상태	의미
Approved	현재 fingerprint가 관리자 승인 기록과 일치
Unapproved	조회에는 성공했지만 승인 기록이 없음
Revoked	관리자가 폐기 상태로 기록
Unknown	네트워크·RPC·레지스트리 오류로 확인 불가

 

특히 Unapproved와 Unknown을 구분해야 한다.

Unapproved:
정상 조회 결과 승인 목록에 없음

Unknown:
승인 상태 조회 자체가 실패함

 

브라우저 확장자 팝업

 

인증서 갱신과 운영 정책

인증서가 갱신되면 일반적으로 fingerprint가 바뀐다. 따라서 정상 갱신도 승인 반영 전에는 미승인으로 보일 수 있다. 이를 줄이기 위해 다음 정책을 고려할 수 있다.

• 신규 인증서 사전 등록
• CT 신규 발급 알림
• 제한된 grace period
• ACME 클라이언트와 승인 흐름 연동
• 운영 배포 전에 승인 완료
• 다중 관리자 승인
• 기존 인증서와 신규 인증서의 중첩 기간 지원

자동 승인은 주의해야 한다.

CT에서 발견됨
→ 자동 승인

 

이 구조는 CA 오발급 인증서도 자동 승인할 수 있다. 따라서 자동화는 발견과 정보 수집에 사용하고, 최종 승인에는 별도 정책이나 사람의 검토를 두는 편이 안전하다.

제안 시스템의 위협 모델

탐지 또는 완화하려는 대상

• CA 오발급
• 관리자가 모르는 인증서 발급
• 일시적인 DNS 탈취를 통한 발급
• 조직 정책에 승인되지 않은 CA 사용
• 승인되지 않은 인증서의 운영 사용
• 폐기된 인증서 재사용
• 외부 협력사의 비인가 발급
• CT에서 발견된 미인지 인증서

직접 방어하지 못하는 대상

• 정상 인증서를 사용하는 피싱 도메인
• 서버 자체 침해
• 사용자 단말 악성코드
• Root CA 저장소 오염
• 승인자 계정 또는 지갑 키 탈취
• 잘못된 domain owner 등록
• 승인된 인증서의 개인키 탈취
• TLS를 사용하지 않는 HTTP
• 악의적인 브라우저 또는 검증 모듈

승인된 인증서의 개인키가 탈취되면 fingerprint는 여전히 승인값과 일치한다. 따라서 이 시스템은 개인키 보호와 서버 보안이 전제된 기존 Web PKI 인프라 위에서 추가적인 신뢰를 제공할 뿐이다.

브라우저 확장 방식

현재 제안하는 브라우저 확장 방식은 TLS 연결이 수립된 뒤 인증서의 승인 여부를 검사한다.

도메인 인증서 검증: TLS handshake 도중
  → 인증서 체인 획득
  → leaf 검증(서명 검증)
  → intermediate 검증(서명 검증)
  → root 검증(trust store 대조)
  
인증서 승인 검증: TLS connection 이후  
  → 인증서 검증 단계에서 사용한 leaf 인증서 획득
  → 레지스트리에서 승인 상태 조회
  → 경고 UI 표시

 

따라서 연결 전 차단보다는 사후 검증과 경고만이 가능하다. 만약 연결 전 통제까지 고려한다면 다음 구조가 필요할 수 있다.

• 로컬 프록시
• 네트워크 보안 에이전트
• 커스텀 브라우저
• 운영체제 네트워크 필터
• 기업용 보안 게이트웨이

하지만 이 방식은 루트 인증서 설치, TLS 중간자 처리, 프라이버시, 성능과 배포 복잡도를 추가한다.

실시간 모니터링과 보안 운영 연동

추가 검증 시스템은 CT 이벤트를 실시간으로 감시하는 방향으로 확장할 수 있다.

CT 신규 인증서 이벤트
→ 등록 도메인 매칭
→ fingerprint 계산
→ 기존 승인 목록과 비교
→ 관리자 알림
→ 검토 및 상태 등록

 

조직의 기존 보안 운영과도 연결할 수 있다.

• Slack·Discord·Email 알림
• SIEM 이벤트
• 보안 티켓 자동 생성
• 허용되지 않은 CA 탐지
• 인증서 자산 대시보드
• 만료와 갱신 상태 추적
• 변경 관리 시스템 연동

이 경우 시스템은 브라우저 경고 기능을 넘어 인증서 자산 관리와 정책 집행 도구로 발전할 수 있다. 즉, 기존의 복잡한 통합 보안 시스템에 포함된 몇가지 장치를 간단하게 대체할 수 있다. 이는 비용 경감과 직결된다.

제안 프로세스의 핵심 의미

세 검증 계층은 서로 다른 질문에 답한다.

Web PKI:
이 인증서가 기술적으로 유효한가?

Certificate Transparency:
이 인증서 발급 사실이 공개되고 감사 가능한가?

도메인 관리자 승인:
이 인증서가 실제 운영에 사용되도록 정당한 관리자로부터 승인됐는가?

 

CT가 인증서 발급을 보이게 만들었다면, 추가 승인 프로세스는 발급된 인증서에 대한 운영 조직의 의사결정을 검증 가능하게 만든다. 이 시스템의 목적은 기존 Web PKI와 CT를 유지하면서, 그 위에 조직의 인증서 승인 정책을 하나의 추가 보안 신호로 연결하는 것이다.

마무리

현행 Web PKI는 인증서의 기술적 유효성을 검증하고, CT는 발급 사실을 공개적으로 감사할 수 있게 한다. 그러나 다음 두 문장은 같은 뜻이 아니다.

이 인증서는 발급되었다.
이 인증서는 사용하도록 승인되었다.

 

이 차이를 보완하려면 다음과 같은 흐름을 추가할 수 있다.

CT에서 도메인 관련 인증서를 발견한다.
→ 관리자가 인증서를 검토한다.
→ 승인과 폐기 상태를 검증 가능한 레지스트리에 기록한다.
→ 브라우저가 실제 연결 인증서를 읽는다.
→ 현재 fingerprint와 승인 기록을 비교한다.
→ 사용자와 보안 운영자에게 추가 신호를 제공한다.

 

궁극적으로 필요한 것은 Web PKI를 대체하는 새로운 신뢰 체계가 아니라, 인증서 발급 사실과 실제 운영 승인 사실을 구분해 검증할 수 있는 보조 프로세스다.

 

https://github.com/sweatbuckets/30fi30ficate

GitHub - sweatbuckets/30fi30ficate: 접속하려는 사이트 TLS 인증서의 도메인 관리자 승인 여부를 검증하는

 

참고 자료

• Certificate Transparency Community: https://certificate.transparency.dev/community/
• RFC 9162 — Certificate Transparency Version 2.0: https://datatracker.ietf.org/doc/html/rfc9162
• MDN — webRequest.getSecurityInfo(): https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/getSecurityInfo