웹 PKI의 변천: 인증서 생태계는 왜 바뀌었나

핵심: 인증서는 귀중품에서 소모품이 됐다

TLS의 원리(대칭키·공개키, 핸드셰이크, HSTS)는 HTTPS와 TLS에 있다. 이 노트는 그 위의 신뢰 체계, 즉 누가 인증서를 발급하고 브라우저가 무엇을 믿는지(웹 PKI)가 어떻게 바뀌었는지를 다룬다.

인터넷 곳곳에 남은 "CSR 만드는 법" 답변은 대부분 RSA 2048·SHA-1·장기 유효 기간을 전제로 해서 지금은 그대로 쓰면 안 된다. 직접 CSR을 만들 일 자체가 드물다. ACME 클라이언트나 호스팅이 키 생성부터 갱신까지 맡는다(HTTPS 전환).

옛 웹 PKI가 동작하던 방식

flowchart LR
    root["루트 CA<br/>(브라우저·OS의 루트 저장소에 내장)"] --> mid["중간 CA"] -->|"서명"| site["사이트 인증서"]

• CA는 매년 WebTrust 감사를 통과하면 루트 저장소에 남는다

• 규칙(Baseline Requirements)은 CA/브라우저 포럼에서 합의로 바꾼다

• 감사의 이해 상충: CA가 감사인을 직접 고르고 돈을 냈다. 1년에 한 번 감사만 통과하면 됐다.

• CA/브라우저 포럼(2005~): CA와 브라우저가 함께 최소 규칙(Baseline Requirements)을 정하는 자율 규제 기구다. 규칙을 바꾸려면 CA 쪽 표결도 통과해야 했으므로, 현상 유지로 이익을 보는 쪽이 사실상 거부권을 가졌다.

• 비싼 인증서: 검증 수준(DV·OV·EV)에 따라 값이 달랐고, 인증서 하나가 몇 년을 갔다. 개인키를 잃으면 돈을 내고 다시 사야 했다.

• "RSA"의 혼동: RSA는 키 교환(TLS 1.3에서 제거), 인증서 키(타원 곡선으로 대체 중), 서명 알고리즘(아직 사용)을 모두 가리켜서 맥락마다 뜻이 다르다. 어느 RSA를 말하는지 구분해야 한다.

무엇이 무너뜨렸나

전방 비밀성: 신원과 암호화를 분리한다

옛 RSA 키 교환에서는 클라이언트가 세션 비밀값을 서버 공개키로 암호화해 보냈다. 통신을 저장해 둔 사람이 나중에 서버 개인키를 얻으면 그 키로 만든 모든 과거 세션을 풀 수 있었다.

전방 비밀성(forward secrecy)은 두 일을 나눈다.

sequenceDiagram
    participant C as 클라이언트
    participant S as 서버
    Note over C: 비밀 a 생성
    C->>S: g^a 전송
    Note over S: 비밀 b 생성
    S->>C: g^b 전송
    Note over C,S: 양쪽 모두 g^ab를 계산<br/>(관찰자는 g^a, g^b만 보고 g^ab를 구할 수 없다: 이산 로그 문제)

공유 비밀은 어느 쪽도 전송하지 않는다. 개인키가 세션 키 계산에 쓰이지 않으므로 개인키가 유출돼도 과거 통신은 풀리지 않는다. 유출은 여전히 나쁘지만(위장 가능) 재앙은 아니게 됐고, 개인키를 자동화 도구로 옮기고 자주 바꾸는 것이 현실적인 선택이 됐다. TLS 1.3은 RSA 키 교환을 없애 전방 비밀성을 강제한다.

인증서 투명성(CT)

모든 공개 인증서는 발급 시 추가만 가능한 공개 로그에 기록되어야 하고, 브라우저는 로그 기록 증명(SCT)이 없는 인증서를 거부한다. 누구나 로그를 감시해 자기 도메인으로 발급된 인증서를 확인할 수 있다.

• 도메인 주인은 crt.sh 같은 CT 검색으로 모르는 발급을 찾는다. 감시 알림 서비스도 있다.
• 반대로 CT 로그는 공개 정보다. 인증서에 넣은 내부 서브도메인 이름이 모두 드러난다. 숨겨야 할 호스트 이름은 공개 인증서에 넣지 않거나 와일드카드·사설 CA를 쓴다.

폐기는 지금도 잘 안 된다

OCSP는 CA/브라우저 포럼 규칙에서 선택 사항이 됐고, Let's Encrypt는 2025년에 OCSP를 끝내고 CRL만 제공한다. 폐기를 믿을 수 없으니 인증서 수명 자체를 짧게 해서 폐기가 필요 없게 만드는 방향으로 간다. 폐기된 인증서를 브라우저가 막는지는 revoked.badssl.com으로 확인할 수 있다.

ACME와 Let's Encrypt

Let's Encrypt는 ISRG(비영리)가 운영하는 무료 CA이고, ACME(RFC 8555)는 그 발급 절차를 표준화한 프로토콜이다. 처음부터 무료, 짧은 수명, 사람 없는 자동화를 목표로 했다.

