인증서 체인

체인이 존재하는 이유는 가장 중요한 키를 오프라인에 둘 수 있게 하기 위해서입니다. 루트 인증서는 소수의 중간 인증서에 서명한 뒤 다시 금고에 보관되고, 중간 인증서들이 서버에 서명하는 일상적인 작업을 맡습니다. 검증은 반대 방향으로 진행됩니다. 전달받은 인증서에서 출발해 기기가 이미 가지고 있던 무언가까지 거슬러 올라가며, 어느 연결 고리 하나라도 빠졌거나 만료되었거나 인식되지 않으면 검증은 실패합니다.

작동 방식

일반적인 체인은 세 위치로 구성되며, 서버는 그중 두 개만 전송합니다.

맨 아래에는 특정 도메인 이름 집합을 위해 발급된 리프 인증서가 있습니다. 그 위에는 하나 이상의 중간 인증서가 있으며, 그 목적은 루트 인증서를 일상적인 사용으로부터 격리하는 것입니다. 맨 위에는 루트 인증서가 있으며, 자기 서명되어 있고 사용자가 해당 사이트를 방문하기 훨씬 전부터 사용자의 신뢰 저장소에 들어 있습니다. 서버는 리프 인증서와 중간 인증서를 전송합니다. 루트 인증서를 전송하면 바이트만 늘어날 뿐 아무것도 증명하지 못하기 때문입니다. 루트 인증서는 사용자가 이미 가지고 있을 때만 의미가 있습니다.

검증은 목록을 따라 곧장 올라가는 방식이 아닙니다. 하나의 인증서가 둘 이상의 발급자에 의해 서명될 수 있으며, 이를 교차 서명이라고 합니다. 따라서 클라이언트는 여러 후보 경로를 마주할 수 있고, 자신이 보유한 루트 인증서에서 끝나는 경로를 찾아야 합니다. 같은 웹사이트가 새 노트북에서는 열리고 오래된 휴대전화에서는 실패하는 이유가 여기에 있습니다. 신뢰 저장소가 다르기 때문에 경로가 다른 것입니다.

가장 명확한 예는 여전히 Let's Encrypt의 전환입니다. Let's Encrypt의 자체 루트 인증서인 ISRG Root X1은 아직 X1을 추가하지 않은 기기도 경로를 구성할 수 있도록 더 오래된 DST Root CA X3에 의해 교차 서명되었습니다. DST Root CA X3은 2021년 9월 30일에 만료되었습니다. X1을 보유한 기기는 아무도 알아차리지 못한 채 경로를 전환했지만, 7.1.1보다 오래된 Android 버전과 여러 레거시 TLS 라이브러리는 그렇게 하지 않았고, 전 세계에서 한 오후 만에 연결이 끊겼습니다. 해킹된 것도 없었고 키가 유출된 것도 아니었습니다. 날짜가 지났을 뿐입니다.

확인할 수 있는 곳

체인 문제는 무섭게 보이지만 거의 항상 평범한 원인에서 비롯됩니다.

가장 흔한 서버 설정 오류는 잊힌 중간 인증서입니다. 브라우저는 이전 방문에서 중간 인증서를 캐시하거나 인증서 안의 URL에서 가져와서 이러한 설정 오류를 흔히 감추기 때문에, 관리자에게는 사이트가 작동하고 명령줄 도구와 휴대전화에서는 실패합니다. 그래서 이 버그는 추적하기가 잊을 수 없을 만큼 짜증스러운 버그가 됩니다.

비트코인을 관리하는 사람이라면 체인 오류를 진단의 관점에서 읽는 것이 유용합니다. 한 기기에서는 거래소가 인증서 오류를 내고 다른 기기에서는 작동한다면, 차이는 거의 항상 기기에 있습니다. 시스템 시계가 잘못되었거나, 운영체제가 너무 오래되어 더 새로운 루트 인증서를 받지 못했거나, 백신 제품이 연결에 끼어들고 있는 경우입니다. 공격이라고 가정하기 전에 먼저 기기를 고쳐야 하며, 경고를 넘겨 접속하는 일은 절대 해서는 안 됩니다.

하드웨어 지갑의 인증은 훨씬 작은 규모로 같은 형태를 사용합니다. 제조사의 루트 인증서, 때로는 중간 인증서 하나, 그리고 기기 자체에 저장된 인증서로 구성됩니다.

인증서 체인 vs 루트 인증서

체인은 경로이고, 루트 인증서는 그 경로가 끝나야 하는 지점입니다. 체인에 있는 루트 인증서를 제외한 모든 인증서는 그 위의 무언가가 서명했기 때문에만 신뢰되지만, 루트 인증서는 기기가 처음 출하될 때 포함된 목록에 있기 때문에 신뢰되며 스스로에게 서명합니다. 따라서 그 목록에 루트 인증서를 추가하는 것은 다른 어떤 인증서를 수락하는 것보다 훨씬 큰 결정이며, 기업 네트워크와 트래픽 가로채기 도구가 사용자에게 요청하는 것이 바로 이것입니다.