요약
[](https://www.nhncloud.com/kr) ## 들어가며 여러분은 '인증서'라고 하면 어떤 생각이 떠오르시나요? 아마 많은 분들이 '**매년 갱신해야 하는 귀찮은 일**'을 떠올리실 겁니다. 그런데 정작 인증서가 무엇인지, 왜 필요한지는 잘 모르는 경우가 많습니다. 오늘은 인증서의 기본 개념부터 도메인 인증서 관리 실무에서 알아두면 좋은 내용까지 한번 살펴보겠습니다. ## 인증서(Certificate)란? 인증서는 **디지털 신원 증명서**입니다. 현실 세계의 신분증이 사람을 증명하듯, 디지털 세계에서는 이 인증서라는 전자 문서가 서버, 클라이언트, 또는 개인의 신원을 증명합니다. 가장 흔하게 접하는 것은 **웹 서버 인증서(도메인 인증서)**입니다. 브라우저 주소창의 자물쇠 아이콘을 클릭해 보면 인증서를 확인할 수 있는데, 이는 "**이 서버는 진짜 example.com이 맞습니다**"라고 증명하는 역할을 합니다. ### 인증서의 핵심 구성 요소  * **Subject(발급 대상)**: 이 인증서가 누구(어떤 도메인/조직)를 위한 것인지 명시 * **CN(Common Name)**: 보호할 도메인명(예: `example.com`, `*.example.com`) * **O(Organization)**: 조직/회사명(특정 유형의 인증서에서 필수) * 기타: OU(부서), L(도시), ST(주/도), C(국가 코드) * **Issuer(발급자)**: 이 인증서를 발급한 CA의 정보 * 신뢰 체인 검증 시 사용 * **Self-signed 인증서**: Subject=Issuer(자신이 자신을 서명) * 개발/테스트 환경에서 사용 * 브라우저가 신뢰하지 않아 경고 표시 * 공개 CA 발급 전 테스트용으로 유용 * Root CA도 자체 서명하므로 Subject=Issuer이지만, 브라우저/OS에 사전 설치되어 신뢰됨 * **Public Key(공개 키)**: 서버 신원 검증과 안전한 키 교환에 사용 * 서버의 디지털 서명 검증 * TLS Handshake 시 안전한 세션 키 협상 * 대응하는 개인 키(Private Key)는 서버만 보유 * **Validity Period(유효 기간)**: 인증서 사용 가능 기간 * **Not Before**: 유효 시작 일시 * **Not After**: 만료 일시 * 최근 CA/Browser Forum 규정: 최대 398일(약 13개월) * **2026년 3월 15일부터: 최대 200일** * **2027년 3월 15일부터: 최대 100일** * **2029년 3월 15일부터: 최대 47일** * 위와 같이 점차 유효 기간이 줄어들 예정 * **Digital Signature(디지털 서명)**: CA의 개인 키로 생성한 서명 * 인증서 내용의 무결성 보장 * CA의 공개 키로 검증 가능 * 위변조 방지의 핵심 메커니즘## TLS/HTTPS 통신 과정 인증서의 구조를 살펴봤으니, 이제 이 인증서가 실제 HTTPS 통신에서 어떻게 사용되는지 알아보겠습니다. ### 1\. TLS Handshake 브라우저가 [https://nhncloud.com](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 과정에서 인증서는 **공개 키 암호화** 방식을 사용합니다.  **서명 생성 과정** ``` 1. TBS(To-Be-Signed): Subject, Public Key, 유효 기간 등 인증서 정보 ↓ 2. 해시 함수 적용(SHA-256 등) → 고정 길이 해시값 생성 ↓ 3. CA의 개인 키로 해시값 암호화 → 디지털 서명 완성 ``` **위변조 방지 원리**: 인증서 내용이 조금이라도 변경되면 해시값이 완전히 달라지므로, CA의 공개 키로 검증 시 즉시 탐지됩니다. CA의 개인 키 없이는 유효한 서명을 만들 수 없기 때문에 위조가 불가능합니다. **핵심 원리** * 공개 키로 암호화한 데이터는 오직 개인 키로만 복호화 가능 * 개인 키로 만든 서명은 공개 키로 검증 가능  ## 인증 기관(CA)과 신뢰 체인 ### CA(Certificate Authority)의 역할 CA는 인증서를 발급하고 그 진위를 보증하는 **디지털 공증인**입니다.  ### 신뢰 체인(Chain of Trust) 검증 1) 브라우저가 서버 인증서 수신 CN: *.nhncloud.com Issuer: Sectigo RSA Organization Validation Secure Server CA  2) Intermediate CA 인증서 확인 Issuer: USERTrust RSA Certification Authority  3) Root CA 확인 → 브라우저/OS에 사전 설치된 신뢰할 수 있는 Root CA 목록에 있는가? ✓ 있으면 신뢰 ✗ 없으면 경고("연결이 비공개로 설정되어 있지 않습니다")  ### 주요 CA 업체들 * Let's Encrypt * DigiCert * GlobalSign * Sectigo(구 Comodo) ## 인증서 파일 형식 실무에서 다양한 확장자의 인증서 파일을 마주치게 되는데, 처음에는 매우 헷갈립니다. **인코딩 형식**(데이터 표현 방법)과 **파일 확장자**(파일명)는 다른 개념이지만 혼용되어 사용되므로 주의가 필요합니다. ### 인코딩 형식(데이터 표현 방법) 인증서 데이터를 저장하는 방식은 크게 2가지입니다. * **PEM(Privacy Enhanced Mail)**: Base64로 인코딩된 텍스트 형식 * `-----BEGIN CERTIFICATE-----`로 시작하는 형태 * 텍스트 편집기로 열어볼 수 있음 * **DER(Distinguished Encoding Rules)**: 바이너리 형식 * 텍스트 편집기로 열면 깨진 문자 표시 * PEM과 내용은 같지만 인코딩 방식만 다름 ### 주요 파일 확장자와 용도 | 확장자 | 주로 사용하는 인코딩 | 내용 | 주요 용도 | | --- | ----------- | --- | ----- | | **`.pem`** | PEM | 인증서, 개인 키, 체인 | Linux/Unix, Nginx, Apache | | **`.crt`** | PEM(또는 DER) | 인증서만 | 인증서 배포(Linux/Unix) | | **`.cer`** | DER(또는 PEM) | 인증서만 | 인증서 배포(Windows) | | **`.key`** | PEM(또는 DER) | 개인 키만 | 서버 개인 키 보관 | | **`.der`** | DER | 인증서 또는 개인 키 | DER 인코딩임을 명시 | | **`.pfx`, `.p12`** | 바이너리(PKCS#12) | 인증서+개인 키+체인 | Windows, IIS, Java(Java 9+부터 기본) | | **`.jks`** | 바이너리(Java KeyStore) | 인증서+개인 키 | Java(레거시, Java 8 이하) | ### 헷갈리기 쉬운 포인트 **Q. `.crt`와 `.cer`의 차이는?** * 확장자만 다르고 본질적으로 같은 인증서 파일 * `.crt`는 주로 Linux/Unix에서, `.cer`는 Windows에서 선호 * 두 가지 모두 PEM 또는 DER 인코딩을 사용할 수 있음 * **중요**: 확장자로는 인코딩 형식을 알 수 없음! **Q. `.pem`과 `.crt`의 차이는?** * `.pem`: 인증서, 개인 키, 체인 등 다양한 내용 포함 가능 * `.crt`: 일반적으로 인증서만 포함(개인 키 없음) * 두 가지 모두 대부분 PEM 인코딩 사용 **Q. `.der` 파일은?** * DER 인코딩을 사용한다는 것을 확장자로 명시 * 인증서 또는 개인 키 모두 가능(바이너리 형식) * 주로 Java, Windows 환경에서 사용 ### 특수 형식 상세 설명 **PKCS#12(.pfx, .p12)** * 인증서+개인 키+체인을 하나의 파일로 묶은 형식 * 비밀번호로 보호 가능 * Windows 환경과 **Java 9 이상에서 표준 형식** * `.pfx`는 Windows 관례, `.p12`는 범용 확장자 **JKS(Java KeyStore) - 레거시** * Java 전용 바이너리 형식 * Java 8 이하에서 기본 형식 * Java 9부터는 PKCS#12가 기본이므로, 신규 프로젝트는 `.p12` 사용 권장 ## 도메인 인증서의 종류 ### 적용 범위에 따른 분류 ``` 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** * `2.23.140.1.2.1`: Domain Validation * `2.23.140.1.2.2`: Organization Validation * `2.23.140.1.1`: Extended Validation ## 실무에서 자주 마주치는 이슈들 지금까지 인증서의 기본 개념과 파일 형식, 도메인 인증서의 종류를 살펴봤습니다. 이제 실제 도메인 인증서를 관리하면서 마주칠 수 있는 대표적인 문제들과 해결 방법을 알아보겠습니다. ### 1\. 인증서 체인 불완전\(Incomplete Chain\) ``` ❌ 잘못된 구성 서버: End-Entity Certificate만 제공 ✅ 올바른 구성 서버: End-Entity + Intermediate CA 모두 제공 ``` **증상:** 일부 구형 브라우저/디바이스에서만 인증서 오류 * 최신 브라우저는 AIA(Authority Information Access)를 통해 누락된 중간 인증서를 자동으로 가져오지만, 구형은 이를 지원하지 않음 * [SSL Labs](https://www.ssllabs.com/ssltest/)로 체인 구성 검증 가능 **해결:** 제공 받은 인증서 번들 파일 모두 사용 ### 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` ``` #### **주의 사항** * `.pem` 파일은 여러 인증서를 연결해서 하나의 파일로 만들 수 있음(체인 번들) * 개인 키(`.key`) 파일은 절대 외부에 노출되면 안 됨 * Windows 환경은 주로 `.pfx`, Linux 환경은 주로 `.pem` 사용 * Java 환경: Java 9+는 `.p12`(PKCS#12), 레거시(Java 8 이하)는 `.jks` * 확장자는 관례일 뿐, 실제 내용은 파일을 열어봐야 정확히 알 수 있음 * keytool 사용 시 비밀번호 입력이 필요하며, `-storepass` 옵션으로 지정 가능 ## 마치며 인증서는 **단순히 "자물쇠 아이콘"이 아닙니다.** 현대 웹 보안의 기초이자, 사용자와 서비스 간의 신뢰를 구축하는 핵심 요소입니다. **핵심 요약** * 인증서는 디지털 신원 증명서로 공개 키 암호화와 CA의 서명으로 신뢰성 보장 * TLS Handshake를 통한 안전한 통신 수립 * 신뢰 체인: End-Entity → Intermediate CA → Root CA * 파일 형식: `.pem`(텍스트), `.der`(바이너리), `.pfx`(인증서+키) * 실무 체크리스트: 체인 완전성, SAN 포함 여부 다음 편에서는 **짧아지는 인증서 유효 기간과 이에 대한 해결책인 ACME 프로토콜**에 대해 알아보겠습니다. 2029년 최대 47일까지 단축되는 유효 기간에 대응하는 자동화 전략과, Let's Encrypt의 무료 인증서 제공 원리를 다룹니다. 긴 글을 읽어 주셔서 감사합니다. ## 참고 자료 ### 참고 문헌 * Sharon Boeyen 외, RFC - [Proposed Standard](https://tools.ietf.org/html/rfc5280), 2008. 5. * Qualys SSL Labs, [SSL Server Test](https://www.ssllabs.com/ssltest/) * 한국전자인증, [[중요공지] SSL/TLS 인증서 유효기간 단축 확정](https://cert.crosscert.com/%EC%A4%91%EC%9A%94%EA%B3%B5%EC%A7%80-ssl-tls-%EC%9D%B8%EC%A6%9D%EC%84%9C-%EC%9C%A0%ED%9A%A8%EA%B8%B0%EA%B0%84-%EB%8B%A8%EC%B6%95-%ED%99%95%EC%A0%95/), 2025. 4. 18. ### NHN Cloud 인증서 관리 서비스 살펴보기 > * **[Certificate Manager](https://www.nhncloud.com/kr/service/management/certificate-manager)**: 인증서, 도메인 등 만료 기한이 있는 자산을 관리하고 만료일 알림을 제공하는 서비스 > * **[Private CA](https://www.nhncloud.com/kr/service/management/private-ca)**: 조직 내·외부에서 사용하는 사설 인증서를 발급부터 폐기까지 자동화 및 표준화하는 서비스 [](https://www.nhncloud.com/kr)