공개키 기반 구조, PKI (Public Key Infrastructure) #2

 

공개키 기반 구조, PKI (Public Key Infrastructure) #1

이전 게시글과 이어집니다. 

 

인증기관(CA)에 대한 이야기를 하기 전에 ! 

해당 내용을 이해하려면 디지털 인증서인 X.509를 알아야 합니다. 
PKI 빙산의 일각 start... 

 

1. 디지털 인증서(X.509)?
X.509는 디지털 인증서의 표준 형식으로, 
공개키 기반 구조(PKI)에서 신원 검증을 위해 사용됩니다. 
인증서가 어떤 필드를 포함하고, 어떤 형식이어야 하는지를 정의합니다. 

인증서는 주로 .crt, .pem, .cer 확장자로 제공되며, 
.pem(Base64 인코딩) 또는 .der(바이너리) 형식이 있습니다. 
단, 사용 용도나 시스템 환경에 따라 확장자가 다릅니다. 
.pem, .crt, .cer 등은 실제로 PEM 또는 DER 형식의 인증서를 담고 있는 확장자 이름일 뿐입니다.

X.509 인증서
│
├── 인코딩 방식
│   ├── PEM (텍스트, Base64)
│   │   ├── .pem
│   │   ├── .crt
│   │   └── .cer
│   └── DER (바이너리)
│       ├── .der
│       └── .cer
│
└── 컨테이너 포맷 (개인 키 포함 가능)
    └── PKCS#12 (바이너리 + 비밀번호 보호)
        ├── .p12
        └── .pfx

인증서 사용 용도는 간단하게 표로 작성했습니다.
인증서 확장 필드 내 Key Usage 및 Extended Key Usage 로 명시됩니다.
필드 이야기는 하단에서 확인 가능합니다.

구분	설명	예시	주요 확장자
서버 인증(Server Auth)	클라이언트가 서버의 신원을 확인	HTTPS, 웹사이트	.crt, .pem, .cer
클라이언트 인증(Client Auth)	서버가 클라이언트를 인증	VPN, 기업 내부 인증	.p12, .pfx, .pem
코드 서명(Code Signing)	소프트웨어에 대한 무결성/신뢰 보장	EXE, 드라이버	.pfx, .pem, .cer
이메일 암호화(S/MIME)	이메일 암호화 및 서명	기업 이메일	.p12, .pem, .cer
문서 서명	전자 문서에 법적 효력 부여	PDF 전자서명 등	.p12, .pfx, .pem

 

2. PEM과 DER

1) PEM
Base64로 인코딩된 인증서에 헤더(BEGIN)와 푸터(END)가 포함된 텍스트 형식
텍스트 편집기로 열면 값을 확인할 수 있습니다.

 

2) DER
순수 바이너리 형식이며 ASN.1 인코딩을 사용합니다.
파일 내부는 OpenSSL이나 Windows 인증서 뷰어로 확인이 가능합니다.

 

구분	PEM	DER
형식	텍스트 (Base64 + 헤더/푸터)	이진 (Binary)
확장자	.pem, .crt, .cer, .key 등	.der, .cer
용도	사람이 직관적으로 파악 가능, 텍스트 기반 시스템	기계 간 통신, 리소스 제한 환경
호환성	OpenSSL, Apache, Nginx 등에서 일반적	일부 Java 시스템, Windows 등에서 사용

 

3. 디지털 인증서의 구조
테스트 인증서(.der)를 하나 발급 후 파일을 열면
어떠한 구조로 이루어진 것을 알 수 있습니다.
해당 구조는 X.509 표준에 따라 정의된 인증서의 형식입니다.

인증서 파일 내 자세히 탭에서 필드, 값을 확인 가능합니다.

.pem도 OpenSSL로 인증서 내부 구조 확인이 가능합니다.