sequenceDiagram
    participant A as ACME 클라이언트
    participant CA as CA
    A->>CA: 주문(example.com)
    CA->>A: 챌린지: 도메인을 통제함을 증명하라
    Note over A: HTTP-01: http://example.com/.well-known/acme-challenge/#lt;토큰#gt; 에 파일을 둔다<br/>DNS-01: _acme-challenge.example.com TXT 레코드를 둔다 (와일드카드는 이것만)<br/>TLS-ALPN-01: 443 포트의 TLS 핸드셰이크로 증명한다
    A->>CA: CSR 제출
    CA->>A: 인증서 발급 (몇 초)

• CA들은 "기업은 자동화를 감당할 수 없다"고 반대했지만, Let's Encrypt는 지금 웹에서 가장 많은 인증서를 발급하는 CA다. ACME는 거의 모든 CA·호스팅·로드 밸런서가 지원하는 표준이 됐다.
• ARI(ACME Renewal Information, RFC 9773)로 CA가 클라이언트에게 갱신할 때를 알려 준다. 대량 폐기 사고가 나면 CA가 갱신을 앞당기도록 신호를 보낼 수 있다.
• Let's Encrypt는 6일짜리 단기 인증서도 발급하고, 기본 수명도 단계적으로 줄인다.

규칙을 정하는 힘이 브라우저로 옮겨 갔다

브라우저·OS는 각자의 루트 프로그램으로 어떤 CA를 넣을지 정한다. 포럼 표결이 막히면 루트 프로그램 규칙을 바꾸는 것으로 결과를 강제할 수 있고, CA가 반대하면 포럼 대신 브라우저마다 따로 감사를 받아야 한다. 이 압력으로 SC-081 같은 단축안이 통과됐다. 포럼은 남아 있지만 결정의 무게는 브라우저 쪽에 있다.

짧은 수명이 운영에 주는 일

수동 갱신은 1년에 한 번이면 달력 알림으로 버텼다. 47일이면 인증서 하나에 1년에 8번 이상이고, 인증서가 수십 장이면 수백 번이 된다. 수동 갱신으로는 감당할 수 없다.

갱신 자동화만으로는 부족하다. 장애는 대개 배포에서 난다. 새 인증서를 모든 서버·장치에 맞는 형식으로 넣고 서비스를 다시 읽게 하는 일이다.

스크립트로 시작한 자동화는 보통 이렇게 자란다.

이런 스크립트는 결국 인증서 수명 주기 관리(CLM: certificate lifecycle management)의 절반을 엉성하게 다시 만든 것이 된다. 인증서가 많다면 처음부터 이 기능을 갖춘 도구나 플랫폼을 쓴다.

가장 쉬운 길은 이 일을 플랫폼에 넘기는 것이다. Vercel·Netlify·Cloudflare 같은 호스팅, 클라우드 로드 밸런서, Caddy·Traefik 같은 서버는 발급·갱신·배포를 스스로 한다.

다음 전환: 양자 내성 암호

충분히 큰 양자 컴퓨터는 (EC)DHE 키 교환을 깰 수 있다. 그래서 지금 저장한 트래픽을 나중에 푸는 "지금 저장, 나중에 해독"(harvest now, decrypt later) 위협이 다시 생긴다.

• 키 교환은 이미 전환 중이다. X25519MLKEM768(기존 X25519 + ML-KEM 하이브리드)을 주요 브라우저와 CDN이 기본으로 협상한다(HTTPS와 TLS).
• 인증서 서명(ML-DSA 등 양자 내성 서명)은 서명과 인증서가 훨씬 커지는 문제 때문에 웹 PKI에 아직 들어오지 않았다. 바뀌면 다시 모든 인증서를 새로 발급해야 한다.
• 발급·배포가 자동화돼 있으면 이 전환은 설정 변경으로 끝나고, 수동이라면 또 한 번 긴 비상 작업이 된다. 짧은 수명이 강제하는 자동화가 암호 민첩성(crypto agility)의 기반이다.

정리

• 웹 PKI는 CA 침해, 대량 감청, 해시 충돌, Heartbleed, 폐기 실패를 겪으며 "CA를 믿고 감사로 확인한다"에서 "모든 발급을 공개 기록하고, 짧게 쓰고, 자동으로 바꾼다"로 바뀌었다.
• 전방 비밀성이 개인키를 귀중품에서 소모품으로 바꿨다. TLS 1.3이 이를 강제한다.
• CT 로그는 잘못된 발급을 드러내는 장치다. 대신 인증서에 넣은 호스트 이름은 모두 공개된다.
• 폐기는 지금도 믿을 수 없다. 그래서 수명을 줄인다: 2029년 3월부터 최대 47일.
• 갱신 자동화로 끝나지 않는다. 탐색·배포·감시·소유까지 수명 주기 전체를 자동화하거나 플랫폼에 맡긴다.
• 양자 내성 암호 전환이 다음 차례다. 자동화된 곳만 쉽게 넘어간다.

관련 노트: HTTPS와 TLS, HTTPS 전환: 인증서 고르기부터 리다이렉트까지, 로컬 개발 환경에 HTTPS 적용하기, 정보 시스템 보안(공격 기법과 암호), 프라이버시를 위한 암호화