HTTPS 인증서는 브라우저가 어떻게 믿는 걸까?

https://로 시작하는 사이트에 접속하면 브라우저는 별다른 질문 없이 서버와 암호화된 통신을 시작한다.

우리는 이 과정을 너무 자연스럽게 받아들인다.

그런데 조금 이상하다.

처음 접속하는 서버라면 브라우저는 그 서버를 한 번도 본 적이 없다. 서버가 보내온 인증서 역시 인터넷을 통해 처음 받은 데이터일 뿐이다.

그런데 브라우저는 어떻게,

“이 서버는 정말 example.com이 맞다.”

라고 판단할 수 있을까?

처음에는 나도 단순히 “CA가 인증서를 발급했으니까 브라우저가 믿는 것” 정도로 생각했다.

그런데 조금 더 파고들어 보니 HTTPS의 신뢰 구조는 생각보다 훨씬 흥미로웠다.

브라우저가 실제로 믿는 것은 서버가 아니다.

정확히는,

이미 신뢰하기로 결정되어 있는 어떤 지점까지 연결되는 ‘증명의 사슬’을 믿는다.

그리고 그 시작점에 Root CA가 있다.

인증서가 있다고 해서 믿을 수 있는 건 아니다

우선 서버가 가진 인증서부터 보자.

TLS 연결 과정에서 서버는 브라우저에게 자신의 인증서를 전달한다.

인증서에는 대략 이런 정보가 들어 있다.

Subject
Subject Alternative Name
Issuer
Public Key
Validity
Signature Algorithm
Signature

쉽게 말하면,

이 인증서는 example.com의 것이고
이 공개키를 사용하며
2026년 XX월까지 유효하고
이 CA가 발급했습니다.

라는 정보가 담긴 문서다.

여기까지만 보면 꽤 그럴듯하다.

그런데 문제가 하나 있다.

인증서 자체는 누구나 만들 수 있다.

OpenSSL만 있어도 자체 서명 인증서를 하나 만드는 것은 어렵지 않다.

공격자가 자기 컴퓨터에서 인증서를 만들어놓고 이렇게 주장할 수도 있다는 뜻이다.

나는 google.com이다.
이게 내 공개키다.

따라서 브라우저 입장에서 중요한 것은

“인증서가 있느냐?”

가 아니다.

진짜 중요한 질문은 이것이다.

“누가 이 인증서에 서명했는가?”

CA가 등장한다

여기서 CA, 즉 Certificate Authority가 등장한다.

CA는 인증서를 발급하는 인증기관이다.

예를 들어 어떤 서버 운영자가 example.com의 인증서를 발급받으려고 한다고 해보자.

CA는 먼저 신청자가 실제로 해당 도메인을 제어하고 있는지 확인한다.

대표적으로 DNS에 특정 값을 넣게 하거나,

_acme-challenge.example.com

특정 HTTP 경로에 값을 올리게 하는 식이다.

도메인 제어권이 확인되면 CA는 인증서를 만들어 서명한다.

중요한 것은 바로 서명이다.

CA는 자신의 개인키(Private Key) 를 이용해 인증서에 전자서명을 남긴다.

그리고 브라우저는 CA의 공개키(Public Key) 를 이용해서 그 서명이 진짜인지 검증할 수 있다.

즉,

example.com 인증서
        ↓
Intermediate CA가 서명

이라는 관계가 만들어진다.

하지만 여기서 문제가 끝난 것은 아니다.

오히려 더 근본적인 문제가 생긴다.

그 CA는 왜 믿어야 하지?

CA가 “나 믿을 만한 CA야”라고 주장한다고 해서 믿을 수는 없지 않은가.

신뢰를 계속 따라 올라가 보자

실제 인증서는 보통 한 단계로 끝나지 않는다.

구조를 단순화하면 다음과 같다.

example.com
     │
     │ signed by
     ▼
Intermediate CA
     │
     │ signed by
     ▼
Root CA

example.com의 인증서는 Intermediate CA가 서명하고,

그 Intermediate CA의 인증서는 또 Root CA가 서명한다.

이것이 Certificate Chain, 인증서 체인이다.

브라우저는 서버 인증서 하나만 보는 것이 아니라 이 체인을 위로 올라가면서 검증한다.

