Android IKEv2 신뢰 오류: 루트가 아니라 중간 CA를 보내야 합니다
체인이 일찍 끝나기 때문에 휴대전화가 게이트웨이를 거부합니다. 중간 인증서를 보낼지, ID를 고칠지, 키 유형을 바꿀지 결정하세요.
휴대전화가 연결을 거부하며 No trusted RSA public key found for vpn.example.net을(를) 출력하지만, 같은 게이트웨이 인증서가 같은 네트워크의 노트북에서는 작동합니다. 인증서를 다시 발급하는 것이 끌리는 선택입니다. 그 전에 세 가지 실패 중 어느 것인지 확인하세요. 인증서 내용에 관한 것은 그중 하나뿐입니다. 이 메시지는 불완전한 체인, ID 불일치, 지원되지 않는 키나 서명을 포괄하며 각각 해결 방법이 다릅니다.
하나의 메시지 뒤에 있는 세 가지 실패
Android는 게이트웨이 인증서에서 VPN 프로필에 선택된 CA까지 체인을 만든 뒤 서버 이름을 프로필과 비교합니다. 알림은 단계가 아니라 결과를 알려 줍니다. 신뢰 실패는 교환에서 전달된 인증서로 체인을 완성할 수 없었다는 뜻이고, ID 실패는 체인은 검증되었지만 이름이 일치하지 않았다는 뜻이며, 알고리즘 실패는 기기나 프로필이 키 유형이나 서명을 받아들이지 않는다는 뜻입니다.
| What you see | What it points to | First move |
|---|---|---|
| Chain stops after the leaf in the daemon log | intermediate not loaded or not sent | load the intermediate as CA material |
| Chain validates, name differs from the profile | identity mismatch | fix the profile name or the certificate SAN |
| Chain validates, handshake still fails | key or signature not accepted | compare key type against the device |
해결책을 순서대로 시도하기보다 증거로 판단하세요. 데몬에 대해 로그 수준 2로 한 번 시도하면 어느 행에 속하는지 알 수 있으며, 애초에 잘못된 적 없는 인증서를 다시 발급하는 것보다 비용이 적습니다.
먼저 결정하세요: 체인 전체가 도착했나요?
strongSwan은 해당 연결에 구성된 인증서를 보내며, 중간 인증서는 별도의 자격 증명입니다. 데몬이 페이로드에 넣으려면 먼저 CA 인증서로 로드해야 합니다. 따라서 서버 인증서가 중간 인증서로 서명되고, 루트가 신뢰 앵커이며, 중간 인증서가 CA의 빌드 디렉터리에만 있는 구성은 정확히 이 실패를 만듭니다. 즉, 전송 구간에는 리프만 있고 휴대전화에서는 체인이 일찍 끝납니다.
swanctl 배포에서는 swanctl --list-certs로, 이전 starter에서는 ipsec listcerts로 데몬이 무엇을 보유하는지 확인하세요. 중간 인증서는 그 위에 루트가 있는 CA 인증서로 나타나야 합니다. 없으면 어떤 클라이언트 옵션도 도움이 되지 않고, 있으면 다음 질문으로 넘어가세요.
그다음 전송될 것인지 확인하세요. swanctl.conf 참조는 send_cert을 문서화하는데, 기본값 ifasked은 피어가 요청했을 때만 인증서를 보내고 always은 무조건 보냅니다. 레거시에 해당하는 것은 ipsec.conf의 leftsendcert=always입니다. 이 설정은 전송을 제어할 뿐 가용성을 제어하지 않으므로, 데몬이 로드한 적 없는 중간 인증서를 보완할 수 없습니다.
체인이 짧다면 데몬이 찾는 위치에 중간 인증서를 로드하세요
중간 인증서를 리프 옆이 아니라 CA 디렉터리에 두세요. ipsec.conf 구성에서는 /etc/ipsec.d/cacerts, swanctl에서는 /etc/swanctl/x509ca, 또는 패키지가 대체하는 경로입니다. 구성을 다시 로드하고 인증서를 다시 나열하세요. 일부 버전은 리프 파일 안에 체인을 담은 번들을 보내기도 하지만, CA 디렉터리는 버전과 패키지 전반에서 이식 가능한 방식입니다.
클라이언트 쪽에서도 확인하세요. 휴대전화는 교환이 전달한 것만 보므로, 로그 수준 2의 데몬 로그에 전송된 인증서 가운데 중간 인증서가 보여야 합니다. 로그에 보이는데도 휴대전화가 실패하면 다른 행에 속한 것이며, CA 파일을 계속 조정해도 결과는 바뀌지 않습니다.
체인이 완전하면 인증서 편집을 멈추세요
ID 실패는 VPN 프로필의 이름과 인증서의 이름이 일치하지 않는 것입니다. Android는 구성한 서버 ID를 검증한 인증서와 비교하므로, 인증서가 호스트 이름을 지정하는데 프로필이 주소를 가리키거나, 인증서가 포함하지 않는 호스트 이름을 프로필이 지정하면 체인 검증에 성공한 뒤에도 실패합니다. 잘못된 쪽을 고치고, 어느 한쪽이 바뀌면 프로필과 인증서를 계속 일치시키세요.
알고리즘 실패는 유효한 체인과 일치하는 이름에서 나타납니다. Android 릴리스마다 허용하는 키 유형과 서명 방식이 다르며, 프로필 유형 자체가 옵션을 제한합니다. 게이트웨이가 오래되었거나 흔치 않은 조합을 사용한다면 인증서가 손상되었다고 단정하기 전에 기기가 지원하는 것과 비교하세요. 데몬 로그는 신뢰 사례보다 핸드셰이크가 더 진행되는 것을 보여 주며, 이것이 체인이 더 이상 문제가 아니라는 신호입니다.
중간 인증서를 휴대전화의 사용자 루트로 설치하지 마세요
누락된 중간 인증서를 휴대전화에 사용자 인증서로 설치하면 경고가 사라지고 사용자 설치 루트를 허용하는 모든 앱에 대해 휴대전화의 신뢰 모델이 바뀝니다. 또한 다음 클라이언트에서 터질 전달 버그를 숨기고, 게이트웨이가 앞으로의 모든 기기에 불완전한 체인을 보내도록 남깁니다. 지속적인 해결책은 서버에서 한 번, 모든 클라이언트를 위해 하는 것입니다.
변경 기록에서 세 가지 결정을 분리해 두세요. 어떤 인증서가 전송되었는지, 어떤 ID가 비교되었는지, 어떤 알고리즘이 협상되었는지입니다. 항상 전체 체인을 보내는 게이트웨이, 인증서 이름을 올바르게 지정하는 프로필, 그리고 플릿이 지원하는 키 유형은 세 가지 작은 사실이며, 이 실패의 전부입니다.