[Security] 디지털 인증서
개요
디지털 인증서는 공개키의 소유자를 보증하는 전자 문서다. 신뢰할 수 있는 제3자(CA, Certificate Authority)가 발급하며, 인터넷 통신의 보안을 담당한다. 이 글에서는 인증서의 필요성, 구조, 체인, 종류에 대해 알아본다.
인증서의 대표적인 표준 형식인 X.509에 대해서는 X.509 인증서를, PKI 전반에 대해서는 PKI를 참고하자.
인증서의 필요성
공개키 배포의 문제점
비대칭키 암호화에서 공개키를 안전하게 배포하는 것이 핵심 과제이다. 공개키가 정말 상대방의 것인지 확인할 수 없다면, 중간자 공격에 취약하다.
중간자 공격 시나리오
Normal Communication:
A ─────[A's Public Key]─────> B
(B receives A's public key)
Man-in-the-Middle Attack:
A ────[A's Public Key]───> Z ────[Z's Public Key]───> B
(Z intercepts) (Z sends own key
as A's key)
Result:
- B mistakenly thinks Z's key is A's key
- B encrypts with Z's key → Z can intercept all messages
A가 B에게 자신의 공개키를 전송할 때, 해커 Z가 A로 가장하여 Z의 공개키를 B에게 전달할 수 있다. B는 Z의 공개키로 암호화하고, Z가 모든 메시지를 탈취한다.
중간자 공격과 PKI의 해결책에 대한 자세한 내용은 PKI 글의 중간자 공격 예방을 참고하자.
인증서의 역할
신뢰할 수 있는 제3자(CA)가 공개키의 소유자를 보증하는 문서가 인증서다.
“CA인 제가 사용자의 신분을 보장하고, 동봉된 키는 사용자 A의 공개키가 확실함을 보장합니다.”라고 말하는 것과 같다.
인증서의 구성은 다음과 같다:
┌───────────────────────────────────────┐
인증서 (Certificate)
├───────────────────────────────────────┤
소유자: A
소유자의 공개키: [A의 공개키]
발급자: CA (신뢰할 수 있는 기관)
유효기간: 2024-01-01 ~ 2025-01-01
├───────────────────────────────────────┤
CA의 디지털 서명 (CA의 개인키로 서명)
└───────────────────────────────────────┘
인증서에 CA의 서명이 포함되어 있으므로, 수신자는 CA의 공개키로 서명을 검증하여 인증서가 위조되지 않았음을 확인할 수 있다.
루트 인증서
개념
CA의 서명을 검증하려면 CA의 공개키가 필요하다. 이 공개키는 루트 인증서에 담겨 있다.
루트 인증서는 CA가 스스로 발급하고 자신의 개인키로 서명한 특별한 인증서이다. 일반 인증서는 외부 CA에 서명을 요청하지만, 이처럼 자기 자신이 서명하는 것을 Self-Signed라고 한다.
┌───────────────────────────────────────┐
루트 인증서 (Self-signed)
├───────────────────────────────────────┤
발급자: CA
주체: CA (자기 자신)
주체 공개키: [CA의 서명용 공개키]
├───────────────────────────────────────┤
CA의 디지털 서명 (자기 서명)
└───────────────────────────────────────┘
특징은 다음과 같다:
- 발급자(Issuer)와 주체(Subject)가 동일함
- 자기 자신의 개인키로 서명 (Self-signed)
- CA의 공개키가 포함되어 있어, 다른 인증서의 서명 검증에 사용됨
루트 인증서의 신뢰
루트 인증서는 기술적으로 “누가 이걸 보증하는가?”에 대한 답이 없다. 신뢰 체인을 거슬러 올라가면 결국 이 지점에서 멈추고, “이건 그냥 믿기로 했다”가 된다. 그래서 Trust Anchor(신뢰의 닻)라고 부른다.
실제로 Self-Signed 인증서는 누구나 만들 수 있다. 하지만 OS나 브라우저의 Trust Store에 포함된 루트 인증서만 신뢰 체인의 시작점이 될 수 있다. Trust Store에 포함되려면 엄격한 감사와 보안 요구사항을 통과해야 하므로, 주요 CA들만 포함된다.
그렇다면 아무나 Trust Anchor가 될 수 있는가? 그렇지 않다. 브라우저와 OS에 루트 인증서를 포함시키려면 엄격한 검증을 통과해야 한다.
- Mozilla, Apple, Microsoft 등은 각각 Root CA Program을 운영
- WebTrust, ETSI 등의 감사 기준 충족 필요
- 보안 정책 준수, 투명성 요구사항 등 까다로운 조건
결국 루트 인증서를 신뢰하는 이유는:
- 기술적 검증: 없음 (Self-Signed이므로 상위 서명자가 없음)
- 제도적 검증: 있음 (감사, 정책, 프로그램 가입)
“이 조직들은 믿을 만하다”는 사회적 합의가 기술적 신뢰의 출발점이 된다.
현재 Windows, macOS, Linux, 브라우저 등에 약 50~100개의 Root CA 인증서가 사전 설치되어 있다. DigiCert, Let’s Encrypt, GlobalSign, Comodo, IdenTrust 등이 대표적이다.
인증서 발급 절차
CSR (Certificate Signing Request)
인증서를 발급받으려면 먼저 CSR을 생성해야 한다. CSR은 인증서 서명 요청으로, 발급 대상자의 정보와 공개키를 포함한다.
# OpenSSL을 사용한 CSR 생성
openssl req -new -newkey rsa:2048 -nodes -keyout private.key -out request.csr
CSR에는 아래와 같은 정보가 포함된다:
- Subject 정보 (조직명, 국가, 도메인 등)
- 공개키
- 서명 알고리즘
포함되는 정보에서 볼 수 있듯, CSR에는 공개키만 포함되며, 개인키는 포함되지 않는다. 개인키는 요청자가 안전하게 보관해야 한다.
인증서 활용 절차
인증서를 사용하여 A가 B에게 암호화된 메시지를 전송하는 과정:
┌─────────┐ ┌─────────┐ ┌─────────┐
│ CA │ │ B │ │ A │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
│ 1. Create Root │ │
│ Certificate │ │
│ │ │
│<───2. Submit CSR───│ │
│ │ │
│──3. Issue Cert────>│ │
│ │ │
│ │ 4. Store Cert │
│ │ │
│ │<───5. Request Cert─│
│ │ │
│ │───6. Send Cert────>│
│ │ │
│ │ 7. Verify │
│ │ │
│ │<──8. Encrypt/Send──│
│ │ │
- CA는 자신의 루트 인증서를 만들어 둠
- B는 (개인키, 공개키) 쌍 생성 후, CSR 생성하여 CA에 제출
- CA는 B의 신원을 확인한 후 인증서 발급 (CA 개인키로 서명)
- B는 발급받은 인증서 보관
- A가 B와 통신 시, B의 인증서 획득
- A는 CA의 루트 인증서로 서명 검증
- 검증 성공 → B의 공개키 신뢰
- B의 공개키로 암호화하여 메시지 전송
인증서 체인
계층 구조
실제로 Root CA가 직접 모든 인증서를 발급하지 않는다. 중간 CA(Intermediate CA)를 통해 발급한다.
Root CA (최상위)
↓ 서명
Intermediate CA (중간)
↓ 서명
End Entity (최종 - 예: google.com)
중간 CA의 필요성
- 보안: Root CA의 개인키는 매우 민감하므로, 오프라인 보관. HSM(Hardware Security Module)에 저장되며, 물리적으로 격리된 환경에서만 접근 가능하다.
- 유연성: 중간 CA를 통해 다양한 정책 적용 가능. 예를 들어 지역별, 용도별로 다른 중간 CA를 운영할 수 있다.
- 폐기 대응: 중간 CA가 침해되어도 해당 중간 CA만 폐기하고 Root CA는 안전하게 유지할 수 있다. Root CA의 폐기는 모든 하위 인증서의 무효화를 의미하므로 매우 치명적이다.
- 성능: Root CA 운영 부담 감소. 대량의 인증서 발급 작업을 중간 CA에 분산시킬 수 있다.
검증 과정
인증서 검증 과정은 아래와 같다:
1. 서버 인증서 수신
2. 발급자: Intermediate CA → Intermediate CA 인증서 확인
3. Intermediate CA 인증서의 발급자: Root CA → Root CA 인증서 확인
4. Root CA 인증서가 Trust Store에 내장되어 있음 → 신뢰!
5. 체인 전체 검증 성공 → 서버 인증서 신뢰
인증서 체인 검증 시 각 단계에서 다음을 확인한다:
- 서명이 유효한가?
- 인증서가 만료되지 않았는가?
- 인증서가 폐기되지 않았는가? (CRL 또는 OCSP 확인)
- 발급자가 해당 인증서를 발급할 권한이 있는가? (Basic Constraints 확인)
상호 인증 (Mutual Authentication)
일반적으로 서버만 인증서를 제시하지만, 양쪽 모두 인증서를 제시하여 서로를 검증하는 방식도 있다. 클라이언트도 자신의 신원을 증명해야 하는 환경에서 사용된다.
사용 사례:
- 쿠버네티스 컴포넌트 간 통신
- 금융 시스템
- VPN
- 마이크로서비스 간 통신
인증서의 종류
인증서는 용도에 따라 다양한 종류로 분류된다.
- SSL/TLS 인증서: HTTPS 웹 서버 인증에 사용되며, 검증 수준에 따라 DV, OV, EV로 구분
- 코드 서명 인증서: 소프트웨어 배포 시 개발자 신원을 증명하고 변조 여부 확인
- 이메일 인증서: S/MIME이나 PGP를 통한 이메일 암호화 및 서명
- 클라이언트 인증서: 사용자나 기기를 인증하며, 상호 인증 환경에서 주로 활용
- IPSec 인증서: VPN 터널 연결에서 상대방 인증
각 인증서 종류의 상세한 사용 사례와 예시는 PKI 실제 사용 사례를 참고하자.
인증서 관리
유효 기간과 갱신
인증서에는 유효 기간이 있으며, 만료 전에 갱신해야 한다. 과거에는 2~5년의 긴 유효 기간이 일반적이었으나, 최근에는 보안 강화를 위해 단축되는 추세이다. 현재 SSL/TLS 인증서는 최대 398일(약 13개월), Let’s Encrypt는 90일이 권장된다. 유효 기간이 짧으면 침해 시 피해 기간이 단축되고, 자동화가 촉진되며, 키 크기나 알고리즘 업데이트가 용이해진다. Let’s Encrypt는 ACME 프로토콜을 통해 인증서 발급과 갱신을 자동화하며, certbot 같은 도구로 자동 갱신할 수 있다.
폐기
개인키가 유출되거나 인증서 정보가 변경된 경우, 만료 전이라도 인증서를 폐기해야 한다. 폐기된 인증서는 CRL(Certificate Revocation List)이나 OCSP(Online Certificate Status Protocol)를 통해 확인할 수 있다.
인증서 폐기 메커니즘(CRL, OCSP, OCSP Stapling)에 대한 자세한 내용은 PKI의 인증서 폐기 관리를 참고하자.
정리
디지털 인증서는 공개키 암호화의 신뢰 문제를 해결하는 핵심 기술이다. CA가 공개키의 소유자를 보증하고, 인증서 체인을 통해 신뢰를 전파한다. 루트 인증서는 기술적 검증 없이 사회적 합의로 신뢰되며, 이것이 PKI 전체의 출발점이 된다.
인증서의 표준 형식에 대해서는 X.509 인증서를, PKI의 전체 구조와 운영에 대해서는 PKI를 참고하자.
댓글남기기