인증서 주요 필드	설명
버전(Version)	인증서 버전 (보통 V3)
일련번호(Serial Number)	인증서 고유 식별 번호
서명 알고리즘 (Signature Algorithm)	CA가 인증서에 서명할 때 사용하는 알고리즘 (e.g. SHA256withRSA)
발급자(Issuer)	인증서를 발급한 CA의 식별 정보
유효기간(Validity)	인증서의 유효기간 (시작일 ~ 만료일)
주체(Subject)	인증서 소유자의 식별 정보 (도메인명, 조직 등)
공개키 (Subject Public Key Info)	공개키 및 알고리즘 정보 (RSA, ECDSA 등)
확장 필드(Extensions)	추가 정보 (SAN, 키 사용 용도, CRL 분배점 등)
디지털 서명(Signature)	CA가 위 모든 정보에 대해 서명한 디지털 서명값

 

사실 X.509를 설명할 때 기본 필드만 다루기에는 부족하고
확장 필드(Extensions)가 실제 용도, 보안 정책, 인증서의 기능을 결정짓는 핵심 요소입니다.
그래서 주요 확장 필드를 표로 정리해봤습니다.

구분	설명	예시
Key Usage	인증서로 가능한 암호학적 동작 정의	디지털 서명, 키 암호화 등
Extended Key Usage	인증서의 용도 세분화	TLS 서버, 클라이언트 인증, 코드 서명 등
Subject Alternative Name (SAN)	추가 도메인/IP/이메일 지정 HTTPS 환경 내 필수로 요구	www.example.com, api.example.com 등
Basic Constraints	인증서가 CA인지 여부, 체인 깊이 제한	CA:TRUE, pathlen:0
CRL Distribution Points	인증서 폐지 목록(CRL)의 위치	URL 또는 LDAP
Authority Key Identifier	상위 인증서의 키 ID 참조	체인 검증에 사용
Subject Key Identifier	이 인증서의 키 ID	체인 연결에 사용됨
Certificate Policies	인증서 발급 조건, 법적 정책 식별	보험, 신뢰 등급 등 명시

체인 연결은 CA를 다룬 이후 설명하겠습니다.

 

4. 디지털 인증서 발급 플로우

1. 키 쌍 생성
   - 사용자(서버 관리자 등)가 공개키 / 개인키 생성
   - 이 키는 암호화 및 서명 검증에 사용됨
       ↓
2. CSR 생성 (Certificate Signing Request)
   - 공개키 + 도메인/조직 정보 → CSR 파일 생성
   - CSR은 개인키로 서명됨 (무결성 보장)
       ↓
3. CSR 제출
   - CSR을 CA에 제출 (ACME 사용 시 자동 제출됨)
       ↓
4. CA의 신원 확인
   - 도메인 소유권 검증 (HTTP-01, DNS-01, 이메일 등)
   - OV/EV 인증서일 경우 조직 정보까지 검증
       ↓
5. 인증서 발급
   - CA가 CSR 내용을 검토하여 인증서를 생성
   - CA가 자신(또는 중간 CA)의 개인키로 서명함
       ↓
6. 인증서 전달
   - 발급된 인증서(PEM/CRT 등)를 사용자에게 전달
   - 웹서버/서비스에 설치 (Nginx, Apache 등)
       ↓
7. 인증서 사용
   - TLS 통신 등에서 클라이언트에게 인증서 제공
   - 브라우저는 CA 체인을 따라 인증서 신뢰 검증

사용자가 공개키 + Subject 정보 등을 담은 CSR을 CA에 제출하면
CA는 다음을 수행하고 X.509 인증서를 발급합니다.

1. CSR을 검증하고 유효한지 판단
2. 자체 정책에 따라 필요한 필드 자동 생성 (Serial Number, Validity 등)
3. Issuer, Signature 등 CA 고유 정보 설정
4. 전체 내용을 디지털 서명하여 최종 인증서 발급

인증기관(CA)은 X.509 인증서의 주요 필드를 생성하고 서명해주는 주체이며,
일부 필드는 클라이언트(CSR 요청자)가 제공하거나 CA가 정책에 따라 설정할 수 있습니다.

 

...

그럼 다음에는 진짜 CA에 대해 작성해보겠습니다.