# 클라이언트 인증서 (Client Certificate)

## 1. 개요
클라이언트 인증서란 SSL/TLS 프로토콜 환경에서 서버가 클라이언트(사용자 또는 기기)의 신원을 확인하기 위해 요구하는 디지털 인증서이다. 

일반적인 웹 브라우징에서 사용하는 **서버 인증서(Server Certificate)**가 "접속한 사이트가 신뢰할 수 있는 곳인가"를 확인하는 용도라면, **클라이언트 인증서**는 "접속을 시도하는 사용자가 허가된 사용자인가"를 검증하는 용도로 사용된다. 이는 ID/비밀번호 기반의 인증 방식보다 보안성이 훨씬 높으며, 소유 기반 인증(Possession-based Authentication)의 대표적인 사례이다.

## 2. 동작 원리 및 인증 과정
클라이언트 인증서는 **상호 TLS(mTLS, Mutual TLS)** 메커니즘을 통해 작동한다. 일반적인 TLS 핸드셰이크에서는 서버만 인증서를 제시하지만, mTLS에서는 서버와 클라이언트 모두 자신의 인증서를 교환하여 상호 신원을 확인한다.

### mTLS 핸드셰이크 과정
1. **Client Hello**: 클라이언트가 서버에 연결을 요청한다.
2. **Server Hello & Certificate**: 서버가 자신의 인증서를 클라이언트에 전달한다.
3. **Certificate Request**: 서버가 클라이언트에게 인증서를 제시할 것을 요청한다.
4. **Client Certificate**: 클라이언트가 자신의 인증서를 서버에 전달한다.
5. **Client Key Exchange & Certificate Verify**: 클라이언트가 **이전 단계까지 주고받은 모든 핸드셰이크 메시지들의 해시값을 자신의 개인키로 서명**하여 전송한다. 서버는 클라이언트의 공개키로 이를 검증하여, 클라이언트가 해당 인증서의 정당한 소유자임을 증명한다.
6. **Finished**: 양측의 신원 확인이 완료되면 암호화된 세션을 생성한다.

### 일반 TLS vs mTLS 비교
| 구분 | 일반 TLS (One-way TLS) | 상호 TLS (mTLS) |
| :--- | :--- | :--- |
| **인증 주체** | 서버 → 클라이언트 (서버만 인증) | 서버 ↔ 클라이언트 (상호 인증) |
| **인증서 필요 대상** | 서버 | 서버 및 모든 클라이언트 |
| **주요 목적** | 데이터 암호화, 서버 신원 확인 | 강력한 접근 제어, 기기/사용자 식별 |
| **사용자 경험** | 브라우저 접속 시 즉시 연결 | 인증서 설치 및 선택 과정 필요 |

## 3. 구성 요소 및 발급 체계
클라이언트 인증서 체계는 공개키 기반 구조(PKI, Public Key Infrastructure)를 바탕으로 한다.

*   **공개키/개인키 쌍 (Public/Private Key Pair)**: 비대칭 암호화 알고리즘을 통해 생성된다. 개인키는 클라이언트가 안전하게 보관하며, 공개키는 인증서에 포함되어 서버에 전달된다.
*   **CSR (Certificate Signing Request)**: 인증서 서명 요청서. 클라이언트가 생성한 공개키와 식별 정보(DN, Distinguished Name)를 담아 CA에 제출하는 문서이다.
*   **CA (Certificate Authority)**: 인증 기관. CSR을 검토하고 자신의 개인키로 서명하여 신뢰할 수 있는 인증서를 발급한다.
*   **신뢰 체인 (Trust Chain)**: 루트 CA $\rightarrow$ 중간 CA $\rightarrow$ 엔드 엔티티(클라이언트)로 이어지는 계층 구조이다. 서버는 자신이 신뢰하는 루트 CA의 공개키를 가지고 있어, 클라이언트 인증서의 서명을 검증할 수 있다.
*   **X.509 표준**: 클라이언트 인증서를 포함한 공개키 인증서의 국제 표준 포맷이다. 인증서 버전, 일련번호, 서명자, 유효 기간, 주체(Subject) 정보 및 공개키 등이 정해진 규격에 따라 포함된다.