example.com의 서명은 정상인가?
          ↓
Intermediate CA의 공개키로 검증

Intermediate CA의 서명은 정상인가?
          ↓
Root CA의 공개키로 검증

그리고 마지막 Root CA까지 도달한다.

그런데 여기서 정말 재미있는 문제가 하나 나온다.

잠깐, Root CA는 누가 인증해주지?

Certificate Chain을 계속 따라 올라가면 결국 Root CA가 나온다.

그렇다면 Root CA의 인증서는 누가 서명할까?

답은 조금 이상하다.

자기 자신이다.

Root CA 인증서는 일반적으로 Self-Signed Certificate, 즉 자체 서명 인증서다.

구조만 보면 이런 셈이다.

Root CA

발급자: Root CA
대상:   Root CA
서명자: Root CA

그러면 의문이 생긴다.

앞에서는 자체 서명 인증서를 믿을 수 없다고 했는데,

왜 Root CA의 자체 서명 인증서는 믿는 걸까?

여기서 HTTPS 신뢰 구조의 핵심이 나온다.

Root CA가 신뢰받는 이유는 자기 서명이 유효해서가 아니다.

운영체제나 브라우저가 미리 그 Root CA를 신뢰하기로 결정했기 때문이다.

Trust Store — 결국 신뢰는 어딘가에서 시작해야 한다

Windows, macOS, iOS, Android 그리고 브라우저에는 신뢰할 수 있는 Root CA 목록이 존재한다.

이를 Trust Store라고 부른다.

대략 이런 개념이다.

Trusted Root Certificates

- Root CA A
- Root CA B
- Root CA C
- Root CA D
...

여기에 들어 있는 인증서는 이미 신뢰할 수 있는 인증서로 취급한다.

그렇기 때문에 인증서 체인이

example.com
    ↓
Intermediate CA
    ↓
Root CA

까지 정상적으로 이어지고,

마지막 Root CA가 Trust Store에 존재한다면 브라우저는 이 체인을 신뢰할 수 있다.

결국 HTTPS의 신뢰는 수학적인 증명만으로 완성되는 구조가 아니다.

맨 마지막에는 반드시

“이 Root는 우리가 신뢰한다.”

라는 정책적인 결정이 하나 존재한다.

이 지점을 Trust Anchor, 신뢰 기준점이라고 한다.

생각해보면 당연하다.

신뢰를 계속 다른 사람에게 증명하라고 요구한다면 끝이 없다.

A를 누가 보증하지?
→ B

B는 누가 보증하지?
→ C

C는?
→ D

언젠가는

여기부터는 그냥 신뢰한다.

라는 지점이 필요하다.

HTTPS에서는 그 역할을 Root CA가 맡고 있다.

그런데 서버는 Root 인증서까지 보내지 않는다

여기까지 알고 나면 서버가 이런 인증서를 전부 보내줄 것 같지만 실제로는 그렇지 않다.

일반적으로 서버가 보내는 것은

Leaf Certificate
Intermediate Certificate
Intermediate Certificate
...

정도다.

Root 인증서는 보통 보내지 않는다.

처음에는 이상하게 느껴질 수 있다.

하지만 생각해보면 Root 인증서를 서버가 보내주는 것은 신뢰 측면에서 아무 의미가 없다.

공격자도 똑같이 Root 인증서를 보낼 수 있기 때문이다.

브라우저가 중요한 것은

서버가 어떤 Root 인증서를 보냈느냐

가 아니라,

이 체인의 마지막 인증서가
내 Trust Store에 있는 Root와 연결되느냐

이다.

즉 Root는 서버가 알려주는 것이 아니라 클라이언트가 이미 가지고 있어야 한다.

브라우저는 단순히 서명만 보는 것도 아니다

Certificate Chain이 정상이라고 해서 바로 연결이 허용되는 것도 아니다.

브라우저는 꽤 많은 것을 확인한다.

가장 대표적인 것이 도메인 이름이다.

https://example.com에 접속했다면 인증서에는 example.com에 대한 권한이 있어야 한다.

과거에는 인증서의 Common Name(CN)을 많이 사용했지만 현재는 주로 Subject Alternative Name(SAN) 을 사용한다.

예를 들면,

