Windows에서 EAP-TLS로 PIV 로그인이 실패한다면? 서명 경로를 확인하세요

PIV 카드의 인증서를 모든 Windows 대화 상자에 표시해도 VPN 로그인은 여전히 실패할 수 있습니다. 보이는 것과 쓸 수 있는 것은 다른 속성이기 때문입니다. 인증서는 공개 객체이고, 로그인에는 카드가 자체 액세스 규칙에 따라 수행하는 개인 키 작업이 필요합니다. 이 두 사실 사이에는 프로필 선택, 인증서 선택, 로컬 서명, 서버 측 검증이라는, 서로 다른 네 가지 방식으로 실패하는 네 단계가 있으며, 순서대로 짚어 가면 일반적인 핸드셰이크 오류가 다음 조각을 가진 사람에게 던지는 구체적인 질문으로 바뀝니다.

프로필과 EAP 방식부터 시작합니다

연결 속성을 열어 프로필이 실제로 어떤 EAP 방식을 쓰는지 읽고, 이어서 그 방식이 어떤 인증서를 선택하도록 설정되어 있는지 읽습니다. 많은 배포에는 인증서 기반 외부 방식과 내부 방식이 함께 있으며, 연결 수준에서 설정한 인증서가 자동으로 EAP-TLS 내부에서 제시되는 인증서가 되는 것은 아닙니다. 프로필이 발급자나 주체 필터로 인증서를 고른다면 그 필터는 Windows가 해당 저장소에서 볼 수 있는 것 중에서 고르며, 카드에 우연히 들어 있는 것 중에서 고르지 않습니다. 아무것도 일치하지 않는 필터는 프로필 구성에 따라 프롬프트나 조용한 실패로 되돌아가므로, 변경 전에 선택된 지문을 기록해 둘 가치가 있습니다.

연결이 로그인한 사용자로 실행되는지 컴퓨터로 실행되는지도 확인합니다. 이 한 가지 사실이 어떤 인증서 저장소가 범위에 들어가는지, 어떤 보안 컨텍스트가 서명을 수행하는지를 결정합니다.

어떤 인증서가 선택되었는지 확인합니다

Windows가 고른 지문을 클라이언트 인증 용도, 신뢰할 수 있는 루트에서 끝나는 체인, 인증 서버의 정책이 매핑하는 ID, 그리고 시도의 실제 시점을 덮는 유효 기간이라는 요구 사항과 비교합니다. 이들은 별개의 확인이며 마지막 항목은, 특히 계속 발급되는 인증서와 어제의 선택을 아직 가리키는 캐시된 프로필에서, 사람들이 예상하는 것보다 더 많은 변수를 잡아냅니다.

사용자와 컴퓨터 컨텍스트는 확인의 나머지 절반입니다. 사용자의 개인 저장소에 있는 인증서는 컴퓨터로 실행되는 서비스에는 보이지 않으며, 컴퓨터 인증서는 프로필이 그렇게 말하지 않는 한 사용자 모드 EAP 교환으로 제시되지 않습니다. 인증서를 잘못된 저장소로 다시 가져오면 보이는 인증서와 보이지 않는 로그인 자격 증명이 생깁니다. 프로필에 있는 저장소 경로를 읽어야 하며, 우연히 열린 대화 상자의 경로가 아닙니다.

PIN을 추측하지 않고 키 작업을 시험합니다

선택이 정해지면 질문은 카드가 서명을 수행할지 여부입니다. Windows가 개인 키에 도달하려면 지원되는 카드 공급자나 미니드라이버가 필요하고, 장치는 자체 PIN 및 존재 규칙을 작업에 적용합니다. 서명마다 터치를 요구하는 카드는 세션 단위로 검증을 캐시하는 카드와 다르게 동작하며, 둘 다 프롬프트가 나타나는 시점을 바꾸는 정당한 구성입니다. 이 차이가 인증서가 잘못되지 않은 채로 새로 삽입했을 때는 성공하고 다시 시작한 뒤에는 실패하는 로그인을 설명합니다.

certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'

첫 번째 명령은 카드를 목록화하고 판독기와 공급자의 상태를 보고하는데, 이는 Microsoft의 스마트 카드 디버깅 지침에 문서화되어 있습니다. 두 번째 명령은 사용자 컨텍스트가 실제로 무엇을 볼 수 있는지 나열합니다. 어느 것도 성공적인 인증을 증명하지 않으며, 둘 다 어디에서 멈췄는지를 좁힙니다.

PIN을 추측하지 마세요. 카드는 재시도 한도를 적용하며, 몇 번의 낙관적인 시도가 권한 문제를 관리자 복구가 필요한 차단된 자격 증명으로 바꿉니다. 로컬 서명이 실패하면 변형을 시도하는 대신 공급자 상태와 카드 상태를 기록하세요. 같은 프로필, 같은 인증서, 알려진 정상 판독기 경로로 한 번만 재시도한 뒤 두 기록을 비교하세요; 여러 변수를 한꺼번에 바꾸면 결과가 아니라 이야기가 됩니다.

핸드셰이크의 양쪽을 읽습니다

서명이 완료되었다고 해서 아직 허용은 아닙니다. 인증 서버는 체인을 받아들이고, 폐기를 확인하고, 현재 규칙에 따라 ID를 매핑하고, 요청을 승인해야 합니다; 클라이언트는 차례로 프로필이 요구하는 대로 서버 인증서를 검증해야 합니다. 서버가 생성한 TLS 경고는 클라이언트 로그에서 로컬로 생성한 것과 똑같이 보이므로, 경고 문구보다 어느 쪽이 내보냈는지가 더 중요합니다.

Windows 이벤트와 서버 측 이벤트를 정렬된 타임스탬프와 함께 수집한 뒤, 어느 쪽이 첫 실패를 만들었는지 식별합니다. RFC 5216은 EAP-TLS의 소유 증명 단계를 설명하며, 일반적인 핸드셰이크 경고는 로컬 키 원인을 그 자체로 지목하지 않습니다. 두 로그를 순서로 바꾸는 것은 타임스탬프 비교입니다.

보고서에서 경계를 곧게 유지합니다

보고서를 네 단계로 쓰고, 각 단계에 어떤 프로필과 컨텍스트가 실행되었는지, Windows가 어떤 인증서를 선택했는지, 카드가 서명했는지, 서버가 무엇을 결정했는지라는 하나의 판정을 붙입니다. 이 구조는 다음 단계를 분명하게 만들고, 아무도 식별하지 못한 단계를 통과하려고 검증을 끄는 흔한 수리를 막습니다.

임시 비교로서의 소프트웨어 인증서는 정당한 관리자 테스트이지만 자격 증명과 보증의 모델을 바꾸므로, 조용한 운영 우회가 아니라 승인된 변경에 속합니다. 같은 규율이 PIN 시도와 실패 단계가 알려지기 전의 자격 증명 재발급에도 적용됩니다. 똑같이 실패하는 교체 카드는 문제가 애초에 카드에 없었다는 값비싼 증거입니다.