## 4. 주요 활용 사례
비밀번호는 유출이나 무차별 대입 공격(Brute-force)에 취약하므로, 고보안 환경에서는 클라이언트 인증서를 필수적으로 도입한다.

*   **금융망 및 공공기관**: 뱅킹 시스템의 관리자 페이지 접속, 정부 기관 간 데이터 송수신.
*   **기업 내부망 (Zero Trust)**: VPN을 대체하거나 보완하여, 승인된 단말기(Managed Device)만 내부 시스템에 접근하도록 제한.
*   **B2B API 통신**: 서버 간(Server-to-Server) 통신 시 API Key 대신 mTLS를 사용하여 호출자의 신원을 엄격히 제한.
*   **IoT 기기 인증**: 수많은 IoT 기기가 서버에 접속할 때, 각 기기에 고유 인증서를 부여하여 비인가 기기의 접속을 차단.

## 5. 구현 및 설정 방법

### 5.1 OpenSSL을 이용한 인증서 생성 (예시)
```bash
# 1. CA 개인키 및 루트 인증서 생성
openssl genrsa -out rootCA.key 2048
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.crt

# 2. 클라이언트 개인키 및 CSR 생성
openssl genrsa -out client.key 2048
openssl req -new -key client.key -out client.csr

# 3. CA가 클라이언트 CSR에 서명하여 인증서 발급
openssl x509 -req -in client.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out client.crt -days 365 -sha256

# 4. 브라우저 설치를 위한 PKCS#12(p12) 형식 변환
openssl pkcs12 -export -out client.p12 -inkey client.key -in client.crt -certfile rootCA.crt
```
**[파일 매핑 설명]**
- `rootCA.crt`: 서버 설정의 `ssl_client_certificate`에 등록되어 클라이언트 인증서를 검증하는 기준이 됨.
- `client.crt` & `client.key`: 클라이언트의 신원을 증명하는 인증서와 비밀키.
- `client.p12`: 사용자가 브라우저나 OS 인증서 저장소에 가져오기(Import) 하는 최종 배포 파일.

### 5.2 서버 설정 예시 (Nginx)
```nginx
server {
    listen 443 ssl;
    server_name secure.example.com;

    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;

    # 클라이언트 인증 설정
    ssl_client_certificate /etc/nginx/ssl/rootCA.crt; # 신뢰하는 CA 인증서
    ssl_verify_client on; # 클라이언트 인증서 요구 (on: 필수, optional: 선택)

    location / {
        # 인증 결과가 SUCCESS가 아닐 경우 403 Forbidden 반환
        if ($ssl_client_verify != SUCCESS) {
            return 403;
        }
        try_files $uri $uri/ =404;
    }
}
```

### 5.3 브라우저별 인증서 등록 방법
클라이언트 인증서는 일반적으로 `.p12` 또는 `.pfx` 파일 형태로 배포된다.

*   **Google Chrome / Microsoft Edge (Windows/macOS)**:
    1. 설정 $\rightarrow$ 개인정보 및 보안 $\rightarrow$ 보안 $\rightarrow$ 인증서 관리(또는 '인증서 관리자') 클릭.
    2. '가져오기' 버튼을 클릭하여 `.p12` 파일 선택.
    3. 인증서 생성 시 설정한 암호 입력 후 완료.
*   **Mozilla Firefox**:
    1. 설정 $\rightarrow$ 개인정보 및 보안 $\rightarrow$ '인증서' 섹션의 '인증서 보기' 클릭.
    2. '내 인증서' 탭 $\rightarrow$ '가져오기' 클릭.
    3. `.p12` 파일 선택 및 암호 입력 후 완료.
