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

HTTPS 연결에서 웹 브라우저는 서버가 제시한 인증서를 보고 해당 서버를 신뢰할 수 있는지 판단한다. 이 과정은 단순히 인증서에 적힌 발급자 이름을 확인하는 수준이 아니다. 

 

먼저 서버 운영자가 키 쌍을 생성하고, CA가 도메인 통제권을 검증한 뒤 사이트 공개키와 도메인 정보를 디지털 서명으로 묶는다. 사용자가 사이트에 접속하면 브라우저는 TLS handshake에서 받은 인증서 체인의 서명을 단계적으로 검증하고, 마지막 인증서가 플랫폼의 Trust Store에 등록된 신뢰 앵커까지 이어지는지 확인한다.

 

이 일련의 과정은 비대칭 암호화 즉, 공개키를 기반으로 하는 구조(PKI)에 의존한다.

 

Web PKI의 핵심은 다음 한 문장으로 요약할 수 있다.

인증 기관(CA)이 “이 공개키는 이 도메인에 속한다”는 내용을 디지털 서명으로 보증하고, 브라우저는 미리 신뢰하도록 등록된 Root CA까지 그 서명을 검증한다.

 

 

다만 실제 과정은 인증서 한 장을 단순히 확인하는 것보다 복잡하다. 인증서가 발급되는 단계와 사용자가 사이트에 접속해 검증하는 단계로 나누어 살펴보자.

 

이 글은 인증서 발급부터 TLS 1.3 handshake, 인증서 체인 구축, Root CA 신뢰, hostname·유효 기간·폐기·Certificate Transparency 검증까지 현행 Web PKI의 전체 흐름을 순서대로 설명한다.

인증서 발급 및 검증

 

공개키와 개인키 쌍의 생성

인증서 발급은 서버 운영자가 비대칭키 쌍을 만드는 것에서 시작한다.

 

Private Key

• 서버 운영자만 보관
• TLS handshake에서 서버가 키 소유자임을 증명할 때 사용
• 유출되면 공격자가 서버를 사칭할 수 있음

Public Key

• 외부에 공개 가능
• 최종적으로 서버 인증서 안에 포함됨
• 브라우저가 서버의 서명을 검증할 때 사용

중요한 점은 **인증서가 공개키 그 자체가 아니라, 공개키와 도메인 정보를 CA가 서명한 문서**라는 것이다.

 

CSR - CA에 보내는 인증서 발급 요청

서버 운영자는 키 쌍 생성 후, 공개키와 도메인 정보를 담은 CSR(Certificate Signing Request)을 만든다.

CSR에는 일반적으로 다음 정보가 들어간다.

• 인증서에 포함할 공개키
• 인증서를 사용할 도메인 이름
• 요청하는 인증서 확장 정보
• CSR 자체의 서명

CSR
├─ Public Key: server-public-key
├─ Requested SANs
│   ├─ example.com
│   └─ www.example.com
└─ Signature made with server-private-key

 

CSR에 포함된 서명은 "요청자가 CSR 속 공개키와 짝을 이루는 개인키를 실제로 가지고 있음"을 보여준다. 그러나 이것만으로 "요청자가 해당 도메인의 정당한 관리자인지"는 알 수 없다.

CA의 검증

CA는 인증서를 발급하기 전에 CSR 신청자가 대상 도메인을 통제하는지 확인한다. 자동화된 공개 인증서 발급에서는 흔히 다음과 같은 방식이 사용된다.

HTTP-01
→ CA가 지정한 값을 해당 도메인의 HTTP 경로에 게시

DNS-01
→ CA가 지정한 값을 DNS TXT 레코드에 게시

TLS-ALPN-01
→ 지정된 TLS 응답을 제공해 도메인 통제권 증명

 

이 검증의 의미는 “신청자가 지금 이 도메인의 특정 검증 경로를 통제할 수 있다”는 것이다. 그러나 이 검증이 "신청자가 조직 내부의 보안 담당자가 맞음"까지 보장하지는 않는다.

CA의 디지털 서명

CA가 검증을 완료하면 사이트의 공개키와 도메인 정보를 포함한 X.509 인증서를 만든다. 인증서는 크게 다음 세 부분으로 볼 수 있다.

