Windows에서 OpenVPN 3와 Connect에서 cryptoapicert가 실패하는 이유

작동하던 OpenVPN 2 프로필을 더 새로운 Windows 클라이언트로 복사하면, 예전 클라이언트가 스스로 찾던 인증서가 더 이상 제공되지 않습니다. 그렇게 작동하게 만든 줄은 Community 2 클라이언트에 속한 Windows 전용 선택자이며, 더 새로운 응용 프로그램은 다른 자격 증명 경로를 가진 다른 프로그램입니다. 프로필은 그 한 줄 말고는 바뀌지 않았고, 바로 그 점이 차이를 알아보기 어렵게 만듭니다.

그 보고서에서는 Community 클라이언트, 코어 라이브러리, 그리고 누군가 설치한 프런트엔드라는 세 계층이 뒤섞여 있습니다. 그중 지시문을 이해한 것은 하나뿐이었습니다.

이 옵션이 존재하는 곳에서 뜻하는 것

Windows의 Community OpenVPN 2 클라이언트에서 cryptoapicert는 클라이언트가 파일이 아니라 Windows 인증서 저장소에서 찾아야 할 인증서를 지정합니다. 이는 Windows 전용 편의 기능이며, 그 클라이언트가 저장소를 열거하고 결과 키를 자체 TLS 스택에 넘길 줄 알기 때문에 작동합니다. 따라서 이 지시문은 그 클라이언트의 구성 언어 일부이지 OpenVPN 프로토콜의 속성이 아닙니다. 전송 형식에는 그것을 담는 것이 없습니다.

같은 줄을 다른 응용 프로그램에 복사하면, 새 프로그램이 구문 분석하거나 무시하거나 거부할 수 있는 단어를 복사한 것입니다. 지시문은 프로토콜 기능이 아니며, 이것은 OpenVPN을 말하는 모든 클라이언트의 기능도 아닙니다.

대신 코어 라이브러리가 제공하는 것

OpenVPN 3 Core는 다른 응용 프로그램이 내장하는 라이브러리이며, 외부 자격 증명을 저장소 조회가 아니라 API로 처리합니다. 내장하는 응용 프로그램이 인증서 체인을 제공하고 나중에 라이브러리에 외부 키로 서명하도록 요청하면, 라이브러리가 그것을 하기 위해 응용 프로그램을 다시 호출합니다. 이는 더 일반적인 설계이며, 어떤 공급자가 존재하는지는 프런트엔드가 결정한다는 뜻입니다. 라이브러리 자체의 옵션 처리에서 cryptoapicert는 구현되지 않은 지시문 가운데 나타나며, 이는 그러한 책임 분담과 일치합니다.

그 콜백의 존재가 특정 패키지 응용 프로그램이 현재 사용자의 개인 저장소를 열거하거나, 특정 키 공급자를 지원하거나, 스마트 카드 프롬프트를 완료할 수 있다는 뜻은 아닙니다. 그것들은 프런트엔드의 속성이며, 각각은 프런트엔드가 문서화해야 합니다.

대신 Windows 프런트엔드가 하는 일

OpenVPN Connect는 다른 길을 택합니다: 운영자가 PKCS#12 파일을 가져와 인증서와 개인 키를 담은 그 파일을 이 목적으로 만들어진 OpenVPN Certificate Store에 넣고, 다음으로 외부 인증서를 프로필에 할당합니다. 이는 의도적인 가져오기 단계이며, 개인 저장소에 있는 것을 자동으로 발견하는 것이 아닙니다. 다른 목적으로 설치한 인증서가 그저 클라이언트 목록에 나타날 것이라고 누군가 가정할 때 이 구분이 중요합니다.

가져오기는 키 정책에도 영향을 줍니다. 키를 P12 파일로 내보내는 것은 내보낼 수 없는 키가 바로 막으려는 일이기 때문에, 이는 구성이 아니라 정책의 문제이며 누군가 가져오기를 시도하기 전에 답이 필요합니다.

키의 정책에 맞는 경로를 선택하십시오

자격 증명을 내보낼 수 있고 정책이 문서화된 가져오기를 허용한다면, 조직의 보호된 등록 절차를 사용하고 임시 P12와 그 암호를 로그와 스크립트에서 빼 두십시오. 키가 스마트 카드나 보호된 공급자를 절대 떠나서는 안 된다면, 그 요구를 명시적으로 지원하는 클라이언트와 공급자 조합을 선택하거나, 설치한 버전에 대해 공급업체의 확인을 받으십시오. 어느 쪽도 다른 쪽의 우회 수단이 아닙니다.

지시문을 프로필에 다시 추가한다고 해서 응용 프로그램에 없는 통합을 제공할 수는 없습니다. 더 새로운 클라이언트 버전이 반드시 그것을 추가하지도 않는 것은 그 능력이 프런트엔드 자체의 설계에 속하기 때문입니다.

로컬 키가 작동한 뒤에도 서버는 인증서 신원, 체인, 권한을 확인합니다. 사용 가능한 로컬 키와 승인된 VPN 신원은 별개의 결과이며, 이 둘을 분리해 두는 것이 프런트엔드의 한계가 약화된 인증서 정책으로 바뀌는 것을 막습니다.