인증서 신뢰 체인 설명

2026-05-07

chain-of-trustroot-caintermediatecertificateverification

브라우저가 HTTPS 사이트에 연결할 때 인증서를 맹목적으로 신뢰하지 않습니다. 신뢰 체인을 검증합니다 — 사이트 인증서에서 미리 신뢰된 루트 인증 기관(CA)까지 연결된 일련의 인증서입니다.

세 가지 수준

┌─────────────────────────────────┐
│         ROOT CA                 │  Pre-installed in browsers/OS
│   (ISRG Root X1 for LE)        │  Self-signed, long validity (20+ years)
└───────────────┬─────────────────┘
                │ signs
                ▼
┌─────────────────────────────────┐
│      INTERMEDIATE CA            │  Signed by the root
│   (Let's Encrypt R3/R10)       │  Medium validity (5-10 years)
└───────────────┬─────────────────┘
                │ signs
                ▼
┌─────────────────────────────────┐
│     YOUR CERTIFICATE            │  Signed by the intermediate
│   (example.com)                 │  Short validity (90 days for LE)
└─────────────────────────────────┘

루트 CA — 브라우저와 운영체제가 신뢰합니다. 기기의 인증서 저장소에 저장됩니다. 자체 서명됩니다(루트를 서명해주는 상위 기관이 없습니다 — 루트 자체가 신뢰의 기준점입니다). 루트 키는 하드웨어 보안 모듈에 오프라인으로 보관됩니다.

중간 CA — 루트가 서명합니다. 실제로 최종 엔티티 인증서를 발급합니다. 중간 CA가 침해되면 해당 CA만 폐기하면 되며, 루트는 안전하게 유지됩니다.

최종 엔티티 인증서 — 귀하의 인증서입니다. 중간 CA가 서명합니다. 서버가 브라우저에 전송하는 인증서입니다.

검증 작동 방식

브라우저가 인증서를 수신하면:

인증서 읽기 — 발급자 이름을 추출합니다
중간 인증서 찾기 — 서버 응답이나 브라우저 캐시에서
중간 인증서 서명 검증 — 신뢰할 수 있는 루트가 서명했는지 확인
인증서 서명 검증 — 중간 CA가 서명했는지 확인
유효기간 확인 — 어떤 인증서도 만료되지 않았는지
도메인 일치 확인 — 인증서의 SAN/CN이 URL과 일치하는지
폐기 확인 — 인증서가 폐기되지 않았는지(OCSP/CRL)

어떤 단계라도 실패하면 → 브라우저가 보안 경고를 표시합니다.

중간 인증서가 중요한 이유

가장 흔한 SSL 오류는 중간 인증서 누락입니다. 서버가 중간 인증서 없이 귀하의 인증서만 전송하면 브라우저가 신뢰 체인을 구축할 수 없습니다.

Nginx는 fullchain.pem(인증서 + 중간 인증서 결합)을 사용합니다:

ssl_certificate /etc/ssl/fullchain.pem;  # cert + intermediate

Apache는 별도 파일을 사용합니다:

SSLCertificateFile /etc/ssl/cert.pem          # your cert
SSLCertificateChainFile /etc/ssl/chain.pem    # intermediate

GetHTTPS는 fullchain.pem과 별도의 cert.pem + chain.pem 파일을 모두 제공하므로 어떤 서버에서든 올바른 형식을 사용할 수 있습니다.

Let’s Encrypt의 체인

Let’s Encrypt의 현재 체인:

ISRG Root X1 (root, in all trust stores)
  └── Let's Encrypt R10 (intermediate, signs your cert)
        └── yourdomain.com (your certificate)

이전 기기와의 호환성을 위해 IdenTrust의 DST Root CA X3을 통한 교차 서명 경로도 있지만, 대부분의 사용 사례에서는 더 이상 필요하지 않습니다.

자주 묻는 질문

”인증서를 신뢰할 수 없음” 오류를 어떻게 수정하나요?

거의 항상 중간 인증서가 누락된 것입니다. fullchain.pem(Nginx)을 사용하거나 SSLCertificateChainFile chain.pem(Apache)을 추가하세요. 다음으로 테스트할 수 있습니다:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

“verify return:1”(정상) vs “verify return:0”(체인 문제)을 확인하세요.

브라우저에서 체인을 볼 수 있나요?

네. 자물쇠 아이콘 클릭 → “인증서”(또는 “연결이 안전합니다” → “인증서가 유효합니다”)를 클릭하세요. 체인이 표시됩니다: 귀하의 인증서 → 중간 CA → 루트.

루트 CA가 침해되면 어떻게 되나요?

브라우저/OS 업데이트를 통해 신뢰 저장소에서 해당 루트가 제거됩니다. 해당 루트 아래 발급된 모든 인증서가 신뢰할 수 없게 됩니다. 이는 극히 드문 경우입니다 — 루트 키는 물리적 접근 통제가 있는 오프라인 하드웨어 보안 모듈에 보관됩니다.

Let’s Encrypt가 루트로 직접 서명하지 않고 중간 인증서를 사용하는 이유는?

보안 격리입니다. 중간 키가 침해되면 해당 중간 CA만 폐기하면 되며, 루트는 안전하게 유지됩니다. 루트 키는 오프라인으로 보관되며 중간 인증서를 서명할 때만 사용됩니다. 이는 모든 주요 인증 기관의 표준 관행입니다.

서버에 루트 인증서를 설치해야 하나요?

아닙니다. 루트 인증서는 브라우저와 운영체제에 미리 설치되어 있습니다. 서버는 인증서 + 중간 인증서만 전송하면 됩니다. 브라우저가 이미 루트를 보유하고 있으며 이를 사용하여 체인을 검증합니다.

체인 문제 디버깅

프로덕션 환경에서 가장 흔한 SSL 오류는 불완전한 인증서 체인입니다. 체계적으로 진단하는 방법은 다음과 같습니다:

1단계: 서버가 전송하는 체인 확인

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null

출력을 확인하세요:

Certificate chain
 0 s:CN = example.com
   i:C = US, O = Let's Encrypt, CN = R10
 1 s:C = US, O = Let's Encrypt, CN = R10
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---
Verify return code: 0 (ok)

Depth 0 = 귀하의 인증서
Depth 1 = 중간 인증서
“Verify return code: 0 (ok)” = 체인이 완전합니다

depth 0만 보이고 depth 1이 없다면 중간 인증서가 누락된 것입니다.

2단계: 체인 수정

Nginx: fullchain.pem(인증서 + 중간 인증서 결합)을 사용하세요:

ssl_certificate /etc/ssl/fullchain.pem;  # NOT cert.pem

Apache: 중간 인증서를 명시적으로 추가하세요:

SSLCertificateChainFile /etc/ssl/chain.pem

chain.pem을 분실한 경우: Let’s Encrypt의 중간 인증서를 letsencrypt.org/certificates에서 다운로드하거나 GetHTTPS로 인증서를 재발급하세요.

3단계: 수정 확인

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | grep "Verify return code"
# Must say: Verify return code: 0 (ok)