Subject Alternative Name

DNS: example.com
DNS: www.example.com

같은 식이다.

따라서 공격자가 정상 CA에서

attacker.com

인증서를 발급받았다고 하더라도 그 인증서를 example.com 접속에 사용할 수는 없다.

서명은 정상이어도 이름이 다르기 때문이다.

유효기간도 확인한다

인증서에는 사용할 수 있는 기간도 지정되어 있다.

Not Before
Not After

브라우저는 현재 시간이 이 범위 안에 있는지 확인한다.

만약 만료됐다면

NET::ERR_CERT_DATE_INVALID

같은 인증서 오류가 발생할 수 있다.

이 때문에 HTTPS 인증서를 사용하는 서버에서는 인증서 자동 갱신이 꽤 중요하다.

Let's Encrypt 같은 CA와 ACME를 사용하는 서버에서 자동 갱신을 설정하는 이유도 이것이다.

Intermediate CA는 왜 굳이 존재할까?

여기까지 보면 한 가지 의문이 생긴다.

그냥 Root CA가 example.com 인증서를 직접 발급하면 더 간단하지 않을까?

가능은 하지만 실제 PKI 구조에서는 거의 그렇게 하지 않는다.

이유는 Root CA의 개인키가 너무 중요하기 때문이다.

Root CA 개인키가 유출되었다고 생각해보자.

공격자는 그 키를 이용해

google.com
apple.com
github.com
example.com

같은 사이트의 가짜 인증서를 만들어 서명할 수도 있다.

그리고 해당 Root를 신뢰하는 시스템에서는 심각한 문제가 발생한다.

그래서 Root CA의 개인키는 일반 서버의 키처럼 운영하지 않는다.

보통 매우 강한 물리적·운영적 보안 아래 보관하고, 실제 인증서 발급 작업은 Intermediate CA에게 맡긴다.

Root CA
   │
   ├── Intermediate CA A
   │       ├── example.com
   │       └── foo.com
   │
   └── Intermediate CA B
           ├── bar.com
           └── baz.com

이렇게 하면 Intermediate CA에 문제가 생겨도 Root 자체를 폐기하는 대신 해당 Intermediate만 차단할 수 있다.

즉 Intermediate CA는 단순히 계층을 복잡하게 만드는 존재가 아니다.

Root Key를 실제 인터넷 환경으로부터 최대한 격리시키기 위한 보안 장치이기도 하다.

여기까지는 인증서 이야기다. 그런데 TLS는 그다음부터 더 재미있다

많은 HTTPS 설명에서 다음과 같은 이야기를 본 적이 있을 것이다.

서버가 공개키를 보내고
브라우저가 그 공개키로 암호화해서
대칭키를 서버에게 전달한다.

RSA 기반의 과거 TLS를 단순화하면 비슷한 설명이 가능했다.

하지만 TLS 1.3에서는 이렇게 이해하면 정확하지 않다.

현대 TLS에서 인증서의 공개키는 주로

“이 서버가 정말 인증서에 적힌 개인키를 가지고 있는가?”

를 증명하는 데 사용된다.

실제 세션 키는 보통 (EC)DHE 계열의 키 교환을 통해 만들어진다.

이 차이가 꽤 중요하다.

TLS 1.3 Handshake를 실제 흐름으로 따라가 보자

브라우저가

https://example.com

에 접속한다고 해보자.

TLS 1.3 기준으로 흐름을 많이 단순화하면 다음과 같다.

Browser                              Server

ClientHello ------------------------>

                      <-------------- ServerHello

                      <-------------- EncryptedExtensions
                      <-------------- Certificate
                      <-------------- CertificateVerify
                      <-------------- Finished

Finished -------------------------->

=========== encrypted HTTP ===========

각 단계에는 꽤 중요한 의미가 있다.

ClientHello

브라우저가 처음 서버에게 보내는 메시지다.

여기에는 예를 들어 이런 정보들이 포함될 수 있다.

supported_versions
cipher_suites
key_share
server_name
ALPN

쉽게 풀면,

“나는 TLS 1.3을 지원하고, 이런 암호 방식들을 사용할 수 있고, 키 교환을 위해 이 값을 준비했어.”

라고 서버에게 알려주는 것이다.

