SSL 인증서 체인이란? 작동 방식 설명

SSL 인증서 체인이란?

SSL 인증서 체인(신뢰 체인 또는 인증 경로라고도 함)은 웹사이트의 SSL/TLS 인증서를 신뢰할 수 있는 루트 인증 기관(CA)에 연결하는 순서가 있는 디지털 인증서 목록입니다. 체인의 각 인증서는 바로 위 인증서가 디지털 서명하여, 서버에서 브라우저가 이미 신뢰하는 루트 CA까지 검증 가능한 신뢰 경로를 만듭니다.

추천서의 연쇄라고 생각하면 쉽습니다. 서버 인증서는 "저는 example.com입니다"라고 말하고, 중간 CA는 "example.com의 인증서를 보증합니다"라고 말하며, 루트 CA는 "그 중간 CA를 보증합니다"라고 말합니다. 브라우저는 루트 CA를 이미 신뢰하므로, 서명을 따라가면 서버도 신뢰하게 됩니다.

HTTPS 사이트에 접속하면 브라우저가 이 체인을 몇 밀리초 만에 추적합니다. 모든 고리가 정상이면 경고 없이 페이지가 로드됩니다. 고리가 없거나 만료되었거나 신뢰할 수 없으면 대신 NET::ERR_CERT_AUTHORITY_INVALID 같은 보안 경고가 표시됩니다.

체인을 이루는 세 종류의 인증서

모든 체인에는 세 종류의 인증서가 있지만, 서버는 중간 인증서를 둘 이상 보낼 수 있습니다.

루트 인증서

루트 인증서는 체인 최상단의 신뢰 기준점입니다. 자체 서명되어 있는데, 인증 기관이 자기 인증서에 직접 서명했다는 뜻입니다. 루트 인증서는 브라우저와 운영 체제에 미리 설치되어 있으며, 이 모음을 신뢰 저장소(trust store)라고 합니다.

Chrome 자체 루트 목록에는 약 100개의 루트가 있습니다(Chrome Root Store). Mozilla, Apple, Microsoft도 각자 목록을 관리합니다. DigiCert, Let's Encrypt(ISRG), Sectigo, GlobalSign, Google Trust Services 같은 기관이 루트를 운영합니다. 루트 키는 매우 가치가 크기 때문에 CA는 이를 하드웨어 보안 모듈에 오프라인으로 보관하고 중간 인증서에 서명할 때만 사용합니다.

중간 인증서

중간 인증서는 루트와 서버 인증서 사이에 있습니다. 루트 CA가 중간 인증서에 서명하고, 그 중간 CA가 최종 사용자(서버) 인증서에 서명합니다. 대부분의 CA는 중간 인증서를 하나 또는 둘 사용합니다.

웹 서버는 TLS 핸드셰이크 중에 리프 인증서와 함께 중간 인증서도 보내야 합니다. Chrome은 없는 중간 인증서를 내려받을 수 있고 Firefox는 미리 내장하고 있지만, 앱, API 클라이언트, 오래된 Android 기기는 둘 다 못 하므로 이들에게는 체인이 끊어집니다.

리프 인증서(서버 인증서)

리프 인증서(최종 엔티티 인증서 또는 서버 인증서라고도 함)는 웹 서버에 설치된 인증서입니다. 도메인 이름, 공개 키, 유효 기간, 발급자 정보(서명한 중간 CA)가 포함됩니다.

이것은 TLS 핸드셰이크 중에 브라우저가 가장 먼저 받는 인증서입니다. 그런 다음 브라우저는 체인을 올라가며 신뢰할 수 있는 루트에 도달할 때까지 각 서명을 확인합니다.

신뢰 체인의 작동 방식

브라우저가 HTTPS를 통해 웹사이트에 연결하면 TLS 핸드셰이크가 밀리초 단위로 발생하는 체인 검증 프로세스를 시작합니다:

• 서버가 인증서를 보냅니다 — 리프, 그다음 중간 인증서.
• 브라우저가 경로를 구성합니다 — 리프에서 자체 목록의 루트까지. 중간 인증서가 없으면 Chrome은 인증서에 적힌 주소(AIA)에서 내려받고, Firefox는 미리 내장된 집합을 사용합니다. 그 밖의 많은 클라이언트는 그냥 실패합니다.
• 서명을 확인합니다 — 각 인증서는 바로 위 인증서의 키로 서명되어 있어야 합니다.
• 루트를 확인합니다 — 경로는 브라우저 목록에 있는 루트에서 끝나야 합니다. 알 수 없는 루트는 실패합니다.
• 유효성을 확인합니다 — 모든 인증서가 유효 기간 안에 있고 폐기되지 않았어야 하며, 리프가 주소 표시줄의 이름을 포함해야 합니다.

