OpenVPN 프로필에는 세 개의 인증서 블록이 있습니다: 어느 것이 비밀일까요

한 줄을 바꾸려고 .ovpn 파일을 열면 모두 자격 증명처럼 보이는 base64 블록 세 개가 나옵니다. 하나는 공개해도 안전하고, 하나는 비밀번호만큼 민감하며, 하나는 짝이 되는 키로 무언가에 서명하지 않으면 아무 의미가 없는 공개 키입니다. 블록이 서로 바꿔 쓸 수 있는 것처럼 보여서 사람들은 파일 전체를 지원 스레드에 붙이고, 그렇게 클라이언트 키가 공개 저장소에 남습니다. 어느 블록이 무슨 일을 하는지 구분하면 이런 프로필을 둘러싼 혼란의 대부분이 설명되고, 어떤 고장을 직접 고쳐야 하는지도 알 수 있습니다.

파일 하나, 블록 셋, 서로 다른 역할

일반적인 프로필은 BEGIN과 END 표시 사이에 ca 블록, cert 블록, key 블록을 넣거나 같은 셋을 별도 파일로 가리킵니다. 일부 프로필은 tls-auth나 tls-crypt 키를 위한 네 번째 블록을 더하는데, 이는 인증서가 아니라 공유 비밀입니다. 클라이언트는 각 블록을 그것을 지시하는 지시문에 따라 읽으므로, 나타나는 순서보다 이름표가 더 중요합니다.

실제로 안을 들여다보기 전까지는 조립된 프로필을 민감한 것으로 취급하십시오. 공개 인증서와 개인 키가 같은 파일에서 몇 줄 차이로 붙어 있을 수 있고, 헤더를 포함한 스크린샷에는 둘 다 담길 수 있습니다. 보이는 base64를 손으로 가리는 것도 믿을 수 없는데, 일부만 남은 블록도 배포 이름을 알려 주는 인증서 메타데이터를 흘리기 때문입니다. 세 지시문을 값 없이 복사하는 것만으로도 보통은 쓸모 있는 질문을 할 수 있습니다.

블록 주변의 지시문이 사용 방식을 결정합니다. ca를 바꾸면 클라이언트는 다른 기관을 신뢰하고, key를 바꾸지 않고 cert를 바꾸면 신뢰와 무관한 불일치로 핸드셰이크가 실패합니다.

CA 블록은 공개, CA 키는 절대 아님

인증 기관은 공개 키를 신원에 묶는 인증서에 서명하며, 그 기관 자신의 인증서는 클라이언트가 체인을 신뢰할지 판단하는 기준점입니다. 이 인증서는 설계상 공개이므로 모든 프로필에 함께 넣는 것이 정상이며, 그래서 자체 서명 배포가 상업 기관 없이도 동작할 수 있습니다.

클라이언트 프로필에 절대 나타나서는 안 되는 것은 기관의 개인 서명 키입니다. 클라이언트는 무엇을 검증하는 데에도 그것이 필요 없고, 그것이 있으면 프로필을 가진 누구든 배포 전체의 새 신원을 만들 수 있습니다.

기관을 신뢰하는 일은 들리는 것보다 좁습니다. CA가 서명한 어떤 인증서든 받아들이는 클라이언트는 같은 CA에서 다른 서비스용으로 발급된 인증서도 받아들입니다. 기대하는 서버 역할이나 이름을 고정하는 옵션이 그 틈을 막고, TLS 옵션 참조 가 그렇게 하는 검증 지시문을 나열합니다.

서버 인증서와 클라이언트 인증서는 반대 방향을 가리킵니다

서버 인증서는 클라이언트가 올바른 종단점에 도달했는지 확인하려고 살펴보는 것입니다. 반대로 클라이언트 인증서는 서버가 이 장치나 사용자가 자신이 등록한 대상인지 판단하는 데 씁니다. 형식은 같고 신뢰의 방향은 반대입니다.

주소는 신원이 아닙니다. 올바른 IP에 도달해도 누가 응답했는지는 아무것도 증명하지 않으므로 호스트 이름이나 인증서 이름 검사는 여전히 프로필에 속합니다. 계정 비밀번호도 요구되는 클라이언트 인증서를 조용히 대신하지 않으며, 둘은 서로 다른 단계에서 검사되고 배포가 둘 다 요구할 수 있기 때문입니다.

클라이언트 개인 키는 비밀로 남아야 하는 부분입니다. 노출되었을 가능성이 있다면 노트북에서 파일을 지워도 서버에서는 아무것도 달라지지 않고, 운영자가 폐기할 때까지 해당 인증서를 계속 받아들입니다. 운영자에게 그 신원을 교체하거나 폐기해 달라고 요청하는 것만이 함께 이동하는 유일한 해결책입니다.

똑같아 보이지만 같지 않은 두 가지 요청

암호화된 형태로 저장된 키는 클라이언트가 쓰기 전에 암호 문구를 요구합니다. VPN 서비스가 별도로 계정 비밀번호를 요구할 수 있고, 두 요청은 거의 같은 문구로 몇 초 간격을 두고 나타날 수 있습니다. 암호 문구는 디스크의 파일을 보호하고, 비밀번호는 서버에 계정을 증명합니다. 둘을 혼동하면 도움이 될 수 없는 비밀번호 재설정으로 사람들을 보내게 됩니다.

무엇이든 재설정하기 전에 요청 내용을 읽으십시오. 계정 비밀번호 재설정은 잊어버린 키 암호 문구나 폐기·만료된 인증서에는 아무 소용이 없고, 고장이 인증서 검증인데 비밀번호를 재설정하면 두어 분이면 되는 수정이 지원 사건이 됩니다. 불만이 유효 기간 날짜를 언급하면 먼저 장치 시계를 확인하고, 다음으로 해당 인증서 자체의 유효 기간을 보십시오.

인증서가 실제로 만료되었다면 교체는 그것을 발급한 곳에서 와야 합니다. 다른 사람의 키는 갱신 경로가 아니며, 동료에게서 동작하는 프로필을 빌리는 것도 마찬가지입니다.

깨끗한 핸드셰이크가 증명하는 것과 증명하지 않는 것

완료된 TLS 핸드셰이크에 도달했다는 것은 설정된 신원 관계가 유지되었다는 뜻이고, 서버 인증서가 자신의 CA에 연결되고 자신의 인증서가 받아들여졌습니다. 운영자의 기록 정책에 대해서는 아무 말도 하지 않고, 터널이 올라간 뒤 애플리케이션이 동작할지도 말하지 않습니다.

경로와 DNS는 연결의 이후 단계이므로, 로그인에 성공한 뒤 인트라넷 호스트에 닿지 않는 것은 인증서가 아니라 연결 문제입니다. 자격 증명을 바꾸는 대신 그 계층을 다루고, 프로필을 누군가에게 건넬 때 그 출처와 개인 자료, 신원 검사를 함께 넘기십시오.