Mac IKEv2 ECDSA: 클라이언트에 속한 인증서 유형은 무엇인가?
Mac에서 IKEv2 설정의 ECDSA256은 로컬 ID 인증서를 가리키며, 게이트웨이나 발급자의 서명이 아닙니다. 선택하기 전에 각 역할을 읽으십시오.
macOS에서 IKEv2 클라이언트 설정의 ECDSA 선택은 좁은 질문에 답합니다. 어떤 인증서가 Mac의 ID를 증명하는가입니다. 게이트웨이 인증서, 클라이언트 인증서를 발급한 서명, 터널의 암호화 제안은 설명하지 않습니다. 이 네 가지 역할을 하나의 호환성 질문으로 다루면 올바른 로컬 설정이 서버 측 불일치의 원인으로 지목됩니다. 결정은 작지만 그것을 내리는 데 쓰는 증거는 정확해야 합니다.
이 필드가 가리키는 인증서는 하나입니다: 로컬 ID
Apple의 Network Extension API는 클라이언트 자격 증명에 대한 인증서 유형을 제공하며, NEVPNIKEv2CertificateType.ECDSA256이 포함됩니다. 이는 ECDSA p-256 인증서 유형으로 문서화되어 있습니다. 이 속성은 identityReference 또는 identityData를 통해 제공된 인증서에 적용됩니다.
즉 결정은 Mac이 제시하는 인증서와 그에 딸린 개인 키에 관한 것입니다. 해당 리프 인증서의 공개 키와 일치하는 유형을 선택하고 지원되는 방식으로 ID를 제공하십시오. Mac에 ID용으로 쓸 수 있는 개인 키가 없으면 유형 선택으로 연결을 구할 수 없습니다.
관리 프로파일은 IKEv2 페이로드의 CertificateType과 PayloadCertificateUUID 같은 인증서 참조를 함께 사용해 같은 결정을 내립니다. 이 필드에는 대상 OS 릴리스에 대한 전제 조건과 스키마가 있습니다. 프로파일에 복사한 유형 값만으로는 설치할 수 없고, 설정 창이 모든 API 옵션을 표시하지 않을 수도 있습니다. 배포 전에 해당 릴리스의 페이로드 전제 조건을 확인하십시오.
인증서 라벨이 아니라 역할로 판단하십시오
변경하려는 필드를 읽고 어느 인증서를 가리키는지 물으십시오. 인증서 뷰어의 라벨은 주체, 발급자, 서명 알고리즘을 섞어 보여 주며, 클라이언트 ID 선택에 해당하는 것은 그중 하나뿐입니다.
| What you inspected | What it controls | Does it choose the Mac certificate type? |
|---|---|---|
| Client leaf public key | The identity the Mac presents | Yes, this is the field's subject |
| Issuer signature algorithm | How the client certificate was signed | No |
| Gateway certificate | What the Mac validates as the peer | No, check it separately |
| IKE and ESP proposals | Algorithms for the tunnel | No, separate proposal settings |
인증서 뷰어가 CA의 ECDSA 서명을 보여 준다면 그것은 발급자의 서명 키를 설명합니다. 클라이언트 자신의 키는 여전히 RSA일 수 있고, 유형 필드는 서명 줄이 아니라 클라이언트 키를 따라야 합니다. 이 한 가지 혼동이 "ECDSA를 구성했는데 연결이 실패한다"는 보고의 상당수를 설명합니다. 무엇이든 바꾸기 전에 리프의 키 유형과 프로파일에서 선택한 유형을 비교하십시오.
리프가 식별되면 결정은 더 단순해집니다. p-256 클라이언트 키에는 ECDSA256, 다른 키에는 다른 지원 유형입니다. 클라이언트 인증서와 그 키가 맞지 않으면 VPN 프로파일을 바꾸기 전에 그 짝을 고치십시오.
게이트웨이 인증서는 별도의 결정입니다
게이트웨이는 자체 인증서를 제시하고 Mac은 신뢰 앵커와 예상 이름에 대해 이를 검증합니다. 그 인증서가 ECDSA, RSA 또는 다른 키 유형을 쓰는지는 서버의 속성이지 클라이언트 ID 설정의 속성이 아닙니다.
ECDSA 클라이언트 인증서에 대한 로컬 지원은 모든 게이트웨이 인증서, 곡선, 서버 인증 구성이 상호 운용된다는 것을 증명하지 않습니다. 서버의 ID, 체인, IKE 인증 방법을 별개의 입력으로 확인하고 실제로 배포할 프로파일로 시험하십시오.
게이트웨이 인증서가 문제라면 증상은 보통 ID 선택이 아니라 피어 검증 중에 나타납니다. 클라이언트 유형을 바꾸기 전에 실패 단계를 읽으십시오. 신뢰 실패와 클라이언트 키 불일치는 같은 해결책을 공유하지 않습니다.
발급자의 서명과 키 합의 그룹은 클라이언트 유형이 아닙니다
X.509는 주체의 공개 키와 발급자의 서명을 서로 다른 필드에 둡니다. 주체 공개 키 정보는 인증서 안의 키를 설명하고, 서명 알고리즘은 CA의 키와 서명 작업을 설명합니다. 인증서 유형 설정과 일치하는 것은 첫 번째뿐입니다.
IKE와 Child SA 제안은 또 다른 축입니다. ECDSA 인증서 유형은 ESP 암호화 선택이 아니며, 키 합의 그룹을 바꾼다고 인증서 유형이 선택되지도 않습니다. 프로파일에 유효한 제안과 잘못된 ID 유형이 함께 있을 수도 있고, 올바른 ID 유형과 피어가 거부하는 제안이 함께 있을 수도 있습니다.
변경 기록에서 세 줄을 분리하십시오. ID 인증서와 키, 게이트웨이 신뢰 입력, 제안 알고리즘입니다. 이를 하나의 "암호 설정" 메모로 합치면 다음 실패의 원인을 귀속시킬 수 없습니다.
구성한 필드로 결정을 검증하십시오
프로파일이 실제로 참조하는 ID를 확인한 다음, 그 참조의 인증서에 예상 공개 키와 쓸 수 있는 개인 키가 있는지 확인하십시오. UI에 표시되는 유형, 참조된 인증서, 장치의 키가 일치해야 합니다.
다음으로 게이트웨이 입력을 확인하십시오. 예상 서버 이름, 신뢰 앵커, IKE 인증 방법입니다. 마지막으로 연결해 핸드셰이크가 어디서 멈추는지 읽으십시오. ID 교환 전의 실패는 이 설정에서 멀어진 원인을 가리키고, 피어 검증에서의 실패는 게이트웨이 쪽을 가리킵니다.
선택한 유형, ID 참조, 게이트웨이 인증서의 주체를 배포 메모에 기록하십시오. 다음 프로파일 업데이트에서 어느 것이든 바뀔 수 있고, 이름 붙은 세 값은 설정 패널의 스크린샷보다 빠르게 비교됩니다.