Certificate
├─ TBSCertificate
│   ├─ Subject / Subject Alternative Name
│   ├─ Subject Public Key
│   ├─ Issuer
│   ├─ Serial Number
│   ├─ Validity
│   └─ Extensions
├─ Signature Algorithm
└─ CA Signature

 

TBSCertificate 부분은 “서명될 인증서 본문”이라는 뜻이다. 여기에는 사이트의 공개키, 도메인 이름, 발급자, 유효 기간과 여러 정책 정보가 들어간다.

 

CA는 다음과 같이 해시 함수를 사용하여 인증서에 대한 서명을 생성한다.

certificateHash = Hash(TBSCertificate)

certificateSignature = Sign(CA_Private_Key, certificateHash)

 

 

브라우저는 나중에 사이트에 접속할 때 CA의 공개키를 이용해 이 서명을 검증한다. certificateSignature을 CA_Public_Key로 복호화한 결과와 Hash(TBSCertificate) 값이 같은지를 검사한다.

Verify(
    CA_Public_Key,
    certificateSignature,
    Hash(TBSCertificate)
)

 

서명이 유효하면 다음 두 가지를 확인할 수 있다.

1. 인증서 본문이 CA가 서명한 이후 변경되지 않았다.
2. 해당 서명은 대응하는 CA 개인키를 가진 주체가 생성했다.

따라서 인증서는 사실상 다음과 같은 CA의 서명된 진술이다.

 

이 인증서에 적힌 도메인 이름과 공개키의 결합을 이 유효 기간과 정책 범위 안에서 보증한다.

 

 

인증서의 서명 주체

TBSCertificate를 서명하는 주체는 Root CA가 아니라 Intermediate CA이다. 공개적으로 신뢰되는 Root CA의 개인키는 전체 신뢰 체계의 출발점이다. 혹시라도 이 키가 유출되면 해당 Root가 만든 모든 하위 신뢰 관계가 위험해질 수 있다.

 

그래서 Root CA는 보통 일상적인 서버 인증서를 직접 서명하지 않는다. 대신 Intermediate CA 인증서를 직접 발급하고, 이렇게 Root CA로부터 권한을 위임받은 Intermediate CA가 실제 leaf certificate 발급을 담당한다.

 

Root CA
  └─ signs → Intermediate CA
                 └─ signs → www.example.com Leaf Certificate

 

이 구조는 Root CA 개인키를 더 강하게 보호하면서, Intermediate CA 단위로 발급 권한과 피해 범위를 분리할 수 있게 한다.

 

인증서 설치 후 TLS handshake

이렇게 발급받은 인증서가 서버에 설치된 뒤 사용자가 `https://www.example.com`에 접속하면 TLS handshake가 시작된다.

TLS 1.3을 단순화한 흐름은 다음과 같다.

 

TLS 1.3 handshake

 

 

 

이 과정에서 인증서는 두 가지 역할을 수행한다.

1. CA 서명 검증
   - 인증서에 들어 있는 서버 공개키가 해당 도메인에 연결된 믿을 수 있는 키인지 확인한다.

2. 서버의 개인키 보유 증명
   - 서버는 `CertificateVerify` 메시지에서 지금까지의 handshake transcript에 서명하고, 
     브라우저는 인증서 안의 서버 공개키로 이 서명을 확인한다.

 

즉 브라우저는 다음을 모두 확인한다.

• CA가 이 서버 공개키와 도메인의 관계를 보증했는가?
• 현재 연결 상대가 그 공개키에 대응하는 개인키를 실제로 가지고 있는가?

TLS 1.3에서는 일반적으로 인증서 공개키로 세션 키를 직접 암호화하는 것이 아니다. ECDHE 등의 일회성 key share로 공유 비밀을 만들고, 인증서와 `CertificateVerify`는 서버 인증에 사용된다.

 

서버가 보내는 인증서 체인

서버는 보통 다음 인증서를 보낸다.

인증서 체인
├─ Leaf Certificate: www.example.com
└─ Intermediate CA Certificate

 

