인증서에 관하여

1. 인증서의 탄생배경

공개키 기반구조(PKI) 에서 제공되는 공개키가 정말 의도한 상대의 공개키인지 확인하기 위해 인증서가 만들어졌다.
인증서 안에는 공개키가 담겨져있고 인증기관(CA)이 어디인지(발급자 필드), 이 내용이 정말 그 CA가 승인한 것이고 중간에 변조되지 않았는지(발급자 서명), 주체가 누구인지, 용도(EKU)가 무엇인지 등이 담겨 있다.

신뢰 사슬은 루트CA -> 중간CA -> 내 인증서 순으로 서명이 이어지고, Windows 나 브라우저 등은 신뢰할 수 있는 루트 CA 목록을 미리 가지고 있다.
그래서 공인 인증서는 별도 설정 없이 신뢰되지만 사설 인증서는 상대 PC에 루트를 직접 설치해야 신뢰된다.

인증서의 용도(EKU) 는 이 인증서가 특정 용도로만 사용되도록 "제약" 을 둔다.
그리고 용도별로 누구를 어떤 방법으로 검증했는지에 대한 정보가 담겨 있다.

 

2. 인증서의 역사

1990년대: 넷스케이프가 SSL을 만들면서 웹 인증서가 등장.
2000년대: 소프트웨어 배포가 늘면서 코드서명과 Windows Authenticode가 정착됨.
2010년대: 부실 CA 사고(DigiNotar 등)가 잇따라 CA에 대한 규칙이 강화됨. 2015년에는 Let's Encrypt가 무료 자동 발급 시대를 열음.
2020년대: 브라우저 업체와 CA가 모인 CA/Browser Forum이 주도해 유효기간을 계속 줄이고 자동화를 요구하는 방향으로 가고 있음.

 

3. 용도(EKU)에 따른 구분

1) TLS/SSL 인증서 - 웹사이트,API 서버의 HTTPS 통신

2) 코드서명 인증서 - exe, msi, 드라이버가 누가 만들었고 변조되지 않았는지 증명

3) 클라이언트 인증서 - 사용자나 장비 인증 (mTLS, VPN, 사내망)

4) S/MIME 인증서 - 이메일 서명과 암호화

5) 문서서명 인증서 - PDF 등 문서 서명

 

4. 인증서가 사용되는 대표 사례

1) 웹/API의 HTTPS - 가장 큰 비중이며 대부분 자동 발급과 갱신으로 운영됨.

2) 소프트웨어 코드서명 - Windows 앱, 설치 프로그램, 드라이버 배포에 사용됨.

3) 사내 mTLS와 제로트러스트 - 서비스 간 통신(마이크로서비스), 장비 인증, VPN에서 사설 CA가 활발히 쓰임.

4) IoT, 장비 인증 - 장비마다 고유 인증서를 심어 신원을 증명함.

5) 이메일(S/MIME), 문서 서명 - 기업과 공공 영역에서 계속 쓰임.

 

5. 2026 최신 인증서 트렌드

1) TLS 인증서 수명 단축
최대 유효기간이 2026년 3월 200일, 2027년 3월 100일, 2029년 3월 47일로 줄어듦.
수동 갱신이 어려워져서 자동화(ACME)가 필수임.

2) 초단기 인증서와 IP 인증서
Let's Encrypt가 약 6일짜리 단기 인증서와 IP 주소 인증서를 정식 제공하기 시작했음.
선택 사항이고, 기본 수명은 2027년 64일, 2028년 45일로 줄어들 예정임.

3) 코드서명 인증서 수명 단축
2026년 3월 1일부터 공인 코드서명 인증서는 최대 460일임.
타임스탬프를 적용하면 인증서가 만료돼도 기존 서명은 유지됨.

4) 클라우드 서명 서비스 확산
Microsoft Artifact Signing이 정식 출시됐고, 인증서 수명은 하루임.
개인키를 직접 관리하지 않고 CI/CD에서 서명하는 방식임.
한국 소재 회사가 이용할 수 있는지는 Microsoft 문서에서 확인이 필요함.

5) 용도 분리 강화
Let's Encrypt가 TLS 클라이언트 인증 EKU를 단계적으로 폐지하고 있음.
인증서 하나를 여러 용도로 쓰는 방식이 막히는 추세임.