실제 체인: 대형 사이트 12곳이 보내는 것

2026년 10월 27일에 대형 사이트 12곳의 체인을 요청했습니다(openssl s_client -showcerts, 두 곳에서 실행). 리프만 보낸 사이트는 없었고, 오래된 기기도 자신이 아는 루트에 닿을 수 있도록 교차 서명된 인증서를 추가로 보내는 사이트도 여럿 있었습니다. 서버가 보내는 내용은 TLS 버전, 클라이언트의 ECDSA 지원 여부, 응답한 CDN 위치에 따라 달라질 수 있습니다. 예를 들어 facebook.com은 TLS 1.2에서 인증서 3개를 보냈습니다.

검증 후 결과

모든 검사를 통과하면 연결이 진행됩니다. 중간 인증서에서라도 하나가 실패하면 브라우저는 "연결이 비공개로 설정되어 있지 않습니다" 같은 경고를 NET::ERR_CERT_AUTHORITY_INVALID 같은 코드와 함께 표시합니다. (인증서를 살펴보기 전, TLS 핸드셰이크 자체에서의 실패는 다른 코드가 표시됩니다: ERR_SSL_PROTOCOL_ERROR 또는 ERR_SSL_VERSION_OR_CIPHER_MISMATCH.)

그래서 리프 인증서만이 아니라 체인 전체가 중요합니다. 만료된 중간 인증서는 클라이언트가 이를 우회하는 다른 경로를 구성할 수 없는 한, 만료된 서버 인증서와 똑같이 HTTPS를 깨뜨립니다.

중간 인증서가 존재하는 이유

루트 CA는 이론적으로 모든 서버 인증서에 직접 서명하여 중간 인증서를 완전히 건너뛸 수 있습니다. 하지만 그렇게 하지 않는 세 가지 중요한 이유가 있습니다:

• 보안 격리 — 루트 CA 개인 키는 물리적으로 안전한 금고 안의 HSM에서 오프라인으로 보관됩니다. 수백만 개의 개별 서버 인증서가 아닌 중간 인증서 서명에만 사용됩니다. 이로써 루트 키 침해 위험이 크게 감소합니다.
• 피해 억제 — 중간 CA가 침해되면 해당 중간 CA의 인증서만 영향을 받습니다. 루트 CA는 침해된 중간 인증서를 폐기하고 새로운 것을 발급할 수 있으며, 이전에 발급한 모든 인증서를 무효화하지 않습니다.
• 운영 유연성 — CA는 목적에 따라 서로 다른 중간 인증서를 사용합니다: DV 인증서용, EV용, 다양한 지역 또는 키 알고리즘(RSA vs ECDSA)용으로 별도의 것을 사용합니다.

SSL 인증서 체인 확인 방법

명령줄 도구부터 브라우저 기반 확인까지, 웹사이트의 인증서 체인을 검사하는 방법은 세 가지입니다.

방법 1: OpenSSL (명령줄)

openssl 명령은 인증서 체인을 검사하는 가장 상세한 방법입니다. 터미널에서 다음을 실행하세요:

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# Then read the verdict
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -m1 'Verify return code'

방법 2: 브라우저 인증서 뷰어

모든 주요 브라우저는 자신이 구성한 체인을 보여줍니다(없는 중간 인증서를 브라우저가 직접 가져왔다면 서버가 보낸 것과 다를 수 있습니다).

• Chrome: 주소 왼쪽의 아이콘 클릭 → 이 연결은 안전합니다 → 인증서가 유효함을 선택한 뒤 세부정보 탭에서 인증서 계층 구조를 확인합니다
• Edge: 자물쇠 클릭 → "Connection is secure" → 패널 상단의 인증서 아이콘
• Firefox: 자물쇠 클릭 → 안전한 연결 → 자세한 정보 → 인증서 보기. 체인의 각 인증서마다 탭이 따로 있습니다
• Safari(18.4 이상): 메뉴 막대에서 Safari > 연결 보안 세부사항을 선택합니다(Apple). iPhone에서는 주소 필드의 왼쪽을 탭 → "Privacy & Security" → "Connection Security Details"

방법 3: DNS Robot SSL 검사기

네트워크 밖에서 가장 빠르게 확인하는 방법은 저희 SSL 검사기입니다. 서버가 보내는 체인, Mozilla·Chrome·Apple·Microsoft 루트 목록이 각각 이를 신뢰하는지, 체인이 불완전할 때의 경고, 각 인증서의 날짜를 보여줍니다. Cloudflare 뒤에 있는 사이트는 공개 CT 로그에서 인증서를 읽기 때문에, 그 경우 서버가 보내는 체인 자체는 확인되지 않습니다.

