grep

Engineering

인증서 톺아보기 시리즈 1: 인증서란? 디지털 신뢰의 시작

NHN

2026년 3월 3일

원문에서 보기 ↗

NHN Cloud_meetup banner_certificate_900.png

들어가며

여러분은 '인증서'라고 하면 어떤 생각이 떠오르시나요? 아마 많은 분들이 '매년 갱신해야 하는 귀찮은 일'을 떠올리실 겁니다. 그런데 정작 인증서가 무엇인지, 왜 필요한지는 잘 모르는 경우가 많습니다. 오늘은 인증서의 기본 개념부터 도메인 인증서 관리 실무에서 알아두면 좋은 내용까지 한번 살펴보겠습니다.

인증서(Certificate)란?

인증서는 디지털 신원 증명서입니다. 현실 세계의 신분증이 사람을 증명하듯, 디지털 세계에서는 이 인증서라는 전자 문서가 서버, 클라이언트, 또는 개인의 신원을 증명합니다.

가장 흔하게 접하는 것은 웹 서버 인증서(도메인 인증서 )입니다. 브라우저 주소창의 자물쇠 아이콘을 클릭해 보면 인증서를 확인할 수 있는데, 이는 "이 서버는 진짜 example.com이 맞습니다"라고 증명하는 역할을 합니다.

인증서의 핵심 구성 요소

certificate_1_900.png

TLS/HTTPS 통신 과정

인증서의 구조를 살펴봤으니, 이제 이 인증서가 실제 HTTPS 통신에서 어떻게 사용되는지 알아보겠습니다.

1. TLS Handshake

브라우저가 https://nhncloud.com에 접속할 때 다음과 같은 프로세스를 거칩니다.

1. Client Hello
   클라이언트 → 서버
   "안녕하세요! 저는 이런 암호화 방식들을 지원합니다."

2. Server Hello + Certificate
   서버 → 클라이언트
   "저는 이 인증서로 신원을 증명합니다."
   (인증서 전송)

3. Certificate Verification
   클라이언트
   ✓ 신뢰할 수 있는 CA가 발급한 인증서인가?
   ✓ 유효 기간이 지나지 않았나?
   ✓ 도메인 이름이 일치하는가?
   ✓ 인증서가 폐기되지 않았나?(CRL/OCSP)

4. Key Exchange
   클라이언트 ↔ 서버
   Diffie-Hellman 알고리즘으로 세션 키를 안전하게 생성

5. Secure Communication
   생성한 세션 키를 이용한 대칭 키 암호화 기반 양방향 보안 통신 시작

2. 비대칭 키 암호화(공개 키 암호화)

위의 TLS Handshake 과정에서 인증서는 공개 키 암호화 방식을 사용합니다.

certificate_2_900.png

서명 생성 과정

  1. TBS(To-Be-Signed): Subject, Public Key, 유효 기간 등 인증서 정보
     ↓
  2. 해시 함수 적용(SHA-256 등)
     → 고정 길이 해시값 생성
     ↓
  3. CA의 개인 키로 해시값 암호화
     → 디지털 서명 완성

위변조 방지 원리: 인증서 내용이 조금이라도 변경되면 해시값이 완전히 달라지므로, CA의 공개 키로 검증 시 즉시 탐지됩니다. CA의 개인 키 없이는 유효한 서명을 만들 수 없기 때문에 위조가 불가능합니다.

핵심 원리

certificate_3_900.png

인증 기관(CA)과 신뢰 체인

CA(Certificate Authority)의 역할

CA는 인증서를 발급하고 그 진위를 보증하는 디지털 공증인입니다.

certificate_4_900.png

신뢰 체인(Chain of Trust) 검증

  1. 브라우저가 서버 인증서 수신 CN: *.nhncloud.com Issuer: Sectigo RSA Organization Validation Secure Server CA

certificate_5.png

  1. Intermediate CA 인증서 확인 Issuer: USERTrust RSA Certification Authority

certificate_6.png

  1. Root CA 확인 → 브라우저/OS에 사전 설치된 신뢰할 수 있는 Root CA 목록에 있는가? ✓ 있으면 신뢰 ✗ 없으면 경고("연결이 비공개로 설정되어 있지 않습니다")

certificate_7.png

주요 CA 업체들

인증서 파일 형식

실무에서 다양한 확장자의 인증서 파일을 마주치게 되는데, 처음에는 매우 헷갈립니다. 인코딩 형식 (데이터 표현 방법)과 파일 확장자(파일명)는 다른 개념이지만 혼용되어 사용되므로 주의가 필요합니다.

