개요
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 X3Extensions (확장 필드)
v3부터 추가된 중요한 확장:
Subject Alternative Name (SAN)
하나의 인증서로 여러 도메인 지원:
Subject: CN=example.com
X509v3 Subject Alternative Name:
DNS:example.com
DNS:www.example.com
DNS:api.example.comKey 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 AuthenticationBasic Constraints
CA 인증서 여부 표시:
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0CA:TRUE: 이 인증서는 CA임pathlen:0: 이 CA 아래 더 이상 하위 CA 불가 (End-entity만 발급 가능)
인증서 검증 과정
1. 형식 검증
- 인증서가 올바른 x.509 형식인가?
- 필수 필드가 모두 존재하는가?2. 유효 기간 검증
현재 시간이 다음 범위 내에 있는가?
Not Before <= 현재 시간 <= Not After3. 서명 검증
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 계층 구조
- 신뢰 체인을 따라 검증
검증 과정
- 형식 검증
- 유효 기간 확인
- 서명 검증 (위조 방지)
- 신뢰 체인 확인 (Root CA까지)
- 폐기 여부 확인 (CRL/OCSP)
다음 글
x.509 인증서 실습 - OpenSSL 완벽 가이드에서 OpenSSL로 실제 인증서를 생성하고 검증하는 방법을 다룹니다.