VPN을 위한 자체 서명 인증서와 공인 CA: 실제로 무엇이 달라지나

VPN 설정의 인증서 페이지에 도달하면 무료 자체 서명 옵션이 유료 공인 CA 옆에 보이고, 질문은 보안 선택처럼 들린다. 실제로는 대상 선택이다. 두 옵션 모두 같은 기본 요소로 터널을 암호화하며, 개인 키가 유출되면 둘 다 무용지물이 된다. 둘을 가르는 것은 서버의 신원에 대한 주장을 누가 하는지, 그리고 그 주장을 검증할 수 있는 위치에 누가 있는지다.

인증서는 혼동되는 두 가지 일을 한다

인증서는 공개 키를 이름에 묶고, 키가 암호화와 서명 작업을 한다. 인증서의 서명은 별도의 진술이다. 어떤 기관이 그 이름이 이 키 소유자에게 속함을 확인했다는 뜻이다. 자체 서명 인증서는 그 진술을 자기 자신에 대해 한다, 이는 제삼자의 주장이 전혀 아니다.

공개 웹사이트에는 제삼자 버전이 필요하다. 방문자는 사전 관계 없이 찾아오고 브라우저의 신뢰 저장소에 의존하기 때문이다. VPN 클라이언트는 낯선 상대가 아니다. 설치하는 프로필 안에 CA 인증서를 주거나 서버 인증서를 고정하므로, 검증은 정확히 당신이 선택한 기관을 상대로 실행된다. 그 검사가 의미를 가지려고 상업적 CA가 관여할 필요는 없다.

결과 세션의 강도는 서명자가 아니라 키 크기와 암호화 제품군에서 나온다. 그래서 자체 서명 인증서를 "덜 암호화되었다"고 부르는 것은 그냥 틀렸다. 널리 보증되지 않는다는 것은 다른 속성이다.

공인 CA가 그 요금을 정당화하는 곳

가장 분명한 경우는 관리 페이지다. 동료, 계약자 또는 준비된 프로필이 없는 누군가가 브라우저 경고 없이 VPN 서버의 웹 인터페이스를 열어야 한다면, 공개적으로 신뢰된 인증서가 그 마찰을 없앤다. 브라우저는 이미 서명자를 신뢰하므로 가져올 것도, 설명할 것도 없다.

그 편리함에는 구매 전에 언급할 만한 비용이 있다. 갱신을 자동화하지 않으면 사이트가 일정에 따라 깨지고, 공인 인증서는 인증서 투명성 로그에 호스트 이름을 노출하며, 발급 속도 제한은 너무 열심히 재시도하는 스크립트를 벌한다. 어느 것도 공인 CA를 피할 이유는 아니지만, 사설 CA가 다른 곳으로 옮기는 운영 작업이다.

공인 인증서가 하지 않는 일은 사용자를 인증하는 것이다. 클라이언트 신원은 별도의 결정으로, 클라이언트 인증서, 비밀번호 또는 두 번째 요소로 정해지며, 서버에 서명하는 CA는 누가 거기에 연결할 수 있는지에 대해 아무것도 말하지 않는다.

사설 CA가 VPN에 맞는 곳

클라이언트 집합이 알려진 사설 VPN에서는 자체 CA를 운영하는 것이 관행적 선택이다. CA를 한 번 만들고, 클라이언트가 사용할 이름으로 서버 인증서에 서명하며, 각 프로필 안에 CA 인증서를 배포한다. 그러면 각 클라이언트가 당신의 기관을 상대로 서버를 검증하고, 외부 어느 누구도 호스트 이름을 알지 못한다.

비용은 실제지만 제한적이다. 누군가 관리 페이지를 직접 열면 브라우저가 경고한다. 브라우저가 당신의 CA를 신뢰할 이유가 없기 때문이다. 프로필 배포는 온보딩의 일부가 되고, CA를 교체하려면 모든 클라이언트를 건드려야 한다. 이는 알려진 사용자가 열 명이나 쉰 명인 서비스에는 받아들일 만한 가격이고, 수천 명인 공개 엔드포인트에는 고통이다.

한 가지 조건이 전체 배치를 유효하게 만든다. 검증이 실제로 일어나야 한다. 인증서 오류를 무시하도록 구성된 클라이언트는 어떤 인증서를 제시하든 어떤 서버든 받아들이므로, 암호화는 남고 신원 보장은 사라진다. 그 설정이 "자체 서명은 안전하지 않다"는 이야기 대부분의 진짜 약점이다.

CA의 개인 키가 나중에 무엇을 할 수 있는지 결정한다

놀라움은 보통 몇 달 뒤 기기를 추가하고 싶을 때 찾아온다. 클라이언트 인증서를 발급하려면 CA의 개인 키가 필요하고, 폐기 목록을 만들 때도 마찬가지다. 인증서와 키 파일은 있지만 CA 키는 없는 서버를 물려받았다면 새로 서명할 수 없다. 선택지는 PKI를 다시 구축해 모든 클라이언트에 새 CA 인증서를 주거나, 비밀번호 인증으로 전환하는 것이다. 후자는 다른 보안 모델이며 잃은 것을 되돌리지 않는다.

같은 영역에 더 작은 함정 두 개가 있다. easy-rsa 스크립트는 그것을 담은 디렉터리에 서 있다고 가정하므로, 파일이 없다는 오류는 보통 손상된 설치가 아니라 잘못된 위치를 뜻한다. 그리고 인증서만으로 구성하는 설계는 완전히 합법적이다. 사전 공유 키 없이 클라이언트 인증서를 요구할 수 있으며, 각 클라이언트가 하나를 갖고 서버가 체인을 검증하면 된다.

팀 전체를 위한 하나의 공유 클라이언트 인증서 대신 기기마다 인증서 하나를 발급하라. 그러면 노트북을 잃어버려도 모두를 위해 재발급하는 대신 한 번의 폐기로 끝난다.

물려받은 것을 확인하라

어떤 변경이든 계획하기 전에 이미 가진 인증서를 읽어라:

$ openssl x509 -in server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.net
issuer=CN = vpn.example.net
notAfter=Nov  3 09:00:00 2027 GMT
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK

발급자가 주체와 같다면 그 인증서는 자체 서명이며, 이는 결함이 아니라 설계 선택이다. 날짜는 갱신이 언제 누군가의 문제가 되는지 알려주고, 배포하려는 CA를 상대로 한 성공적인 검증은 클라이언트 하나가 시도하기 전에 체인이 작동함을 확인한다.

그다음 대상과 배포 방식으로 선택하라. 알 수 없는 브라우저가 관리 페이지를 신뢰해야 한다면 공인 CA, 각 클라이언트가 당신이 통제하는 프로필을 받는다면 사설 CA다. 어느 답도 다른 쪽보다 더 암호화되어 있지 않다.