6) 양자내성암호(PQC) 대비
양자컴퓨터에 대비해 RSA/ECC에서 새 알고리즘으로 전환하는 준비가 진행 중임.
아직 일반 제품에 바로 적용되는 단계는 아니고, 알고리즘 교체가 쉬운 구조가 중요해지고 있음.

 

"즉, 인증서는 더 짧게, 더 자동으로, 용도별로 분리하는 방향으로 가고 있다"

 

6. TLS/SSL 인증서와 클라이언트 인증서 비교

 

7. TLS 1.3 핸드셰이크 과정 (일반 TLS & mTLS 통합)

• 구분: ⚪ TLS 공통 (기본 과정) ｜ 🟧 mTLS 추가 (상호 인증 시 추가 과정)
• 방향: 🟦 Client ➔ Server ｜ 🟩 Server ➔ Client ｜ 🟪 Client ↔ Server (양방향)

단계	구분	방향	메시지 (명령어)	주요 역할 및 동작 내용
1	⚪ TLS 공통	🟦 C ➔ S	ClientHello	지원 암호 스위트, 서명 알고리즘 목록, 임시 공개키(key_share), 난수 전송
2	⚪ TLS 공통	🟩 S ➔ C	ServerHello	알고리즘과 임시 공개키 선택 (양측이 동일한 핸드셰이크 키를 계산하며, 이후 모든 메시지는 암호화됨)
3	⚪ TLS 공통	🟩 S ➔ C	EncryptedExtensions	부가 확장 정보(ALPN 등)를 암호화하여 전달
4	🟧 mTLS 추가	🟩 S ➔ C	CertificateRequest	[mTLS 시작] 클라이언트에게 인증서 제시 요구 (허용 서명 알고리즘, 신뢰하는 CA 목록 동봉 가능)
5	⚪ TLS 공통	🟩 S ➔ C	Certificate	서버 인증서 및 중간 CA 인증서 체인 전송
6	⚪ TLS 공통	🟩 S ➔ C	CertificateVerify	핸드셰이크 해시를 서버 개인키로 서명해 소유권 증명 (클라이언트는 서버 인증서 및 서명 검증)
7	⚪ TLS 공통	🟩 S ➔ C	Finished	서버 측 핸드셰이크 전체에 대한 MAC 값 전송 (클라이언트가 무결성 검증)
8	🟧 mTLS 추가	🟦 C ➔ S	Certificate	클라이언트 인증서 및 인증서 체인 전송
9	🟧 mTLS 추가	🟦 C ➔ S	CertificateVerify	핸드셰이크 해시를 클라이언트 개인키로 서명해 소유권 증명 (서버는 클라이언트 인증서 및 서명 검증)
10	⚪ TLS 공통	🟦 C ➔ S	Finished	클라이언트 측 핸드셰이크 MAC 값 전송 (서버가 검증하면 핸드셰이크 완료)
11	⚪ TLS 공통	🟪 C ↔ S	Application Data	암호화된 실제 데이터 통신 시작 (mTLS의 경우 양측 신원이 모두 검증된 상태)

 

8. Finished의 MAC이란?

Message Authentication Code(메시지 인증 코드) 임. 흔히 쓰는 MAC 주소(네트워크 장치 주소)가 아니고 이름만 같음.
메시지가 변조되지 않았고 같은 비밀 키를 가진 사람이 만들었음을 보증하는 짧은 검증값임.
TLS에서는 HMAC(해시 기반 MAC)을 씀.

(Finished 메시지의 계산 방식)

1. 지금까지 주고받은 핸드셰이크 메시지 전체의 해시(transcript hash)를 구함.
2. 핸드셰이크 중에 합의한 비밀에서 파생한 finished_key를 구함.
3. HMAC(finished_key, transcript hash) 값을 Finished로 보냄.
4. 상대도 같은 계산을 하고 값이 일치하는지 확인함.

TODO> 추가로 더 알아볼 것들.. 언젠가?

Q) 양자내성암호(PQC) 원리?
Q) 인증 자동화는 어케 함?
Q) Microsoft Artifact Signing 이 이전에 사용하던 WHQL 과 같은 건가?
Q) TLS 프로토콜 구조와 진행 방식?
Q) 전자서명된 프로그램의 PE파일 구조?