올바른 VPN 암호로는 없는 인증서를 대신할 수 없습니다

자격 증명은 올바르고 프로필도 깔끔하게 가져오지만, 인증이 끝나기 전에 연결이 여전히 실패합니다. Windows에서는 EAP 방식에 사용할 인증서를 찾지 못했다는 오류 798이 표시될 수 있습니다. OpenVPN에서는 클라이언트 로그에 서버를 결코 만족시키지 못하는 TLS 핸드셰이크가 나타납니다. 두 경우 모두 같은 누락된 대상, 즉 클라이언트가 제시했어야 할 클라이언트 인증서를 설명합니다.

암호는 비밀에 대한 지식을 증명하고 인증서는 키에 대한 소유를 증명하며, 하나가 다른 하나를 대신하지 못합니다.

암호는 문제가 아니었습니다

오류 798은 인증서 조회 실패입니다. 클라이언트는 구성된 인증 방식과 일치하는 인증서를 요구받고 자신의 저장소를 검색했지만 사용할 수 있는 것을 찾지 못했습니다. 이는 인증서가 없거나, 개인 키 없이 존재하거나, 만료되었거나, 조회가 닿지 않는 곳에 저장되어 있음을 뜻할 수 있습니다. 암호를 다시 시도해도 이런 조건은 바뀌지 않으므로 올바른 자격 증명으로도 오류가 다시 나타납니다.

조치하기 전에 메시지를 읽으세요. 자격 증명 거부, 인증서 조회 실패, TLS 핸드셰이크 실패는 서로 다른 세 가지 결과이며 그중 하나만 암호와 관련됩니다.

클라이언트 저장소에 있어야 할 것

두 가지 대상이 관련됩니다. 클라이언트 인증서는 VPN 클라이언트를 실행하는 사용자에 대해 개인 키와 함께 설치되어야 하고, 발급 루트가 신뢰되어야 합니다. .cer 파일에는 공개 인증서만 들어 있으므로 그것만으로는 아무것도 인증할 수 없습니다. Windows 인증서 관리자에서 클라이언트 ID는 현재 사용자의 개인 저장소에, 루트는 신뢰할 수 있는 루트 저장소에 속합니다.

ID를 컴퓨터 저장소에 또는 루트 저장소에만 설치하면 사용자의 개인 저장소를 대상으로 한 조회를 충족하지 못합니다. 저장소, 개인 키 플래그, 유효 기간을 함께 확인한 뒤 클라이언트를 다시 시작해 저장소를 다시 읽게 하세요.

두 제품, 같은 누락된 자격 증명

OpenVPN 서버는 기본적으로 클라이언트 인증서를 요구합니다. 클라이언트에 auth-user-pass를 추가하면 사용자 이름과 암호를 보내지만 TLS 핸드셰이크는 여전히 인증서를 요구하므로, verify-client-cert require 아래에서는 암호만으로 연결을 완료할 수 없습니다. 서버가 아무것도 요구하지 않도록 설정할 수 있는데, 그러면 암호가 유일한 클라이언트 자격 증명이 되어 강도가 실제로 낮아집니다. auth-user-pass-verify 뒤의 shell 스크립트로 자격 증명을 검증할 수 있지만 스크립트 실행이 활성화되어야 하므로 제대로 된 인증 백엔드보다 위험한 설계입니다.

암호만 사용하는 프로필은 푸시되는 옵션에도 의존하며, 그 옵션은 다시 풀 메커니즘이 활성화되어 있는지에 달려 있습니다.

검사를 끄는 방식으로 누락된 인증서를 고치지 마세요

메시지를 없애려고 검증을 느슨하게 하고 싶어집니다. 그러나 그것은 제 역할을 하던 통제를 없애고, 더 이상 주장을 증명하지 못하는 연결만 남깁니다. 게이트웨이가 최근 루트를 바꿨다면 이전 패키지에 예전 루트가 남아 있을 수 있으므로 프로필을 편집하는 대신 클라이언트 패키지를 다시 받으세요. 프로필 편집기에 인증서 인증 옵션이 없다면 설치된 Windows 버전이 그 방식을 제공하지 않을 수 있으니, XML을 직접 편집하는 대신 시스템을 업데이트하세요.

인증서가 어느 저장소에 있었는지, 어느 사용자가 클라이언트를 실행했는지, 개인 키가 있었는지를 기록하세요. 이 세 가지가 이 실패의 거의 모든 사례를 설명합니다.

암호는 문제가 없었습니다. 그 방식이 실제로 필요로 한 자격 증명은 다른 곳에 있었습니다.