*   **Safari (macOS)**:
    1. '키체인 접근(Keychain Access)' 앱 실행.
    2. '내 인증서' 카테고리에 `.p12` 파일을 드래그 앤 드롭.
    3. 암호 입력 후 저장.

## 6. mTLS 도입 시의 장단점 비교

| 장점 | 단점 |
| :--- | :--- |
| **강력한 보안**: 개인키 탈취 없이는 접속이 불가능함 | **운영 복잡도**: 모든 클라이언트의 인증서 발급/배포 필요 |
| **피싱 방지**: ID/PW가 없으므로 사회공학적 공격에 강함 | **사용자 불편**: 인증서 설치 과정이 일반 사용자에게 어려움 |
| **정교한 식별**: 인증서 내 DN 정보를 통해 개별 기기 식별 가능 | **갱신 부담**: 만료일이 되면 모든 인증서를 재발급해야 함 |

## 7. 관리 및 보안 고려사항

### 7.1 인증서 만료 및 갱신 자동화
수동으로 수천 대의 클라이언트 인증서를 갱신하는 것은 불가능에 가깝다. 이를 위해 다음과 같은 자동화 방안을 도입한다.
*   **ACME 프로토콜**: Let's Encrypt와 같이 표준화된 프로토콜을 통해 인증서 발급 및 갱신 자동화.
*   **SCEP (Simple Certificate Enrollment Protocol)**: 네트워크 장비나 모바일 기기에서 CA와 통신하여 자동으로 인증서를 요청하고 설치하는 프로토콜.
*   **MDM (Mobile Device Management)**: 기업용 단말기 관리 솔루션을 통해 원격으로 인증서 프로파일을 푸시(Push) 배포.

### 7.2 인증서 폐기 메커니즘
인증서가 유출되었거나 사용자가 퇴사한 경우, 만료 전이라도 해당 인증서를 무효화해야 한다.
*   **CRL (Certificate Revocation List)**: CA가 폐기된 인증서 목록을 리스트 형태로 발행하고, 서버가 이를 다운로드하여 대조하는 방식이다. 목록이 커질수록 다운로드 시간과 메모리 사용량이 증가하여 성능 저하가 발생한다.
*   **OCSP (Online Certificate Status Protocol)**: 서버가 CA의 OCSP 응답 서버에 실시간으로 특정 인증서의 유효성을 질의하는 방식이다. CRL보다 실시간성이 높으나, CA 서버에 부하가 집중되고 클라이언트의 프라이버시 노출 문제가 있다.
*   **OCSP Stapling**: OCSP의 단점을 보완하기 위해, 서버가 CA로부터 인증서 상태 응답을 미리 받아두었다가 TLS 핸드셰이크 시 클라이언트에게 함께 전달하는 방식이다. 이를 통해 CA 서버 부하를 줄이고 응답 속도를 높일 수 있다.

### 7.3 개인키 보관 및 저장소 보안
인증서 자체보다 중요한 것은 **개인키(Private Key)**의 보호이다. 개인키가 유출되면 인증서의 모든 보안 체계가 무너진다.

*   **소프트웨어 저장소 (KeyStore)**:
    *   **Java KeyStore (JKS) / PKCS#12**: 애플리케이션 레벨에서 인증서와 키를 저장하는 파일 기반 저장소이다. 파일 자체에 암호를 설정하여 보호한다.
    *   **OS 인증서 저장소**: Windows 인증서 관리자나 macOS 키체인과 같이 운영체제가 제공하는 보안 저장소이다.
*   **하드웨어 기반 저장소**:
    *   **HSM (Hardware Security Module)**: 하드웨어 보안 모듈을 사용하여 개인키가 외부로 유출되지 않도록 물리적으로 격리된 환경에서 암호화 연산을 수행한다. 고도의 보안이 필요한 CA 서버나 금융 시스템에서 사용된다.
    *   **TPM (Trusted Platform Module)**: PC/노트북 메인보드에 내장된 보안 칩에 개인키를 저장하여 소프트웨어적인 탈취를 방지하고 기기 고유의 신원을 보장한다.