x.509 인증서와 PKI - 구조와 원리

2024년 12월 17일

dev-common

# x.509# PKI# 인증서# 보안# 암호화# SSL# TLS

개요

x.509는 공개키 인증서의 표준 포맷입니다. HTTPS 웹사이트에 접속할 때, API 서버 간 인증할 때, 코드 서명할 때 등 다양한 곳에서 사용됩니다.

이 글에서는 x.509 인증서의 구조와 PKI(Public Key Infrastructure) 원리를 이해합니다.


PKI (Public Key Infrastructure)

기본 개념

PKI는 공개키 암호화를 기반으로 한 신뢰 체계입니다.

문제: "이 공개키가 정말 google.com의 것인가?"
해결: 신뢰할 수 있는 제3자(CA)가 보증한다.

PKI 구성 요소

구성 요소 역할
CA (Certificate Authority) 인증서를 발급하고 서명하는 신뢰 기관
RA (Registration Authority) 인증서 발급 신청을 검증하는 기관
인증서 (Certificate) 공개키와 소유자 정보를 담은 디지털 문서
CRL (Certificate Revocation List) 폐기된 인증서 목록
OCSP (Online Certificate Status Protocol) 인증서 유효성을 실시간 확인하는 프로토콜

Certificate Chain (인증서 체인)

신뢰 체인의 구조

인증서는 계층적으로 서명됩니다:

Root CA (자체 서명)
  └─ Intermediate CA (Root CA가 서명)
      └─ End-entity Certificate (Intermediate CA가 서명)

왜 Intermediate CA를 사용할까?

Root CA의 비밀키는 극도로 민감합니다.
만약 Root CA가 직접 모든 인증서를 서명하면:
- Root CA의 비밀키를 자주 사용 → 노출 위험 증가
- Root CA가 손상되면 → 전체 신뢰 체계 붕괴

해결책:
- Root CA는 오프라인 보관 (HSM 등)
- Intermediate CA가 일상적인 서명 수행
- Intermediate CA가 손상되어도 Root CA는 안전
- Root CA로 새 Intermediate CA 발급 가능

실제 예시: google.com

1. Root CA: GlobalSign Root CA - R2
   - 자체 서명 (Self-Signed)
   - 브라우저/OS에 미리 설치됨

2. Intermediate CA: GTS CA 1C3
   - Root CA가 서명

3. End-entity: *.google.com
   - Intermediate CA가 서명
   - 실제 웹서버가 사용

브라우저는 다음을 검증합니다:

1. *.google.com 인증서가 GTS CA 1C3에 의해 서명되었는가?
2. GTS CA 1C3 인증서가 GlobalSign Root CA에 의해 서명되었는가?
3. GlobalSign Root CA가 신뢰할 수 있는 Root CA인가? (브라우저 저장소 확인)

x.509 인증서 구조

필드 구성

x.509 v3 인증서는 다음 정보를 포함합니다:

필드 설명 예시
Version 인증서 버전 v3 (0x2)
Serial Number 인증서 일련번호 (CA 내 고유) 0x1a2b3c4d
Signature Algorithm 서명 알고리즘 sha256WithRSAEncryption
Issuer 발급자 (CA) 정보 CN=Let’s Encrypt Authority X3, O=Let’s Encrypt
Validity 유효 기간 Not Before, Not After
Subject 인증서 소유자 정보 CN=example.com
Subject Public Key Info 공개키 정보 RSA 2048-bit, Exponent, Modulus
Extensions 확장 필드 (v3) SAN, Key Usage 등
Signature CA의 디지털 서명 RSA signature bytes

Subject와 Issuer

Distinguished Name (DN) 형식으로 표현됩니다:

C  = Country (KR)
ST = State/Province (Seoul)
L  = Locality (Gangnam)
O  = Organization (Example Corp)
OU = Organizational Unit (IT Department)
CN = Common Name (example.com)

예시:

Subject: C=KR, ST=Seoul, O=Example Corp, CN=example.com
Issuer:  C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3

Extensions (확장 필드)

v3부터 추가된 중요한 확장:

Subject Alternative Name (SAN)

하나의 인증서로 여러 도메인 지원:

Subject: CN=example.com
X509v3 Subject Alternative Name:
    DNS:example.com
    DNS:www.example.com
    DNS:api.example.com

Key Usage

공개키 사용 목적을 제한:

X509v3 Key Usage: critical
    Digital Signature, Key Encipherment
용도 설명
Digital Signature 디지털 서명
Key Encipherment 대칭키 암호화 (SSL/TLS)
Certificate Sign 인증서 서명 (CA만)
CRL Sign CRL 서명 (CA만)

Extended Key Usage

더 구체적인 용도:

X509v3 Extended Key Usage:
    TLS Web Server Authentication
    TLS Web Client Authentication