일반적으로 서버는 Root CA Certificate를 전송하지 않는데, Root CA는 로컬 브라우저 또는 운영체제 내부(Trust Store)에 이미 저장되어 있기 때문이다.

 

예를 들어 서버가 다음 체인을 보냈다고 하자.

Leaf
Subject: www.example.com
Issuer: Example Intermediate CA

Intermediate
Subject: Example Intermediate CA
Issuer: Example Root CA

 

브라우저는 로컬 Trust Store에서 `Example Root CA`에 해당하는 신뢰 앵커를 찾아 인증 경로를 구성한다.

www.example.com Leaf
    → Example Intermediate CA
        → Example Root CA in Trust Store

 

인증서 체인은 발급자 이름만 비교하는 것이 아니다

`Issuer`와 `Subject` 이름은 후보 인증서를 찾는 단서가 될 수 있지만, 이름이 같다는 이유만으로 신뢰하지 않는다.

브라우저는 각 단계의 디지털 서명을 상위 인증서의 공개키로 검증한다.

TLS 1.3에서의 인증서 체인을 통한 인증 경로 구축

 

검증 A
Leaf Certificate의 서명
→ Intermediate CA 공개키로 검증

검증 B
Intermediate CA Certificate의 서명
→ Root CA 공개키로 검증

검증 C
Root CA
→ 로컬 Trust Store에서 신뢰 앵커로 허용되었는지 확인

 

인증서 체인의 관계를 조금 더 구체적으로 표현하면 다음과 같다.

Leaf.TBSCertificate
+ Leaf.Signature
+ Intermediate.PublicKey
	→ Leaf 서명 검증

Intermediate.TBSCertificate
+ Intermediate.Signature
+ Root.PublicKey
	→ Intermediate 서명 검증
   
Root.Certificate
+ Browser / OS Trust Store
	→ Root가 신뢰 앵커로 등록되어 있는지 확인

 

서명 검증에 실패하면 공격자가 인증서 내용을 바꿨거나 올바른 상위 CA가 발급한 인증서가 아니므로 체인을 신뢰할 수 없다.

Root의 Certificate 검증까지 성공한다면 Leaf → Intermediate → Root로 이어지는 인증 경로를 신뢰할 수 있게 된다.

Root 인증서 검증 원리

Root CA 인증서는 따지고 보면 자기 자신의 개인키로 서명된 self-signed 인증서다. 그러나 self-signature 자체는 누구나 만들 수 있으므로, Leaf나 Intermediate 검증 때와는 다르게 인증서에 대한 서명이 신뢰의 근거가 될 수는 없다.

 

Root CA를 검증하는 기준은 로컬 Trust Store에 저장된 목록 중에 해당 인증서 또는 공개키가 존재하는지 여부이다.

 

운영체제·브라우저의 Trust Store은 신뢰 앵커로 Root CA의 인증서 또는 공개키를 사전 등록하기 때문이다.

 

따라서 인증 경로 검증은 사전에 로컬에 저장된 신뢰 앵커 대조로 마무리된다. Root의 self-signature를 다시 다른 CA가 보증하는 식으로 무한히 올라가지 않는다.

Trust Store의 관리

Trust Store의 구체적인 관리 방식은 플랫폼에 따라 다르다.

• 운영체제의 시스템 인증서 저장소를 사용하는 브라우저
• 자체 Root Store와 Root Program을 관리하는 브라우저
• 기업 정책으로 사설 Root CA가 추가된 환경
• 모바일 운영체제가 관리하는 시스템 Root Store

따라서 브라우저는 자신이 적용하는 플랫폼·브라우저 정책상의 Trust Store에서 신뢰 앵커를 찾는다.

브라우저의 추가 검증

신뢰된 Root까지 서명이 이어진다고 해서 인증서가 자동으로 신뢰되는 것은 아니다. 브라우저는 인증 경로와 leaf certificate에 대해 여러 조건을 함께 검증한다.

호스트 이름 검증

접속한 "www.example.com"이 leaf certificate의 Subject Alternative Name(SAN)에 포함되어 있는지 확인한다.

현재 접속 주소: www.example.com

SAN:
  - example.com
  - www.example.com

→ SAN에 포함

 