인코딩 형식(데이터 표현 방법)

인증서 데이터를 저장하는 방식은 크게 2가지입니다.

주요 파일 확장자와 용도

확장자주로 사용하는 인코딩내용주요 용도
.pemPEM인증서, 개인 키, 체인Linux/Unix, Nginx, Apache
.crtPEM(또는 DER)인증서만인증서 배포(Linux/Unix)
.cerDER(또는 PEM)인증서만인증서 배포(Windows)
.keyPEM(또는 DER)개인 키만서버 개인 키 보관
.derDER인증서 또는 개인 키DER 인코딩임을 명시
.pfx, .p12바이너리(PKCS#12)인증서+개인 키+체인Windows, IIS, Java(Java 9+부터 기본)
.jks바이너리(Java KeyStore)인증서+개인 키Java(레거시, Java 8 이하)

헷갈리기 쉬운 포인트

Q. .crt와 .cer의 차이는?

Q. .pem과 .crt의 차이는?

Q. .der 파일은?

특수 형식 상세 설명

PKCS#12(.pfx, .p12)

JKS(Java KeyStore) - 레거시

도메인 인증서의 종류

적용 범위에 따른 분류

1. Single Domain Certificate
   example.com만 보호

2. Wildcard Certificate
   *.example.com
   → sub1.example.com, sub2.example.com 모두 보호
   → example.com은 별도 추가 필요!

3. Multi-Domain(SAN) Certificate
   example.com
   example.org
   sub.example.net
   → 완전히 다른 도메인들도 하나의 인증서로 보호

검증 수준에 따른 분류

종류검증 수준발급 시간Policy OID용도
DV(Domain Validated)도메인 소유권만 확인수분~수시간2.23.140.1.2.1일반 웹사이트, 개발/테스트
OV(Organization Validated)도메인+조직 실재 확인1~3일2.23.140.1.2.2기업 웹사이트(NHN Cloud 도메인 인증서가 해당)
EV(Extended Validation)도메인+조직+법적 실재 확인1~2주2.23.140.1.1금융, 전자상거래(주소창에 회사명 표시)

인증서 타입 구분 방법

인증서 내부의 Certificate Policies 확장 필드에 포함된 OID(Object Identifier)를 통해 DV/OV/EV를 구분할 수 있습니다.

# 인증서의 Policy OID 확인
openssl x509 -in certificate.crt -noout -text | grep -A 5 "Certificate Policies"

# 출력 예시
# Certificate Policies:
#     Policy: 2.23.140.1.2.1  ← DV 인증서
#     Policy: 2.23.140.1.2.2  ← OV 인증서
#     Policy: 2.23.140.1.1    ← EV 인증서

CA/Browser Forum 표준 Policy OID

실무에서 자주 마주치는 이슈들

지금까지 인증서의 기본 개념과 파일 형식, 도메인 인증서의 종류를 살펴봤습니다. 이제 실제 도메인 인증서를 관리하면서 마주칠 수 있는 대표적인 문제들과 해결 방법을 알아보겠습니다.

1. 인증서 체인 불완전(Incomplete Chain)

❌ 잘못된 구성
서버: End-Entity Certificate만 제공

✅ 올바른 구성
서버: End-Entity + Intermediate CA 모두 제공

증상: 일부 구형 브라우저/디바이스에서만 인증서 오류

해결: 제공 받은 인증서 번들 파일 모두 사용

2. CN vs SAN

지금까지의 내용에는 편의를 위해 Common Name(CN)에 도메인을 명시했지만, 현재는 SAN(Subject Alternative Name)이 표준입니다.

현대적인 인증서:
 CN: example.com
SAN:
  - DNS:example.com
  - DNS:www.example.com

💡중요: Chrome 58+ 버전(2017년 출시)부터 CN을 무시하고 SAN만 확인합니다.

인증서 발급 시 SAN에 모든 도메인이 포함되어 있는지 확인해야 합니다.

# 인증서의 SAN 확인
openssl x509 -in certificate.crt -noout -text | grep -A 1 "Subject Alternative Name"

3. 실무에서 유용한 인증서 명령어

👉 OpenSSL 명령어 살펴보기

파일 인코딩 형식 확인

# 1. 파일을 텍스트로 열어보기
cat certificate.crt
# → -----BEGIN CERTIFICATE----- 가 보이면 PEM 인코딩
# → 깨진 문자가 보이면 DER 인코딩

# 2\. file 명령어로 확인
file certificate.crt
# → "PEM certificate" 또는 "Certificate, Version=3"(DER) 형태 표시

# 3\. 인증서 내용 상세 확인\(PEM/DER 자동 인식\)
openssl x509 -in certificate.crt -text -noout

# 4\. 인증서 만료일 확인
openssl x509 -in certificate.crt -noout -dates

인증서 형식 변환

# 인증서: PEM → DER
openssl x509 -in cert.pem -outform DER -out cert.der

# 인증서: DER → PEM
openssl x509 -in cert.der -inform DER -outform PEM -out cert.pem
# [-inform DER] 생략 가능

# 개인 키: PEM → DER
openssl rsa -in private.key -outform DER -out private.der

# 개인 키: DER → PEM
openssl rsa -in private.der -inform DER -out private.key
# [-inform DER] 생략 가능

# PEM → PFX(인증서+개인 키)
openssl pkcs12 -export \
	-out certificate.pfx \
	-inkey private.key \
	-in certificate.crt \
	-certfile ca-bundle.crt

# PFX → PEM(인증서와 개인 키 분리)
# 인증서 추출
openssl pkcs12 -in certificate.pfx -clcerts -nokeys -out certificate.pem
# 개인 키 추출
openssl pkcs12 -in certificate.pfx -nocerts -nodes -out private.key

👉 Java keytool 명령어 살펴보기

Keystore 생성 및 관리

# 1\. Keystore 내용 확인 및 인증서 만료일 확인
keytool -list -v -keystore keystore.p12 -storetype PKCS12
# [-storetype PKCS12] 생략 가능
# 만료일 영역을 찾아서 확인

# 2\. 특정 alias 인증서 상세 정보 확인
keytool -list -v -keystore keystore.p12 -alias myalias

# 3\. Keystore에 있는 모든 alias 목록 확인
keytool -list -keystore keystore.p12`

PEM/PFX → Keystore 변환

# 1\. PFX를 PKCS12 keystore로 변환\(사실상 같은 형식\)
# Java 9+에서는 그냥 사용 가능
keytool -list -keystore certificate.pfx -storetype PKCS12
# [-storetype PKCS12] 생략 가능

# 2\. PEM 인증서를 keystore로 import
# 먼저 PEM을 PFX로 변환
openssl pkcs12 -export \
    -in certificate.crt \
    -inkey private.key \
    -out keystore.p12 \
    -name myalias

# 3\. JKS keystore를 PKCS12로 변환\(권장\)
keytool -importkeystore \
    -srckeystore old-keystore.jks \
    -srcstoretype JKS \
    -destkeystore new-keystore.p12 \
    -deststoretype PKCS12

# 4\. PKCS12 keystore에서 인증서 export
keytool -exportcert \
    -keystore keystore.p12 \
    -alias myalias \
    -file exported-cert.crt`

인증서 추가/삭제

# 1\. 신뢰할 수 있는 CA 인증서 추가
keytool -import \
    -trustcacerts \
    -alias ca-cert \
    -file ca.crt \
    -keystore truststore.p12 \
    -storetype PKCS12

# 2\. Keystore에서 인증서 삭제
keytool -delete \
    -alias myalias \
    -keystore keystore.p12

# 3\. Alias 이름 변경
keytool -changealias \
    -keystore keystore.p12 \
    -alias oldname \
    -destalias newname`

주의 사항

마치며

인증서는 단순히 "자물쇠 아이콘"이 아닙니다. 현대 웹 보안의 기초이자, 사용자와 서비스 간의 신뢰를 구축하는 핵심 요소입니다.

핵심 요약

다음 편에서는 짧아지는 인증서 유효 기간과 이에 대한 해결책인 ACME 프로토콜에 대해 알아보겠습니다. 2029년 최대 47일까지 단축되는 유효 기간에 대응하는 자동화 전략과, Let's Encrypt의 무료 인증서 제공 원리를 다룹니다.

긴 글을 읽어 주셔서 감사합니다. 🙂

참고 자료

참고 문헌

NHN Cloud 인증서 관리 서비스 살펴보기

  • Certificate Manager: 인증서, 도메인 등 만료 기한이 있는 자산을 관리하고 만료일 알림을 제공하는 서비스
  • Private CA: 조직 내·외부에서 사용하는 사설 인증서를 발급부터 폐기까지 자동화 및 표준화하는 서비스

NHN Cloud_meetup banner_footer_blue_202412_900.png