인증서는 Windows에 보이지만 OpenVPN이 그 키를 쓸 수 없는 이유
Windows 저장소의 인증서는 그대로 쓸 수 있는 신원이 아닙니다. 클라이언트의 저장소 선택자, 개인 키, 프로세스가 실행되는 계정을 확인하십시오.
인증서는 Windows 인증서 뷰어에 보이는데도 클라이언트는 그것을 쓸 수 없습니다. 인증서가 보인다는 것은 저장소에 공개 객체가 있다는 것만 증명합니다. 연결 프로세스가 짝이 맞는 개인 키를 찾을 수 있는지, 또는 그것을 쓸 권한이 있는지는 증명하지 않습니다.
세 객체가 맞아떨어져야 합니다. 선택된 인증서, 그 뒤의 개인 키, 클라이언트가 실행되는 계정은 서로 다른 것이며 각각 따로 실패할 수 있습니다.
세 객체, 세 가지 답
Windows의 커뮤니티 OpenVPN은 지문을 받는 CryptoAPI 저장소 선택자 cryptoapicert를 문서화합니다. 값은 실제로 쓰려는 인증서를 가리켜야 하며 이름이 비슷한 다른 인증서가 아닙니다. OpenVPN 기반의 다른 애플리케이션은 가져오기 모델이 완전히 다를 수 있으므로 이 선택자는 그것을 문서화한 빌드에 대해서만 증거가 됩니다. 하위 단계를 디버그하기 전에 클라이언트가 이 메커니즘을 구현하는지 확인하십시오.
빌드가 그 선택자를 지원하지 않는다면 해결책은 다른 프로필 형식이지 다른 인증서가 아닙니다.
선택자가 올바른 신원으로 해석되는가
공개 인증서는 개인 키 없이도 가져올 수 있습니다. 인증서 뷰어는 두 경우 모두 그것을 보여 주므로, 이 고장은 분명히 있는 인증서를 클라이언트가 무시하는 것처럼 보입니다. 항목의 존재만이 아니라 키 연결을 확인하십시오.
갱신된 인증서는 두 번째 함정을 더합니다. 프로필이 아직 이전 지문을 지목하는 동안 두 항목이 모두 저장소에 남을 수 있고, 클라이언트는 폐기하려던 신원을 계속 선택합니다.
권한을 보기 전에 선택자가 어느 신원으로 해석되는지 확인하십시오. 잘못된 지문은 키가 없을 때와 같은 방식으로 실패합니다.
이 계정이 키를 쓸 수 있는가
키 접근은 계정별입니다. 서비스, 예약된 작업, 대화형 데스크톱 세션은 저장소를 보는 방식과 개인 키를 쓸 권한이 서로 다를 수 있습니다. 자신의 세션에서 인증서가 보인다는 사실은 서비스 계정에 대해 아무것도 말해 주지 않습니다.
하드웨어 기반 키는 해당 공급자와 확인 단계가 필요할 수 있습니다. 프롬프트를 표시할 수 없는 서비스는 키를 일반 파일로 내보낸다고 해서 구제되지 않습니다.
무엇이든 바꾸기 전에 로컬 오류를 읽으십시오. 선택 실패, 서명 실패, 서버의 거부는 서로 다른 세 가지 결과입니다. 앞의 두 가지만 로컬입니다. 세 번째는 키가 동작했고 서버가 인증서를 거부했다는 뜻입니다.
로컬 사용은 서버의 수용이 아니다
로컬 성공은 권한 부여가 아닙니다. 클라이언트가 자기 키로 서명한 뒤에도 서버는 발급자, 유효 기간, 역할, 자체 접근 정책을 평가합니다. 같은 CA의 다른 인증서가 같은 VPN 권리를 자동으로 갖는 것은 아닙니다.
서버에 필요한 것은 신뢰 체인이지 클라이언트 개인 키의 사본이 아닙니다. 키를 서버로 보내는 것은 검증 문제의 해결책이 결코 아닙니다.
고장을 순서대로 다루십시오
오류 문구를 정확히 보관하십시오. 키 권한 부족이 CA 변경으로 번져서는 안 되고, 서버의 거부가 저장소 수리로 번져서도 안 됩니다. 각각은 자기 증거를 갖습니다.
고장이 나타나는 순서(선택자, 키, 계정, 그다음 서버 정책)대로 작업하십시오. 커뮤니티 클라이언트 참조는 실행 중인 버전의 Windows 저장소 선택자를 문서화합니다.