모든 VPN 클라이언트에 ca.key를 복사하면 CA가 무너지는 이유

설정 안내문 어딘가에서, 어떤 파일이 그곳에 속하는지 결정하는 것보다 쉽다는 이유로 디렉터리 하나가 모든 노트북에 통째로 복사된다. 그 디렉터리에는 ca.key가 들어 있고, 그것이 두 번째 기기에 도달하는 순간 인증 기관은 더 이상 기관이 아니다. 이제 어떤 보유자든 나머지 네트워크가 신뢰할 신원을 발급할 수 있다.

이 혼란은 두 파일이 비슷하게 생겼지만 정반대의 일을 하기에 한 번 풀어 볼 가치가 있다.

검증 재료와 서명 재료

클라이언트는 상대가 제시한 인증서가 그 기관에 의해 서명되었는지 확인하기 위해 CA의 공개 인증서를 필요로 한다. 이것은 검증 작업이며 어떤 비밀도 필요로 하지 않는다. 상대의 인증서에 서명하는 것은 다른 작업으로, CA를 운영하는 사람이 한 번만 수행하며, 보호된 저장소를 결코 떠나지 않는 개인 키를 사용한다. 이 두 작업을 분리해 두는 것이 두 파일을 배포하는 이유 전부다.

따라서 ca.crt은 프로필에 속하고 ca.key는 그 근처 어디에도 속하지 않는다. 파일 이름은 관례일 뿐 보장이 아니므로, 이름에서 추론하지 말고 유형을 확인해야 한다.

중간 CA나 온라인 발급 서비스를 쓰는 구조도 예외가 아니다. 기기 인증서를 대규모로 발급하면서 서명 능력을 엔드포인트에서 멀리 두는 표준적인 방법이다.

클라이언트가 자기 키로 증명해야 하는 것

각 기기는 자기만의 키 쌍과, CA가 한 번 서명한 자기만의 인증서를 받는다. 클라이언트는 그 인증서를 제시하고 대응하는 개인 키를 보유했음을 증명하며, 서버가 이를 받아들일지 결정한다. 노트북을 잃어버렸을 때 폐기되는 신원이 바로 이것이다.

이 대비는 도난 이후에 가장 중요하다. 기기별 신원이 있으면 노출된 클라이언트 하나는 폐기나 상대 제거로 빠지고, 나머지 함대는 계속 작동한다.

유출된 기관 키는 그렇게 다룰 수 없다. 그것이 서명한 또는 서명할 수 있었던 모든 인증서가 의심받으므로, 대응은 단일 폐기가 아니라 신뢰 자체를 교체하는 일이다. 그것은 티켓이 아니라 프로젝트다.

어딘가로 복사하기 전에 파일을 읽어라

두 명령이 아무 비밀도 출력하지 않고 지금 손에 든 대상이 어떤 종류인지 알려 준다. 첫 번째는 인증서의 주체와 CA 플래그를 밝히고, 두 번째는 키를 검증하여 그 유형을 보고한다. 배포하려는 번들의 파일에 둘 다 실행하라. 개인 키로 검증되는 것은 클라이언트 디렉터리에 두어서는 안 된다.

openssl x509 -in ca.crt -noout -subject -ext basicConstraints
openssl pkey -in ca.key -noout -check

클라이언트 번들에 있는 파일에서 두 번째 명령이 성공하면, 멈추고 그 번들을 침해된 것으로 취급하라. 키가 유효하다고 말하는 출력은 그 키가 존재한다고도 말하며, 존재 자체가 문제의 전부다.

반대 방향도 주목해야 하는데, 클라이언트 프로필에는 그 클라이언트 자신의 개인 키가 정당하게 들어 있다. 찾은 키를 닥치는 대로 지우면 아무것도 개선하지 못한 채 연결이 끊기므로, 제거하기 전에 대상의 정체를 확인해야 한다.

이미 배포한 키를 억제하기

로컬 사본을 지운다고 노출이 되돌아간다고 가정하지 마라. 파일을 가졌던 누구든 복사했을 수 있고, 복사했다고 보는 것이 안전한 가정이다. 운영자의 사고 대응 절차를 따르고 신뢰 앵커를 교체하며, 새 CA 아래에서 기기 인증서를 다시 발급하라.

그다음 문제를 만든 패키징을 바꿔라. 허용 파일을 명시한 목록과 함께 디렉터리 목록을 보내고, CA 키는 클라이언트 함대에 결코 합류하지 않는 기계에 두고, 어느 시스템이 그것을 보관하는지 기록하라.

기관이 자주 발급해야 한다면 서명을 범위가 좁고 유효 기간이 짧은 서비스나 중간 기관 뒤로 옮겨라. 그러면 미래의 실수는 배포 전체의 신뢰 뿌리가 아니라 발급의 일부만 노출한다.