iPhone에서 IKEv2 인증서 설정: 수동 등록과 관리형 등록
등록 경로가 어떤 인증서 옵션이 있는지를 결정합니다. 먼저 수동 또는 관리형을 선택한 다음 서버 ID, 클라이언트 자격 증명, 알고리즘을 맞추십시오.
게이트웨이의 인증서 도구가 기본값으로 RSA를 사용한다는 이유만으로 RSA를 고르는 것은, 이 iPhone들을 어떻게 등록할 것인가라는 정말 중요한 질문 이전에 내리는 결정입니다. 사용자가 직접 입력하는 연결과 관리 측이 배포하는 구성 프로필은 서로 다른 설정을 노출하며, 일부 인증서 선택지는 두 경로 중 하나에만 존재합니다. 순서를 올바르게 잡으면 인증서 계획은 짧아지고, 잘못 잡으면 전화기가 쓰지 않을 자격 증명을 발급하게 됩니다. 아래 단계는 각 단계가 다음 단계에서 고를 수 있는 범위를 좁히므로 순서로 다루십시오.
첫 번째 단계: 등록 경로 선택
수동 설정은 사용자가 서버 주소를 입력하고, 인증 방법을 고르고, 인터페이스가 허용하는 자격 증명을 제공한다는 뜻입니다. 관리형 등록은 프로필이 주소와 식별자, 자격 증명 페이로드에 대한 참조를 담는다는 뜻입니다. 관리형 경로는 수동 화면이 표현할 수 없는 조합을 표현할 수 있으므로 인증서 결정은 이 선택 이후에 와야 하며 그 전에 와서는 안 됩니다.
두 경로 모두 전화기를 인증할 수 있습니다. 설정할 수 있는 것과 ID의 소유자가 다르므로, 관리형 프로필과 수동 자격 증명 입력을 섞지 말고 둘 중 하나를 의식적으로 고르십시오.
두 번째 단계: 선택한 경로에 맞는 알고리즘 고르기
수동으로 구성한 iPhone의 경우 strongSwan의 iOS 상호운용성 노트는, 수동 클라이언트가 ECDSA 서버 인증서를 받아들이지 않을 수 있기 때문에 RSA 서버 인증서를 권장하며, 같은 노트는 macOS를 따로 다룹니다. 이것은 지원되는 클라이언트 집합에 대한 지침으로 읽고, Apple 기기에 관한 영구적인 법칙으로 읽지 마십시오. 관리형 프로필은 페이로드와 게이트웨이가 모두 지원할 때 ECDSA 클라이언트 ID를 포함해 인증서 유형을 명시적으로 고를 수 있어 여지가 더 많습니다.
무언가를 배포하기 전에 실제로 지원하는 iOS 버전을 검증하십시오. 최신 릴리스의 실험실 전화기는 구형 기기를 포함한 플릿을 설명하지 못하며, 실험실에서 동작하는 알고리즘도 현장의 가장 오래된 전화기에서는 실패할 수 있습니다. 버전 범위는 기억이 아니라 기기 관리에서 가져오십시오. 플릿이 여러 릴리스에 걸쳐 있으면 수동 인터페이스가 가장 제약이 큰 가장 오래된 것을 먼저 시험하십시오.
세 번째 단계: 프로필 필드를 별개의 것으로 읽기
이름이 비슷한 여러 키가 서로 다른 객체를 설명합니다. 원격 주소는 전화기가 호출하는 호스트입니다. 원격 식별자는 게이트웨이가 제시하리라 기대하는 IKE ID입니다. 페이로드의 인증서 참조는 클라이언트 자격 증명을 가리키고, 인증서 유형 필드는 IKEv2 기계 인증에 쓰이는 유형을 고릅니다. 단어가 겹치더라도 그중 어느 것도 CA의 서명 알고리즘이 아닙니다.
Apple의 IKEv2 페이로드 참조는 RSA를 기본 인증서 유형으로 명시적 ECDSA 변형과 함께 나열하고, 발급자 이름 키를 특정 인증 설정에 연결합니다. 동작하는 배포에서 키 하나를 복사하는 대신 선택한 방법의 참조에서 그 관계를 읽으십시오.
네 번째 단계: 게이트웨이 ID를 인증서에 맞추기
예를 들어 vpn.example.com 같은 명시적 게이트웨이 이름을 쓰고, 서버 인증서에 일치하는 주체 대체 이름을 넣으십시오. strongSwan의 Apple 지침은 서버 인증을 위한 확장 키 사용도 기대합니다. RSA나 ECDSA를 골라도 그중 어느 것도 바뀌지 않으며, 알고리즘은 이름 불일치, 빠진 EKU, 불완전한 체인을 고칠 수 없습니다.
신뢰 앵커 배포는 ID를 주장하는 것과는 별개의 작업입니다. 전화기에는 검증할 수 있는 인증서 체인이 필요하고, 인증서에 실제로 넣은 이름을 기대하도록 구성해야 합니다.
다른 플랫폼이 성공적으로 연결된다는 것은 그 플랫폼의 검증 규칙에 대한 증거이지, 전화기의 규칙을 완화해도 된다는 허가가 아닙니다. 다를 만한 문서화된 이유가 없다면 클라이언트 간 검사를 동일하게 유지하십시오.
다섯 번째 단계: 클라이언트 ID와 CA 신뢰 분리
클라이언트 인증서와 그 개인 키는 전화기가 신뢰하는 CA 인증서와 같은 객체가 아닙니다. CA 인증서를 PKCS#12 ID 안에 묶는다고 해서 지원되는 모든 기기에 신뢰 앵커로 자동 설치되지는 않으므로, 신뢰 배포는 자체 검증을 갖는 별도 단계로 다루십시오.
설계가 대신 암호 기반 EAP를 사용한다면, 전화기에는 의도된 계정 인증과 서버 검증이 필요합니다. 그 경로는 하나의 공유 클라이언트 개인 키를 전체 플릿에 배포하는 것을 정당화하지 않으며, 그것은 실패 방식이 훨씬 나쁜 다른 설계입니다.
갱신과 폐기를 염두에 두고, 누가 클라이언트 자격 증명을 재발급하는지, 프로필을 어떻게 갱신하는지, 분실한 전화기를 어떻게 차단하는지를 정하며 계획을 끝내십시오. 검증한 프로필 버전과 기기 버전을 기록하는 것이 다음 인증서 교체를 일상적인 변경으로 만듭니다.