server_name에는 어떤 호스트에 접속하려는지 알려주는 SNI 정보가 사용될 수 있고,

ALPN을 통해서는

h2
http/1.1

같이 TLS 위에서 어떤 프로토콜을 사용할지도 협상한다.

ServerHello

서버는 브라우저가 보낸 옵션 중 사용할 TLS 설정을 선택한다.

그리고 자신의 key share를 전달한다.

브라우저와 서버는 서로의 값을 이용해 같은 shared secret을 계산할 수 있다.

여기서 재미있는 점이 있다.

실제 세션 암호화 키를 서버가 네트워크로 그대로 보내는 것이 아니다.

각자 가지고 있는 비밀값과 교환된 공개값을 이용해 서로 동일한 비밀값을 계산한다.

네트워크를 보고 있는 공격자는 공개된 값은 볼 수 있어도 필요한 개인 값을 모르기 때문에 동일한 비밀값을 계산할 수 없다.

이 shared secret을 기반으로 여러 TLS traffic key가 만들어진다.

그럼 인증서는 어디서 사용될까?

이후 서버는 자신의 인증서 체인을 보낸다.

Certificate

브라우저는 앞에서 설명했던 검증을 시작한다.

도메인이 맞는가?

기간이 유효한가?

서명이 올바른가?

Intermediate가 올바른 CA인가?

신뢰하는 Root까지 연결되는가?

하지만 이것만으로는 아직 한 가지가 부족하다.

공격자가 실제 서버의 인증서 파일만 복사해온 것일 수도 있다.

인증서는 공개 정보이기 때문에 누구나 가져갈 수 있다.

그래서 TLS에는 CertificateVerify가 있다.

CertificateVerify — “인증서만 가진 게 아니라 개인키도 가지고 있다”

서버는 Handshake 과정의 데이터에 자신의 개인키로 서명한 값을 보낸다.

브라우저는 인증서에 들어 있는 서버의 공개키를 이용해서 그 서명을 검증한다.

성공한다면 브라우저는 중요한 사실 하나를 알게 된다.

이 서버는 인증서 파일만 가지고 있는 것이 아니라 그 인증서에 대응되는 실제 개인키도 가지고 있다.

이것이 서버 인증에서 매우 중요한 부분이다.

즉 인증서 자체가 신원을 증명하는 것이 아니라,

신뢰 가능한 CA의 서명

+

도메인 이름 일치

+

서버가 해당 개인키를 실제로 가지고 있다는 증명

이 합쳐져야 한다.

결국 데이터는 무엇으로 암호화될까?

Handshake가 끝나면 브라우저와 서버는 서로 공유하는 대칭키를 갖게 된다.

그리고 실제 HTTP 데이터는 이 대칭키를 기반으로 암호화된다.

GET / HTTP/1.1
Host: example.com

같은 내용이 인터넷에 그대로 흘러가는 것이 아니다.

실제 네트워크에서는 TLS가 암호화한 데이터 형태로 전송된다.

대칭키 암호화를 사용하는 이유는 간단하다.

빠르기 때문이다.

공개키 암호 방식은 매우 유용하지만 대량의 데이터를 계속 암호화하기에는 비용이 크다.

그래서 TLS는 역할을 나눈다.

인증
→ 인증서 + 공개키 암호 기술

키 합의
→ (EC)DHE

실제 데이터 전송
→ 대칭키 암호화

이 구조를 알고 나면

“HTTPS는 공개키로 웹페이지 전체를 암호화한다.”

라는 설명이 왜 부정확한지도 알 수 있다.

그렇다면 중간자 공격은 어떻게 막을까?

이제 공격자가 브라우저와 서버 사이에 들어왔다고 해보자.

Browser
   │
   ▼
Attacker
   │
   ▼
Server

공격자는 브라우저에게 가짜 인증서를 보낸다.

Subject: example.com
Public Key: 공격자의 공개키

하지만 문제가 생긴다.

이 인증서에는 신뢰 가능한 CA의 서명이 없다.

브라우저가 Chain을 따라가 보면

example.com
    ↓
????

신뢰할 수 있는 Root까지 연결되지 않는다.

그래서 인증서 검증이 실패한다.

공격자가 Self-Signed Certificate를 만들어도 마찬가지다.