일반적인 인증서 체인 오류 및 해결 방법

인증서 체인 문제는 HTTPS 오류의 가장 흔한 원인 중 하나입니다. 가장 자주 발생하는 오류와 각각의 해결 방법을 소개합니다.

중간 인증서 누락

오류 메시지: "unable to get local issuer certificate"(curl, Python, PHP), "unable to verify the first certificate"(Node.js) 또는 "incomplete certificate chain"

원인: 서버가 리프 인증서만 보냅니다. Chrome은 중간 인증서를 직접 내려받아 보완하는 경우가 많아(Apple의 검증기도 마찬가지) 브라우저에서는 사이트가 정상으로 보이지만, Linux의 curl, Python, Java, 결제 콜백, 많은 앱에서는 실패합니다.

해결: 리프와 함께 중간 인증서를 보내세요. Let's Encrypt라면 서버가 cert.pem이 아니라 fullchain.pem을 가리키게 하고, 다른 CA라면 해당 중간 인증서를 내려받아 내 인증서 뒤에 붙여 하나의 파일로 만드세요.

cat your-domain.crt intermediate.crt > fullchain.crt

체인 내 자체 서명 인증서

오류 메시지: "self-signed certificate in certificate chain"(OpenSSL 오류 19)

원인: 체인이 클라이언트가 신뢰하지 않는 루트로 끝납니다. 사설 또는 회사 CA이거나, 자체 루트로 트래픽을 다시 서명하는 프록시나 백신이 해당됩니다. 클라이언트가 신뢰하는 루트를 보내는 것은 해롭지 않고 불필요할 뿐입니다.

해결: 공개 사이트에는 공인 CA의 인증서를 사용하거나, 필요한 클라이언트에 사설 루트를 설치하세요. 서버 체인에서 루트를 빼는 것은 깔끔하지만 이 오류를 고치지는 못합니다.

잘못된 인증서 순서

오류 메시지: 일부 클라이언트에서 체인 검증이 실패하거나, 인증서를 신뢰할 수 없다고 보고합니다.

원인: 체인 파일의 인증서 순서가 잘못되었습니다. TLS 1.3은 서버 자신의 인증서를 먼저 두고 나머지도 순서대로 보내도록 요구하면서, 클라이언트에는 다른 순서도 처리하도록 하고 있습니다(RFC 8446 §4.4.2). 오래되었거나 엄격한 클라이언트는 그렇지 않을 수 있습니다.

해결: 리프 인증서를 맨 앞에 두고, 그다음 리프에 서명한 것부터 시작해 각 중간 인증서를 순서대로 두세요.

체인 내 만료된 인증서

오류 메시지: "certificate has expired" — 하지만 리프 인증서의 만료일은 정상으로 보입니다.

원인: 체인 위쪽의 인증서가 만료되었습니다. 가장 유명한 사례는 Let's Encrypt 루트에 교차 서명했던 IdenTrust의 DST Root CA X3가 2021년 9월 30일에 만료되어, ISRG Root X1을 신뢰하지 않는 기기(및 OpenSSL 1.0.x 클라이언트)가 Let's Encrypt 사이트에서 실패하기 시작한 일입니다.

해결: CA에서 최신 중간 인증서를 내려받아 이전 것을 교체하세요. 그런 다음 저희 SSL 검사기로 갱신된 체인을 확인하세요.

인증서 체인 모범 사례

• 항상 중간 인증서를 보내세요 — 브라우저가 체인을 고쳐주리라 기대하지 마세요. 앱과 API 클라이언트는 고쳐주지 않습니다.
• 루트는 선택 사항입니다 — 클라이언트는 자기 사본을 쓰므로 신뢰하는 루트를 보내면 바이트만 늘어납니다. 오래된 기기를 위한 교차 서명 루트는 의도적인 예외입니다.
• 순서를 지키세요 — 리프를 먼저, 그다음 리프에 서명한 것부터 위로 올라가며 중간 인증서를 둡니다.
• 갱신을 자동화하세요 — 2026년 3월 이후 발급된 인증서는 최대 200일이며 2027년 3월에는 100일로 줄어들고, Let's Encrypt는 2027년 2월에 64일 인증서로 옮겨 갑니다.
• 갱신이나 이전 때마다 확인하세요 — CA는 갱신 사이에 중간 인증서를 바꿀 수 있습니다. 그때마다 SSL 검사기로 사이트를 확인하세요.
• 모든 이름을 살펴보세요 — www, 루트 도메인, 각 서브도메인은 서로 다른 인증서와 체인으로 제공될 수 있습니다. 서브도메인 찾기는 공개 인증서 로그에서 인증서가 다뤄 온 이름을 보여줍니다.