Mac VPN 인증서: 식별 정보 선택기가 비어 있는 이유
클라이언트에는 인증서와 그 개인 키가, 클라이언트가 읽을 수 있는 저장소에 있어야 합니다. 먼저 식별 정보를 확인한 다음 게이트웨이가 이를 수락하는지 확인하세요.
인증서를 설치했고 Keychain Access에 친숙한 이름으로 표시되는데도 VPN 클라이언트의 식별 정보 선택기는 여전히 비어 있습니다. 클라이언트는 인증서를 찾는 것이 아닙니다. 소유를 증명할 수 있는 개인 키와 짝을 이룬 인증서, 즉 클라이언트가 읽도록 허용된 곳에 저장된 식별 정보를 찾는 것입니다.
클라이언트가 요구하는 것은 식별 정보입니다
Apple의 보안 프레임워크는 인증서와 식별 정보를 서로 다른 객체로 취급합니다. 인증서는 공개 데이터입니다. 식별 정보는 그 인증서에 개인 키를 더한 것이며, 챌린지를 완료할 수 있는 것은 식별 정보뿐입니다. 반면 신뢰된 CA 인증서는 클라이언트가 발급자를 평가하도록 해 줄 뿐, 기기를 발급된 클라이언트 자격 증명의 보유자로 만들지는 않습니다.
| Item | What it can do | What it cannot do |
|---|---|---|
| CA or server certificate | Validate the gateway's chain | Authenticate this client |
| Client certificate without key | Nothing for authentication | Prove possession of anything |
| Identity (cert plus key) | Answer the authentication challenge | Guarantee the gateway accepts it |
그래서 .cer 파일을 가져와도 사용 가능한 클라이언트 식별 정보는 절대 만들어지지 않습니다. 파일에는 공개 자료만 들어 있고, 이름을 바꾸거나 신뢰를 부여해도 키 쌍이 되지는 않습니다.
선택기가 비어 있는 세 가지 이유
첫째는 개인 키가 없는 경우로, 등록이나 가져오기 과정이 키를 전달하지 않았다는 뜻입니다. 둘째는 클라이언트가 조회하지 않는 저장소로, 사용자 범위 프로필은 사용자의 키체인을 보지만, 시스템 저장소에 둔 항목은 보이지 않을 수 있습니다. 셋째는 용도나 정책의 불일치로, 인증서는 있지만 배포 규칙상 클라이언트 인증에 유효하지 않은 경우입니다.
security find-identity -v -p ssl-client이 명령은 시스템이 클라이언트 인증에 유효하다고 보는 식별 정보를 나열합니다. 개수가 영이면 문제는 VPN 클라이언트보다 상류에 있고 프로필 편집으로는 고쳐지지 않습니다. 식별 정보가 여기에는 나오지만 클라이언트에는 나오지 않는다면 차이는 클라이언트의 저장소나 범위에 있습니다.
개인 키가 어디에 있고 누가 사용할 수 있는가
Keychain Access로 식별 정보를 가져오면 가져오기 대화상자가 대상 키체인을 제안합니다. 어느 대상이 맞는지는 클라이언트와 프로필이 사용자 범위인지 기기 범위인지에 따라 다릅니다. 시스템 키체인을 권하는 오래된 답변은 보편적 규칙이 아니며, 저장소 사이에 항목을 복사하는 것은 복구가 아닙니다.
System Roots는 신뢰 모음입니다. 거기에 인증서를 두면 시스템이 어떤 발급자를 신뢰하는지가 바뀌며, 개인 키를 만들지 않고 식별 정보 저장소도 아닙니다. 선택기를 채우려고 무관한 인증서를 옮기는 것은 기기에 영구적으로 넓어진 신뢰 집합을 남기는 종류의 수정입니다.
개인 키 접근은 별도의 제어입니다. 모든 애플리케이션에 키 사용 권한을 부여하는 것 은 한 클라이언트의 선택 문제를 해결하지만 같은 능력을 기기의 다른 모든 것에 넘겨줍니다. 필요한 클라이언트에만 부여하고, 키가 하드웨어 기반인지 내보낼 수 없음으로 표시되어 있는지 확인하고, 그렇다면 내보낸 사본이 아니라 지원되는 공급자를 사용해야 합니다.
프로필이 자격 증명을 가리키는 방식
관리되는 네이티브 IKEv2 구성에서 프로필은 PayloadCertificateUUID를 통해 자격 증명 페이로드를 참조합니다. 중요한 것은 참조된 식별 정보와 그것이 제공된 방식이며, 프로필의 표시 이름을 편집해도 잘못된 페이로드나 키를 한 번도 전달하지 않은 페이로드를 가리키는 참조는 고쳐지지 않습니다.
타사 공급자는 자체 저장소나 시스템 프롬프트처럼 전혀 다른 선택 메커니즘을 쓸 수 있습니다. 네이티브 프로필의 가정을 옮기지 말고 해당 공급자의 문서를 읽고, 관리 콘솔의 초안이 아니라 실제로 설치된 프로필에서 참조를 검증하세요.
선택과 수락은 별개의 이정표입니다
선택기가 채워졌다는 것은 클라이언트가 식별 정보를 찾아 쓸 수 있다는 뜻일 뿐입니다. 게이트웨이가 이를 수락할지는 말해 주지 않습니다. 서버는 여전히 발급자, 유효 기간, 해지 상태, 그리고 해당 자격 증명에서 계정으로의 매핑.
두 단계를 명시적으로, 그 순서대로 테스트하세요. 식별 정보가 제공되는지 확인하고 연결한 다음, 게이트웨이 소유자에게 어떤 자격 증명이 제시되었고 어떤 매핑 규칙이 그것을 소비했는지 확인해 달라고 하세요. 클라이언트가 식별 정보를 제공하는데 서버가 거부한다면 남은 작업은 서버 쪽입니다. Mac에서 인증서를 다시 설치해도 몇 번을 반복하든 그 결과는 바뀌지 않습니다.