example.com
Issuer: example.com

서명 자체는 기술적으로 유효할 수 있다.

하지만 브라우저의 Trust Store에 그 인증서가 없다.

즉,

암호학적으로 올바른 서명과 ‘신뢰할 수 있는 서명’은 다른 개념이다.

이 차이가 HTTPS 인증서 구조를 이해할 때 상당히 중요하다.

그런데 내 컴퓨터에 공격자의 Root 인증서를 설치하면?

여기서 한 단계 더 파고들면 꽤 흥미로운 사실이 나온다.

만약 어떤 프로그램이 시스템의 Trust Store에 새로운 Root CA를 설치했다고 해보자.

그러면 그 Root CA가 서명한 인증서는 브라우저 입장에서 신뢰 가능한 체인을 만들 수도 있다.

실제로 기업 네트워크의 HTTPS 검사 장비나 일부 보안 프로그램은 이와 비슷한 구조를 사용한다.

Browser
        ↓ HTTPS
Inspection Proxy
        ↓ HTTPS
Real Server

Proxy가 각각의 사이트용 인증서를 동적으로 발급하고,

컴퓨터에는 해당 Proxy의 Root CA가 미리 신뢰되도록 설치되어 있는 방식이다.

그래서 HTTPS 보안에서 Trust Store 관리 자체가 매우 중요하다.

누군가 신뢰할 Root를 추가할 수 있다면 HTTPS 신뢰 모델의 시작점을 바꿀 수 있기 때문이다.

인증서가 폐기됐는지는 어떻게 알까?

인증서가 아직 만료되지 않았더라도 문제가 생길 수 있다.

예를 들어 서버의 개인키가 유출됐다고 하자.

인증서의 유효기간이 아직 몇 달 남았다면 만료될 때까지 기다릴 수는 없다.

그래서 인증서를 중간에 Revocation, 즉 폐기할 수 있는 구조가 있다.

대표적으로

CRL
Certificate Revocation List

OCSP
Online Certificate Status Protocol

같은 방식이 존재한다.

또 서버가 CA에서 미리 OCSP 응답을 받아 TLS 연결 때 함께 보내주는 OCSP Stapling도 있다.

다만 실제 브라우저의 인증서 폐기 처리 방식은 생각보다 복잡하다.

네트워크 장애 때문에 OCSP 서버에 연결하지 못했다고 모든 HTTPS 사이트 접속을 막아버리면 웹 자체가 정상적으로 동작하지 않을 수도 있기 때문이다.

그래서 브라우저마다 폐기 정보를 다루는 방식에는 차이가 있다.

인증서 검증이라는 게 단순히

valid = true / false

한 번 확인하고 끝나는 과정은 아니라는 뜻이다.

그리고 현대 웹에서는 Certificate Transparency도 중요하다

CA가 존재한다고 해서 CA를 무조건 믿기만 하는 것도 위험하다.

만약 CA가 실수하거나 공격을 받아서

google.com

의 인증서를 엉뚱한 사람에게 발급하면 어떻게 될까?

인증서 Chain만 보면 정상일 수도 있다.

그래서 등장한 것 중 하나가 Certificate Transparency, CT다.

공개적으로 신뢰되는 인증서가 발급되면 해당 사실을 공개 로그에 기록해

“어떤 CA가 어떤 도메인의 인증서를 발급했는가”

를 감시할 수 있게 하는 구조다.

즉 현대 HTTPS 생태계는 단순히

CA가 서명함
→ 신뢰

정도로 끝나는 구조가 아니다.

CA 자체도 여러 정책과 감시 시스템 아래에 놓여 있다.

HTTPS 자물쇠가 의미하지 않는 것

여기까지 읽고 나면 하나 주의해야 할 것이 있다.

HTTPS 인증서가 유효하다고 해서

“이 사이트는 안전하고 착한 사이트다.”

라는 뜻은 아니다.

HTTPS가 보장하는 것은 훨씬 제한적이다.

대략 다음과 같다.

내가 접속하려던 도메인과 통신하고 있는가

통신 내용을 다른 사람이 쉽게 읽을 수 없는가

전송 중 데이터가 몰래 변조되지 않았는가

피싱 사이트도 자기 도메인에 정상 HTTPS 인증서를 발급받을 수 있다.