다음 인증서는 서명 체인이 정상이어도 현재 접속에는 사용할 수 없다.

현재 접속 주소: www.example.com

SAN:
  - api.example.com

→ SAN에 미포함

 

유효 기간

현재 시간이 "notBefore"와 "notAfter" 사이인지 확인한다.

notBefore <= current time <= notAfter

 

CA 권한과 경로 제약

중간 인증서가 실제로 하위 인증서에 서명할 수 있는 CA 인증서인지 확인한다.

• Basic Constraints: CA = TRUE
• Key Usage: keyCertSign
• 허용된 path length
• Name Constraints
• Certificate Policies

공격자가 일반 leaf certificate로 다른 인증서에 서명해도, 이 제약 검증을 통과하지 못한다.

 

서버 인증 용도

leaf certificate가 TLS 서버 인증에 사용 가능한지 확인한다.

Extended Key Usage
→ serverAuth

 

알고리즘과 키 정책

브라우저가 더 이상 안전하지 않다고 보는 서명 알고리즘이나 지나치게 약한 키는 거부될 수 있다.

 

폐기 상태

인증서가 만료 전에 폐기되었는지 CRL 또는 OCSP 같은 메커니즘을 통해 확인할 수 있다. 실제 브라우저의 폐기 처리 정책과 실패 시 동작은 구현마다 차이가 있다.

 

Certificate Transparency

공개 신뢰 TLS 인증서는 브라우저 정책에 따라 SCT 등 CT 증거를 요구받을 수 있다. CT는 인증서가 공개 로그 생태계에 제출되었다는 검증 가능성을 제공한다.

 

현행 시스템

실제 예시

현재 PKI 시스템에서 "www.example.com" 도메인에 접속하기 위한 전체 과정을 예시로 알아보자.

발급 시점

1. 운영자가 서버 키 쌍을 생성한다.
2. CSR에 www.example.com과 서버 공개키를 넣는다.
3. CA가 DNS 또는 HTTP 방식으로 도메인 통제권을 검증한다.
4. Intermediate CA가 leaf certificate에 서명한다.
5. 운영자가 서버에 개인키, leaf 인증서, intermediate 인증서를 설치한다.

 

접속 시점

1. 사용자가 https://www.example.com에 접속한다.
2. 서버가 TLS handshake에서 leaf와 intermediate 인증서를 보낸다.
3. 브라우저가 로컬 Trust Store의 Root까지 경로를 구성한다.
4. Intermediate 공개키로 leaf의 CA 서명을 검증한다.
5. Root 공개키로 intermediate의 서명을 검증한다.
6. Root가 신뢰 앵커인지 확인한다.
7. SAN에 www.example.com이 있는지 확인한다.
8. 유효 기간, Key Usage, EKU, 제약, 정책을 검사한다.
9. 서버의 CertificateVerify 서명으로 개인키 보유를 확인한다.
10. 검증이 끝나면 암호화된 HTTPS 통신을 시작한다.

 

이 과정을 통과하면 브라우저가 확인한 것은 다음과 같다.

• 현재 연결 상대는 인증서 공개키의 개인키를 보유한다.
• 해당 공개키와 www.example.com의 결합은 브라우저가 신뢰하는 CA 체인으로 서명되어 있다.
• 인증서와 경로가 브라우저 정책을 만족한다.

현행 Web PKI의 한계

여기까지의 검증은 강력하지만 다음 사실을 자동으로 보장하지는 않는다.

도메인 운영 조직의 보안 담당자가 이 발급을 승인했는가?
이 인증서가 조직 내부 자산 목록에 등록되어 추적되고 있는가?
해당 도메인의 정당한 관리자가 실제 운영을 위해 발급한 인증서인가?
외부 협력사 등에서 임시로 발급한 인증서인가?

 

CA가 확인하는 도메인 통제권과 조직 내부의 정당한 승인 권한은 같은 개념이 아니다.

따라서 인증서가 Web PKI 관점에서 유효하다는 판단과 도메인 관리자가 사용을 승인했다는 판단 사이에는 여전히 별도의 신뢰 공백이 남는다.

 

바로 이 지점에서 추가적인 관리자 승인 기반 검증 계층의 필요성이 드러난다.