Mac VPN 인증서 로그인: 신원, 키 사용, 아니면 게이트웨이 신뢰?
인증서 로그인 뒤에는 세 가지 결정이 있습니다. 어떤 신원이 선택되는지, VPN 구성 요소가 자기 키를 사용할 수 있는지, 그리고 게이트웨이를 신뢰하는지입니다.
인증서 기반 VPN 로그인은 Mac에 비밀번호보다 훨씬 좁은 것을 요구합니다: 이 실행 컨텍스트에서 이 특정 개인 키를 사용해 그 게이트웨이에 신원을 증명하는 것입니다. 실패했을 때 표시되는 메시지는 대개 마지막으로 잘못된 일만 설명하며, 그것이 원인인 경우는 드뭅니다. 시스템이 결정하는 순서대로 세 가지 결정을 짚어 가면 진단이 정직하게 유지되고, 로컬 권한 문제가 체인 검증 실패로 취급되는 일도 막을 수 있습니다.
Mac이 하는 순서대로 로그인을 따라가기
먼저 클라이언트가 신원을 선택합니다: 사용 가능한 개인 키와 짝을 이룬 인증서, 지원되는 저장소나 자격 증명 공급자를 통해 사용할 수 있습니다. 그다음 VPN 구성 요소가 그 키로 암호 연산을 수행하도록 요청하고, 로컬 인가 모델이 응답합니다. 둘 다 성공한 뒤에야 원격 핸드셰이크가 일어나며, 여기서 Mac이 게이트웨이를 평가하고 게이트웨이가 클라이언트의 증명을 평가합니다.
| Decision | Typical symptom | Where to look |
|---|---|---|
| Identity selection | No valid identity, wrong certificate offered | Profile and which identity the client picked |
| Local key use | Signing or interaction error before any handshake | Execution context and key access rules |
| Remote authentication | Chain, name or client-admission rejection | Gateway identity and what it accepts |
표를 위에서 아래로 읽고 처음 실패하는 행에서 멈추십시오. 실패 아래의 모든 것은 입증되지 않은 상태이며, “인증서를 신뢰할 수 없다”는 결론이 그토록 흔하고 그토록 믿기 어려운 이유가 여기 있습니다.
로컬 권한이 실제로 포괄하는 범위
macOS 키체인 모델에서 보호된 항목은 작업별 접근 규칙과 신뢰하는 응용 프로그램 목록을 가집니다. 개인 키로 서명하는 것도 그런 작업 중 하나이며, 규칙은 그것을 수행하는 실행 파일에 적용되지 문서로서의 인증서에 적용되는 것이 아닙니다. Apple의 접근 제어 참조 문서는 이 모델과 iCloud 키체인 및 접근 그룹 구성 사이에도 선을 긋고 있으므로, 한쪽을 위해 쓰인 조언이 다른 쪽으로 옮겨지지 않습니다.
여기서 두 가지 결과가 따라옵니다. 공개 인증서가 목록에 보인다고 해서 VPN의 백그라운드 구성 요소가 그 키에 닿을 수 있다는 것이 증명되지는 않습니다. 그리고 전면 응용 프로그램에 부여된 권한은 별도의 도우미나 네트워크 확장에 대해 아무것도 말해 주지 않는데, 서로 다른 신원을 가진 다른 코드이기 때문입니다.
옛 클라이언트에서 실행 파일 경로를 복사하는 대신 실제 구현과 그것이 지원하는 자격 증명 공유 방식을 확인하십시오. 먼저 시스템이 어떤 신원을 제시할지 확정하십시오:
security find-identity -v -p ssl-client
errSecInteractionNotAllowed 읽기
그 상태는 Security Server와의 상호 작용이 허용되지 않았음을 알리며, 인증서 체인에 대해서는 아무것도 말하지 않습니다. 그것을 만들어 낸 작업과 함께 읽으십시오: 프롬프트를 표시할 수 없는 컨텍스트에서 보낸 서명 요청은 키와 인증서가 모두 완벽히 유효하더라도 이런 식으로 실패합니다. 시작할 지점은 그것을 기록한 작업이며 인증서 저장소가 아닙니다. 신뢰 앵커에 대해 무엇을 바꾸든 오류는 정확히 있던 자리에 그대로 남습니다.
그러니 이 코드를 실행 컨텍스트와 인가를 살펴볼 이유로 다루십시오. 게이트웨이 CA를 신뢰할 수 없다는 증거로 다루면 문제의 잘못된 절반으로 보내지며, 그곳에서 한 변경은 오류에 전혀 영향을 주지 않습니다.
좁게 고치고 넓게 고치지 않기
연결 소유자의 등록 또는 가져오기 지침에서 시작하십시오. 클라이언트 버전, 프로필 범위, 선택된 신원, 첫 번째 관련 로컬 오류를 기록하십시오: 지원 인계에 필요한 것이 이 네 가지 사실이고 이후 비교도 여기에 의존합니다. 관리형 프로필이나 하드웨어 기반 신원은 관리자나 공급자가 인계를 고쳐야 할 수 있으며, 로컬 클릭으로는 그것을 대신할 수 없습니다.
제품이 사용자 승인을 기대하는 곳에서는 어느 구성 요소가 요청하는지 확인하고 지원되는 흐름으로 그 접근만 승인하십시오. 구성 요소가 실행되는 컨텍스트에서 프롬프트를 띄울 방법이 없다면, 프로비저닝은 공급업체가 문서화한 경로를 따라야 하며 다른 터미널 창에서 끌어낸 대화 상자로는 안 됩니다.
옛 조언에서는 두 가지 변경이 함께 묶이는데, 둘 다 너무 넓습니다. 모든 응용 프로그램에 개인 키 접근을 허용하면 로컬 키 사용이 요구 사항을 훨씬 넘어 넓어지고, 인증서를 Always Trust로 설정하면 시스템의 모든 것에 대한 인증서 평가가 바뀝니다. 어느 것도 “이 승인된 VPN 구현이 이 의도된 신원을 사용하는 것”을 표현하지 않습니다.
게이트웨이를 읽기 전에 로컬에서 확인하기
수리를 마친 뒤 로컬 작업이 성공하는지 확인하고, 상대편의 어떤 응답이든 해석하기 전에. 서명이 이제 동작한다면, 이후의 이름·체인·클라이언트 수용 거부는 재발이 아니라 새로운 결과이며, 다른 책임자를 가진 다른 결정에 속합니다.
유용한 인계는 세 가지 결정 중 어느 것이 실패했는지 밝히고 거기서 멈춥니다. 개인 키를 결코 포함하지 않으며, 깨끗한 상태가 도움이 되리라는 기대에 무관한 키체인 항목을 초기화하지도 않습니다. 그 두 가지 습관은 모든 것을 한꺼번에 시도하고 싶은 유혹이 가장 강한 사건 도중이 아니라 그 전에 정해 두십시오. “키체인을 다시 만들었다”는 티켓은 다음 읽는 사람에게 원래 결함에 대해 거의 아무것도 알려 주지 않습니다.