예를 들어

totally-not-a-bank.example

이라는 도메인의 소유자가 본인 도메인에 대해 정상 인증서를 발급받는 것은 이상한 일이 아니다.

따라서 HTTPS는

“이 사이트의 내용이 안전하다”

를 보증하는 기술이 아니라,

“현재 연결하고 있는 도메인과 암호학적으로 보호된 연결을 만들었다”

에 더 가깝다.

결국 브라우저는 무엇을 믿고 있는 걸까?

처음 질문으로 돌아가 보자.

브라우저는 처음 만난 HTTPS 서버를 어떻게 믿는가?

사실 브라우저가 그 서버를 갑자기 믿는 것은 아니다.

신뢰를 거꾸로 추적한다.

example.com
    │
    │ signed by
    ▼
Intermediate CA
    │
    │ signed by
    ▼
Root CA
    │
    ▼
Browser Trust Store

그리고 동시에 확인한다.

인증서 서명이 올바른가?

접속한 도메인과 인증서의 SAN이 일치하는가?

인증서가 아직 유효한가?

CA로 사용 가능한 인증서인가?

체인이 신뢰할 수 있는 Root까지 이어지는가?

서버가 인증서에 대응되는 개인키를 실제로 가지고 있는가?

이 모든 검증을 통과한 뒤에야 TLS 연결이 완성된다.

그리고 (EC)DHE를 통해 만들어진 비밀값으로부터 세션 키를 파생하고,

그 키를 이용해 실제 HTTP 데이터를 암호화한다.

직접 확인해보기

브라우저 화면만 보지 않고 실제 서버가 보내는 Certificate Chain을 보고 싶다면 OpenSSL로 확인할 수도 있다.

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts

출력에는 서버가 보내는 인증서와 Intermediate 인증서들을 확인할 수 있다.

인증서를 따로 저장했다면 다음처럼 내용을 살펴볼 수도 있다.

openssl x509 -in cert.pem -text -noout

그 안에서 찾아볼 만한 항목은 다음과 같다.

Issuer
Subject
Validity
Subject Public Key Info
X509v3 Subject Alternative Name
X509v3 Basic Constraints
Signature Algorithm

처음에는 인증서 파일 하나가 그냥 “HTTPS용 키 같은 것”으로 보이지만,

내용을 하나씩 읽어보면 사실은

도메인과 공개키, 발급자, 사용 목적, 유효기간, 전자서명이 묶여 있는 하나의 검증 가능한 문서

라는 것을 알 수 있다.

마치며

HTTPS를 처음 공부하면 보통 이렇게 외우게 된다.

HTTPS = HTTP + TLS

CA가 인증서를 발급한다.

Root CA를 브라우저가 신뢰한다.

공개키와 개인키로 암호화한다.

틀린 설명은 아니지만, 이 정도만 알고 있으면 몇 가지 중요한 질문에 답하기 어렵다.

Root 인증서는 누가 인증할까?

Self-Signed인데 왜 Root는 믿을까?

서버는 왜 Root 인증서를 보내지 않을까?

인증서 파일을 훔치면 서버인 척할 수 있을까?

TLS 1.3에서도 공개키로 세션 키를 암호화해서 보내는 걸까?

이 질문들을 하나씩 따라가다 보면 HTTPS의 핵심이 조금 다르게 보인다.

HTTPS의 신뢰는 인증서 한 장에서 만들어지는 것이 아니다.

Trust Store라는 신뢰의 출발점, CA가 만들어 놓은 Certificate Chain, 전자서명 검증, 서버의 Private Key 소유 증명, 그리고 TLS의 키 합의 과정이 전부 연결되어 만들어진다.

결국 브라우저가 믿는 것은

**“이 인증서가 있어 보인다”**가 아니라,

“이 서버가 주장하는 신원이 내가 이미 신뢰하는 기준점까지 암호학적으로 연결되고, 그 서버가 실제로 해당 개인키까지 보유하고 있다는 사실”

이다.

주소창에서 HTTPS 사이트 하나를 여는 데 몇백 밀리초도 걸리지 않지만,

그 짧은 순간 뒤에서는 생각보다 훨씬 많은 검증이 일어나고 있다.