Basic Constraints

CA 인증서 여부 표시:

X509v3 Basic Constraints: critical
    CA:TRUE, pathlen:0
  • CA:TRUE: 이 인증서는 CA임
  • pathlen:0: 이 CA 아래 더 이상 하위 CA 불가 (End-entity만 발급 가능)

인증서 검증 과정

1. 형식 검증

- 인증서가 올바른 x.509 형식인가?
- 필수 필드가 모두 존재하는가?

2. 유효 기간 검증

현재 시간이 다음 범위 내에 있는가?

Not Before <= 현재 시간 <= Not After

3. 서명 검증

1. 인증서의 Issuer 확인
2. Issuer의 공개키로 Signature 복호화
3. 인증서 내용의 해시값과 비교
4. 일치하면 → 서명 유효 (위조되지 않음)

과정:

[인증서 본문] → SHA-256 → [해시 A]

[Signature] → Issuer 공개키로 복호화 → [해시 B]

해시 A == 해시 B → 서명 유효!

4. 신뢰 체인 검증

1. End-entity 인증서의 Issuer 찾기
2. Issuer 인증서의 서명 검증
3. Issuer가 Root CA에 도달할 때까지 반복
4. Root CA가 신뢰 저장소에 있는지 확인

5. 폐기 확인

- CRL 다운로드 → 인증서 일련번호 확인
- 또는 OCSP 쿼리 → 실시간 상태 확인

Self-Signed Certificate

자체 서명 인증서는 Issuer == Subject인 경우입니다.

Root CA는 Self-Signed

Subject: CN=GlobalSign Root CA - R2
Issuer:  CN=GlobalSign Root CA - R2  (자기 자신)

Root CA는 자신의 비밀키로 자신을 서명합니다.

개발/테스트용 Self-Signed

내부 테스트나 개발 환경에서 사용:

Subject: CN=localhost
Issuer:  CN=localhost  (자기 자신)

주의점:

- 브라우저에서 "신뢰할 수 없음" 경고
- 신뢰 체인이 없음
- 프로덕션 환경에서는 사용 금지

인증서 타입

검증 수준별

타입 검증 수준 용도
DV (Domain Validated) 도메인 소유권만 검증 일반 웹사이트, 무료 (Let’s Encrypt)
OV (Organization Validated) 조직 실체 검증 기업 웹사이트
EV (Extended Validation) 엄격한 조직 검증 금융, 정부 (브라우저 주소창 회사명 표시)

용도별

타입 용도 Extended Key Usage
SSL/TLS 인증서 웹서버 HTTPS TLS Web Server Authentication
클라이언트 인증서 사용자 인증 TLS Web Client Authentication
코드 서명 인증서 소프트웨어 서명 Code Signing
이메일 인증서 S/MIME Email Protection

실제 인증서 구조 예시

간단한 형태로 표현하면:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1234567890
        Signature Algorithm: sha256WithRSAEncryption

        Issuer: C=US, O=Let's Encrypt, CN=R3

        Validity
            Not Before: Jan  1 00:00:00 2024 GMT
            Not After : Apr  1 00:00:00 2024 GMT

        Subject: CN=example.com

        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus: 00:a1:b2:c3:...
                Exponent: 65537 (0x10001)

        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:example.com, DNS:www.example.com
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE

    Signature Algorithm: sha256WithRSAEncryption
         a1:b2:c3:d4:...

Root CA 저장소

운영체제 신뢰 저장소

OS 위치
Windows 인증서 관리자 (certmgr.msc)
macOS 키체인 접근 → 시스템 루트
Linux /etc/ssl/certs/, /etc/pki/tls/certs/

주요 Root CA 목록

  • DigiCert: 가장 많이 사용되는 상업용 CA
  • Let’s Encrypt (IdenTrust): 무료 DV 인증서
  • GlobalSign: 국제적으로 신뢰받는 CA
  • Sectigo (Comodo): 대중적인 상업용 CA

정리

x.509 인증서

  • 공개키 인증서의 표준 포맷
  • Subject, Issuer, Public Key, Signature 등 포함
  • v3부터 Extensions로 확장 가능 (SAN, Key Usage 등)

PKI 구조

  • CA가 인증서를 발급하고 서명
  • Root CA → Intermediate CA → End-entity 계층 구조
  • 신뢰 체인을 따라 검증

검증 과정

  1. 형식 검증
  2. 유효 기간 확인
  3. 서명 검증 (위조 방지)
  4. 신뢰 체인 확인 (Root CA까지)
  5. 폐기 여부 확인 (CRL/OCSP)

다음 글

x.509 인증서 실습 - OpenSSL 완벽 가이드에서 OpenSSL로 실제 인증서를 생성하고 검증하는 방법을 다룹니다.


참고 자료

© 2025, 미나리와 함께 만들었음