Windows VPN이 제공하는 컴퓨터 인증서는 무엇인가?

인증서도 설치되어 있고 개인 키도 있는데 터널은 여전히 인증에 실패한다. 인증서가 여러 장인 컴퓨터는 아무도 의도하지 않은 후보를 VPN에 건넬 수 있고, 클라이언트는 게이트웨이가 어느 것을 받아들일지 알 방법이 없다. 나머지를 삭제하는 것은 컴퓨터의 모든 서비스에 영향을 주는 선택 정책이다. 대신 적격 집합을 좁힌 뒤 실제로 어떤 인증서가 제공되었는지 확인하자.

인증서는 여럿, 제공되는 것은 하나

컴퓨터 인증서 인증을 쓰는 Windows 기본 VPN 프로필은 후보를 제한하는 두 가지 필터를 제공한다. 발급자 필터와 확장 키 사용 필터다. 이들은 클라이언트가 고를 수 있는 집합을 줄인다. 부적합한 인증서를 고치지는 않으며, 남은 것을 서버가 받아들인다고 보장하지도 않는다. 이 경계는 변경 기록에 적어 둘 만하다. 다음 독자는 필터가 실제보다 더 많은 것을 결정했다고 여길 것이기 때문이다.

두 필터가 다루는 장애는 좁고 구체적이다. 잘못된 기관의 유효한 인증서, 또는 게이트웨이가 받아들이지 않는 용도로 발급된 인증서가 의도한 것보다 먼저 선택되어, 건강한 저장소 옆에서 인증 실패가 생긴다. 두 필터는 이를 따져 볼 수 있을 만큼 작은 집합으로 바꾸고, 이 페이지의 나머지는 이들을 순서대로 적용한다.

프로필을 편집하기 전에 저장소를 살펴보자

프로필이 실제로 쓰는 저장소에서 후보와 그 속성을 나열한다. 여기서 개인 키를 내보내지 않으며, 어떤 인증서도 컴퓨터를 떠날 필요가 없다:

Get-VpnConnection -Name 'Office' | Select-Object Name, TunnelType, AuthenticationMethod
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Issuer, Thumbprint, NotAfter, HasPrivateKey, EnhancedKeyUsageList

판단이 기대는 속성에 대해 출력을 읽는다. 쓸 수 있는 개인 키, 받아들일 만한 유효 기간, 의도한 발급자, 확장에 담긴 용도다. 인증서는 동시에 존재하고 올바르게 등록되어 있으면서 이 연결에는 쓸모가 없을 수 있다. 나중에 비교할 것은 지문 열이므로 출력을 보관하자.

편집 전에 프로필과 그 범위를 확인하자. LocalMachine 에 있는 컴퓨터 인증서, 사용자 EAP-TLS 인증서, 응용 프로그램 자체의 개인 키 저장소는 서로 다른 세 가지 맥락이기 때문이다. 관리되는 프로필이 그곳에 있으면 모든 사용자 범위와 관리자 맥락을 쓴다. 비슷한 이름으로 두 번째 프로필을 만들면 연결이 실제로 어느 구성을 쓰는지가 가려진다.

발급자 필터는 개체를 원한다

발급자 매개 변수는 인증서 개체를 기대하며, 표시 이름도 아니고 꾸밈없는 지문 문자열도 아니다. 승인된 기관의 인증서를 확인한 경로에서, 그것이 속한 저장소로 넘긴다:

$issuerPath = Read-Host 'Certificate-provider path for the approved issuer CA'
$issuer = Get-Item -LiteralPath $issuerPath
Set-VpnConnection -Name 'Office' -MachineCertificateIssuerFilter $issuer

매개 변수 형식이 받아들인다는 이유만으로 클라이언트 자체의 리프 인증서, 비슷한 주체를 가진 다른 기관, 갓 만든 루트로 바꾸지 말자. 두 기관이 같은 주체 문자열을 공유할 수 있다, 그래서 텍스트보다 개체가 더 중요하다. Microsoft cmdlet 참조 는 두 입력 형식을 모두 문서화하며, 실패한 시도 뒤가 아니라 첫 편집 전에 읽을 만하다.

사용 필터는 OID 문자열을 원한다

확장 키 사용 매개 변수는 OID 문자열을 받고, 클라이언트 인증의 용도는 1.3.6.1.5.5.7.3.2 이다. 이를 적용하면 후보가 그 용도를 지닌 인증서로 제한되며, 클라이언트 인증 배포가 원하는 것이 바로 그것이다:

Set-VpnConnection -Name 'Office' -MachineCertificateEKUFilter '1.3.6.1.5.5.7.3.2'

값은 배열이므로 여러 용도가 필요한 배포는 이를 목록으로 넘긴다. 필터가 할 수 없는 일은 인증서에 용도를 더하는 것이다. 서명된 확장에 대해 평가되는 선택 식이며 어떤 필터도 확장을 다시 쓰지 않으므로, 용도가 빠진 인증서는 등록을 다시 거쳐야 한다.

사용자 인증서의 EAP 구성을 컴퓨터 인증서 필터링과 분리해 두자. 둘은 서로 다른 곳에 있고 한쪽의 변경이 다른 쪽의 장애를 설명하는 일은 드물다. 프로필을 도메인이 소유하는지 장치 관리가 소유하는지도 확인하자. 로컬 편집은 아무도 컴퓨터를 건드리지 않은 채 다음 정책 새로 고침에서 대체될 수 있다.

클라이언트가 어떤 인증서를 제공했는지 증명하자

새 연결을 맺고 의도한 ID에 대한 클라이언트와 서버 인증 증거를 읽는다. 필터를 만족하는 인증서가 둘 이상이면 결과는 고정된 리프가 아니라 더 작은 풀이므로, 다음 시도에서 다른 구성원이 선택될 수 있다. 그 증거에 나타난 지문을 적고 저장소에서 기록한 것과 비교한다.

명령 성공은 인증 성공이 아니다. 기록할 만한 결과는 의도한 인증서가 관리되는 정책 아래에서 인증되고, 무관한 인증서는 그것에 의존하는 서비스에 계속 쓰일 수 있다는 점이다. 두 필터를 거쳐도 장애가 남는다면 다음에 볼 곳은 프로필 전체가 아니라 남은 후보들이다.